3 ms·
That is a very fair reason for structuring it that way. I agree that there is, to some extent, more overhead for the developer who normally works on and maintai
by lbhdc 4y ago
That is a very fair reason for structuring it that way. I agree that there is, to some extent, more overhead for the developer who normally works on and maintains the code base. However, I feel like it is easier as a reader to understand what a service does and how to integrate with it having all of the paths in a centralized location.
How do you normally think about making that information discoverable in your webapps?
- lf-non 4y agoNow a days I mostly always use either graphql/openapi depending on the history of the project and the preferences of the team. So there typically is a spec for the API. I usually prefer a code-first approach and the open source tooling is able to extract the spec for me from annotations - which becomes a centralized location for exploration or generating clients.