> It's always the same thing, figure out what the UI needs then build an endpoint for it. Most API code involves struggling with an ORM to query a database and mangle the data into a shape that the UI expects to see.
Most business API's have business specific per user read/write access roles.
I am starting to think that a better solution to GraphQL and other DSL's is to:
- A. Make the iteration speed of adding a new plain HTTP endpoint very fast.
- B. Use a typed language, and some kind of macro to extract the types into an Open API spec.
This way everything is just a regular function in your general language:
- http_handler(request) -> response
- user_has_access(user, resource) -> bool)
etc.
Regular functions have no external dependencies, are easy to understand, edit and stand the test of time better than DSL's.
If GQL does what you need out of the box, it seems a win. But I would assume some endpoints need to fall back on the above approach anyway giving you a mixture of GQL-generated and hand-written handlers.