|
|
|
|
|
|
by shantly
2426 days ago
|
|
|
Well sure they have the same capabilities from a certain perspective, in that both ultimately send data from a database to a client, but GraphQL does this entirely through a fairly free-form query language with either auto-generated or custom mapping code to turn that into DB queries (though in all cases it has to handle a fairly flexible query set or "shape", or else what's the point of using GraphQL), while PostgREST requires views and stored procedures to handle all but the most trivial cases. I think the latter's way less likely than the former to cause unexpected problems or force tons of defensive coding and cause anxious, sleepless nights—PostgREST seems to me closer to what's normal for any more traditional DB-to-HTTP-client CRUD glueware (Rails, Django—like 99% of the dynamic web, really) when it comes to inherent risk factor. Exposing a poorly-indexed table can happen in any ol' Rails API app with the usual lazy 3-line controller methods bouncing about its codebase—that's the same level of risk in any system using a database, more or less. I don't see PostgREST as being more likely to cause that to happen. GraphQL's trickier, especially from a performance perspective, because the scope of a query is so hard to determine or account for up-front, and it's hard to confidently answer the question "what's the largest possible scope of a request to this endpoint?". |
|
|
Also GraphQL is a protocol and you can't really say it will have poor performance, it all depends on the specific implementation of a particular schema. You can have a GraphQL schema where each query gets translated into a single sql query [1] jsut like with postgrest. One thing that is true is that the reference implementation for graphql servers (but only because it has to be general) pushes one in a direction where a single graphql request might generate a storm of sql queries but it's on developer to understand and write proper resolvers.
[1] https://github.com/subzerocloud/subzero-starter-kit