3 ms·

I absolutely love the idea of these "thin layer over the DB" systems that turn a database into a "mostly-fledged" API, but my biggest problem with them is the e

I absolutely love the idea of these "thin layer over the DB" systems that turn a database into a "mostly-fledged" API, but my biggest problem with them is the edge cases. When I need to drop out of the system and do something more, most of them require very specific "plugins" or "tools" to integrate with the system, locking you to that technology pretty hard, and often being difficult to achieve exactly what you need in anything resembling "ideal". Sometimes I need a unique authentication model which is difficult to model with these systems, or I need to do some data conversion or processing on top of what is being stored/retrieved, but only in one small part. I'd love one of these kinds of things that is flipped around. Let me create the server, let me write the authentication and user system in the application language, then let me define which endpoints I want the "automatic" system to do the heavy lifting on. Not only would this alleviate my fears of lockin to a technology that might die in a few years, but it would also allow me to start adding it to current projects easily.

BenjieGillam 9y ago
Hi, PostGraphile maintainer here. Excellent points! This is actually where the powerful GraphQL ecosystem comes in really handy - with functionality such as GraphQL schema stitching (e.g. graphql-weaver) you can use something like PostGraphile to rapidly build your MVP and easily augment it, extend it or combine it with other GraphQL schemas to build exactly what you need. You could also use something like graphql-binding from graph.cool to build your dream GraphQL schema, and then just call out to PostGraphile under the hood - there's no need to expose the PostGraphile schema directly to the public if you don't want to! With version 4 of PostGraphile I've been really concentrating on the ways that people might want to customise or extend the system, whilst also giving it a welcome speed boost (and reduced memory usage). We're pretty close to a v4 beta now :)
- Klathmon 9y ago
  That's actually fantastic news! I haven't really used GraphQL all that much outside of playing with it a few times, but it's something I really would love to use in a few projects as it solves some very real problems in a really elegant way. And having something like this layered on top might make a switch over to GraphQL possible in a timely manner.
- schickling 9y ago
  I 100% agree with what Benjie said. With things like schema stitching (see https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405 https://blog.graph.cool/graphql-schema-stitching-explained-s...) it's getting super simple to compose GraphQL APIs and therefore use PostGraphile as a "GraphQL database". Static GraphQL bindings even allow to take this even a step further by mapping the GraphQL API capabilities to your (typed) programming language. This kind of gives you a typed "GraphQL ORM" without the typical downsides of a ORM (performance, API limitations etc). If you're interested, this blog post further describes these concepts: https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...
chatmasta 9y ago
Seems like you could do exactly that, by running your own GraphQL server and, default proxying requests to the PostGraphile server, and handling more specific endpoints yourself.
- Klathmon 9y ago
  In theory, however that's a lot of added complexity. Maintaining 2 systems, managing upgrades, schema updates, scaling, and more all becomes much more complicated with that. A large part of the "value add" of something like this is that it's simple and easy to maintain, and doing a 2-stage system like that kind of removes that benefit somewhat.
  - BenjieGillam 9y ago
    From my chat with graph.cool the other day it seems like graphql-bindings would be a very thin wrapper that also can be auto-generated from a GraphQL schema (e.g. PostGraphile), so there shouldn't be too much additional complexity, and I don't think there's any major reasons they couldn't run in literally the same Node.js process. DISCLAIMER: I've not got around to trying this yet.
    - schickling 9y ago
      Yes, this simply runs in the same Node.js process (or any other programming language really) and doesn't add any complexity. Under the hood it's simply delegating your GraphQL queries to another GraphQL API (e.g. PostGraphile or Graphcool) – think of this as a smart HTTP request forwarder. In terms of the API you're using, you can either use a "dynamic" GraphQL binding which uses method introspection (e.g. via JS proxies) or a generated "static" GraphQL binding which maps the GraphQL type system to your programming language. This way you can catch errors at build/compile time and get auto-completion functionality like in GraphiQL/Playground. Check out this article for some more details: https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...

BenjieGillam 9y ago

Hi, PostGraphile maintainer here. Excellent points! This is actually where the powerful GraphQL ecosystem comes in really handy - with functionality such as GraphQL schema stitching (e.g. graphql-weaver) you can use something like PostGraphile to rapidly build your MVP and easily augment it, extend it or combine it with other GraphQL schemas to build exactly what you need. You could also use something like graphql-binding from graph.cool to build your dream GraphQL schema, and then just call out to PostGraphile under the hood - there's no need to expose the PostGraphile schema directly to the public if you don't want to! With version 4 of PostGraphile I've been really concentrating on the ways that people might want to customise or extend the system, whilst also giving it a welcome speed boost (and reduced memory usage). We're pretty close to a v4 beta now :)

Klathmon 9y ago
That's actually fantastic news! I haven't really used GraphQL all that much outside of playing with it a few times, but it's something I really would love to use in a few projects as it solves some very real problems in a really elegant way. And having something like this layered on top might make a switch over to GraphQL possible in a timely manner.
schickling 9y ago
I 100% agree with what Benjie said. With things like schema stitching (see https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405 https://blog.graph.cool/graphql-schema-stitching-explained-s...) it's getting super simple to compose GraphQL APIs and therefore use PostGraphile as a "GraphQL database". Static GraphQL bindings even allow to take this even a step further by mapping the GraphQL API capabilities to your (typed) programming language. This kind of gives you a typed "GraphQL ORM" without the typical downsides of a ORM (performance, API limitations etc). If you're interested, this blog post further describes these concepts: https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...

chatmasta 9y ago

Seems like you could do exactly that, by running your own GraphQL server and, default proxying requests to the PostGraphile server, and handling more specific endpoints yourself.

Klathmon 9y ago
In theory, however that's a lot of added complexity. Maintaining 2 systems, managing upgrades, schema updates, scaling, and more all becomes much more complicated with that. A large part of the "value add" of something like this is that it's simple and easy to maintain, and doing a 2-stage system like that kind of removes that benefit somewhat.
- BenjieGillam 9y ago
  From my chat with graph.cool the other day it seems like graphql-bindings would be a very thin wrapper that also can be auto-generated from a GraphQL schema (e.g. PostGraphile), so there shouldn't be too much additional complexity, and I don't think there's any major reasons they couldn't run in literally the same Node.js process. DISCLAIMER: I've not got around to trying this yet.
  - schickling 9y ago
    Yes, this simply runs in the same Node.js process (or any other programming language really) and doesn't add any complexity. Under the hood it's simply delegating your GraphQL queries to another GraphQL API (e.g. PostGraphile or Graphcool) – think of this as a smart HTTP request forwarder. In terms of the API you're using, you can either use a "dynamic" GraphQL binding which uses method introspection (e.g. via JS proxies) or a generated "static" GraphQL binding which maps the GraphQL type system to your programming language. This way you can catch errors at build/compile time and get auto-completion functionality like in GraphiQL/Playground. Check out this article for some more details: https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...