3 ms·
Defining them all on a single server struct means once you're past a handful you start having a hard-as-heck to organize folder of handlers (or a bunch of massi
by bpicolo 6y ago
Defining them all on a single server struct means once you're past a handful you start having a hard-as-heck to organize folder of handlers (or a bunch of massive code files).
How are folk managing Go endpoint as apps scale across number of endpoints? I'm skeptical that one struct in one folder leads to good app structure, and have seen this start to break down in a few cases in practice
- oppositelock 6y agoIt depends on what the struct contains. I have developed many Go API's professionally at several companies since Go 1.1, and all my servers and up looking like a server struct with only a few fields - a database, AWS client object, and some prometheus metrics. The logic is typically split among many files, all implementing receivers on that struct. If you have independent, different elements in that API, you break them out into separate "servers" but still register the endpoints on the same HTTP handler. I know that people don't like external libraries too much, but I'd like to plug my own here. You declare your API in OpenAPI 3.0 (aka, Swagger) and it generates your server and models for you, so all you need to do is write the business logic. (https://github.com/deepmap/oapi-codegen https://github.com/deepmap/oapi-codegen)
- bpicolo 6y agoThanks for the link - I've had trouble finding pretty much exactly this in the Go ecosystem after a few brief looks, and codegen is really the only sensible way to do openapi in go. I wouldn't be surprised to use this soon