Feedback on My App Architecture for a Card Puzzle Game

0
4
Asked By CuriousCoder88 On

Hey folks, I'm working on my first big app and I could really use some feedback on my planned architecture. It's a card puzzle game that will have tons of possible moves but only a few moves per game round. I'm particularly unsure about the frontend implementation but would love any thoughts on the whole setup!

Here's a rundown of my architecture:

**Go Backend:**
I'm planning to serve the backend from a stateless container, using Go since I want to learn it and actually enjoy coding in it.

**Java API:**
I'm aiming for a stateless API that has two main functions: one to provide possible moves from a given game state, and another to return a new game state based on a user action. I found an open-source project that aligns well with what I need as a solid starting point for my API, and I'm using Java because I've worked with it before.

**Frontend:**
This is where I'm really not sure. I initially started with Go/htmx templates, which seemed great for other projects, but since my backend is stateless, it feels odd to keep sending state back with every request. So, I switched to Vue, which feels better, but now I'm only sending a single large HTML file containing Vue and some other scripts. This still feels not quite right, and I want to avoid a JavaScript-heavy backend.

**Database:**
I'm planning to use MongoDB to store initial states and user information. For now, I have just some sample data in the Go backend for testing. I chose MongoDB because it fits well with my preference for storing everything as JSON-style objects as opposed to traditional tables.

Let me know if my architecture makes sense or if you have suggestions!

3 Answers

Answered By GolangFan88 On

Just dropping in to say I’m a huge fan of Go! It’s got a solid backing and is really efficient for backend tasks. Can't weigh in on the rest, but you’re on a good path using it for your project!

Answered By TechyTina53 On

I’m a bit confused about your frontend design. It sounds like the flow you want involves the backend providing a start state and possible moves, and then the frontend displaying those moves for user selection. From what I gather, you’re sending the game state back and forth, but why not just send the moves instead? Having the backend calculate state based on user actions seems like the better route. You might want to avoid sending the entire state data every time to simplify things.

Answered By JavaGuru42 On

You're focusing a lot on your tech stack, but you haven’t really outlined your architecture clearly. It’s crucial to describe how different components will interact, especially how your Java API will communicate with your Go backend. You could consider using libraries like Datastar to help manage things without overwhelming yourself, especially since you're doing this for fun!

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.