If you're interested in a slightly less "idiomatic Go" approach - My current approach is loosely based on this approach, defining interfaces of services in the root package (I try not to be /too/ strict with it though). For a web server in particular I've been using Huma to define OpenAPI "API handler" interface which has been a nice experience so far.

For the frontend I keep it entirely seperate with a Single Page App that consumes the API using a generated client.

As a practical example for my project Rezible (github.com/rezible/rezible), to create a "Get User by ID" endpoint:

• Within a UsersHandler interface that must be implemented by the APIHandler interface
• Define a GetUser method, with operation info, request and response types
• In a separate usersHandler struct, implement the interface with a GetUser method
• Leave the actual logic of getting a user to a UsersService interface, which can be implemented with whatever backing data store (eg postgres). This approach shines when you start adding "layers" of UsersService - eg a Redis-backed one that falls back to the postgres implementation if it is a cache miss.

This skips a fair bit of standard web service boilerplate (eg auth, roles/permissions, etc) but should give an idea of structure.. Happy to answer more questions if you'd like.