Project Structure

Getting Help
1

I am doing a project as a hobby and its a boxing site. I am not sure how I should structure the different apis.
Here are my apis:

  • Admin API which depends more on loading data from rapid api website, but I added a front end using templ, htmx just in case I need to manually update a boxing match, fighter etc.

  • Web API which is more for the users who login to the site

  • Mobile API for mobile apps. I am leaning towards flutter for now. I am also thinking also to combine web/mobile apis together because they should be doing the exact same things.

My overall question is should I keep all of these under in the same directory stucture. Or do something like this below
Boxing
-----Admin Folders for Admin API
-----Web Folders for Web API
-----Mobile Folders for Mobile API
Any help is appreciated.

2

Just curious. Why not one single API as a micro service? And 3 different frontends?

3

I am new to all of this my background is data engineering and reporting. Does that mean I would do something like this in one file api.go file

router := http.NewServerMux()
router.Handle( “GET /admin/event” …)
router.Handle(" POST /admin/event" …)

router.Handle(" GET /web/event" …)
router.Handle(" GET /mobile/event" …)

4

IMO, yes. You can also use a “target carrier” in the REST and strip that out later from url

/admin/event/…/…
/web/event/…/…
/mobile/event/…/…

Switch target:
  case admin:
     // do admin stuff /event/.../...
  etc...
5

I can see doing different routes for the “admin” functionality. However, aren’t your mobile app and web app both consuming the same “non-admin” data and handling the same business logic, just via different user interfaces? You hinted at this in your question, they do the same thing. One of the main reasons you build an API is so different user interfaces (web, mobile iOS, mobile Android, client Mac, client Windows, etc., whatever your needs are) can all consume the same endpoints, thus decoupling the logic and data tiers from the presentation tier. Assuming it’s the same data and business logic, there should be one base route for each “non-admin” resource, e.g. just “/event” and every UI should consume that exact same route. Whether a user logs in or not shouldn’t matter, you will have a user login route that you could use for any UI, e.g. “/login”.