- runtime assertions [0] - to map unknown values at i/o boundary into statically typed code (rpc input parameters, sql results etc)
- template based sql combinators to sanitize sql/generate sql [1]
- jsonrpc over websockets - for bidirectional comms between f/e and b/e
It works very well for us for hundreds of rpcs - it's easy to manage things like permissioning/narrowing visibility and other aspects you need in business/enterprise-like setting ie. performance monitoring is very easy/straight forward.
It's pretty close to what's being described here, and removes the boilerplate in API orchestration.
Here's an example of a relatively complex query that you'd need when building something like a blog. GraphJin will compile this nested query into a single efficient SQL statement.
https://gist.github.com/dosco/f604c47c1d643fb62072f62c4f6f70...
> 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.