I'm building my first larger app and would love some feedback on my planned architecture for a card puzzle game. This game will have lots of possible moves but only allow a few moves per round. I'm particularly looking for advice on my frontend implementation, but I'm open to comments on anything!
### Go Backend:
I'm planning to build a stateless backend using Go because I want to learn it and enjoy coding in it.
### Java API:
I want a stateless API that can provide possible moves based on a given game state and return a new game state from an action taken. I've found an open-source project that aligns well with my goals, and I chose Java since I'm familiar with it.
### Frontend:
This is where I'm feeling the most uncertain. Initially, I started with Go/HTMX templates, but since I need to send state back with every request due to the stateless nature, it felt off. I've now switched to Vue, which feels better, but I'm still just sending a single large HTML file with the Vue scripts. I'm worried about how this will work out, especially aiming to avoid a traditional database backend.
### Database:
I'm planning to use MongoDB to store the initial states and user information. Currently, I have some sample files in the Go backend for testing and I'm leaning towards using JSON-style objects instead of tables for data storage.
Any thoughts or guidance would be greatly appreciated!
3 Answers
I’m a bit confused by your frontend setup. It seems like the backend provides the state and possible moves, right? I imagine it should go something like this:
1. Start with an initial state, frontend asks the backend for possible moves.
2. The backend returns those moves, frontend shows them.
3. User selects a move, then the frontend sends this to the backend to get the new state.
4. Repeat!
Make sure you're just sending necessary information back and forth to keep things efficient. It feels odd to resend the state multiple times when you could streamline it. Also, what exactly are you storing in your DB?
You mentioned a lot about tech choices, but it sounds like your architecture isn’t completely clear yet. If this is your first big project, consider using something like the Datastar library. It could simplify things for you. What’s your main goal with this project - is it just for learning and fun?
Definitely just for fun! I'm not aiming for anything too serious yet. I’m still figuring out how to best articulate my architecture. What key points should I focus on?
Golang is awesome! I learned it back in college and really appreciate its efficiency and the great community behind it, but I can't speak much about the rest of your stack. Good luck with your project!
The initial state is kept in the database so I can validate moves without breaking the game. For now, I'm sending a complete JSON state around, but the goal is to eventually move to just sending an array of moves to the backend. The API would handle the validation between moves!