4 ms·

Part of what I'm doing is working on a CRUD backend. The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client cu

by latch 7y ago

Part of what I'm doing is working on a CRUD backend. The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client customization. There's also some neat handling around versioning and copy-on-write type behavior to provide a mix of immutability and space saving. To me, this is CRUD because: most resources literally have 4 endpoints (create, index, update and delete). We write a ton of tests to cover all the cases. It's time consuming, even tedious, and it's boring / simple compared to the user facing stuff we do. I've never touched GraphQL, so can that really save me months of work? Or would it save me about as much time as Rails would (which would be not a lot) ?

karatestomp 7y ago
Last time I looked at GraphQL it was only a time-saver if you could rely on significant amounts of automagic for the GraphQL->DB Query step. So if your use case & stack allow for that, yeah, maybe it'll save you significant time. Its main effect is to move app logic query writing to the frontend, in something that's not SQL, which some folks seem to really like. But it's still got to get turned into whatever your data sources actually speak at some point, just like REST or anything else. If there's nothing magically doing that for you or if the magic turns out to suck, you'll be doing it manually. [EDIT] to make it more clear, here are your possibilities: 1) a. GraphQL queries -> b. Queries for one or more kinds of datastore 2) a. REST requests -> b. Queries for one or more kinds of datastore You shift choices about how to query kinda forward in 1, but that means you need a very general and flexible GraphQL query handler to make step 2 happen, and if that doesn't exist or is insufficient you have to write it. That is, obviously, more work than 2, in which 2b is where the choices you'd make in 1a happen, so that layer doesn't need to be as flexible. TL;DR the apparent flexibility and responsibility-shifting of GraphQL isn't free and is in fact quite expensive (and, if I may, risky)... unless it is free because someone's already done the work, for your particular use case and stack.
tango12 7y ago
If you're up for it, I'd love to chat and see if Hasura could've worked in your case[1]! Especially on the read side, if we're able to model the authz with Hasura your API consumers get a rich read API "for free" and Hasura can delegate the CUD stuff to your existing REST APIs. Hasura aside, GraphQL will save your API consumers time more than anything else. Like the other comment/reply to this, you still have to build a GraphQL server. [1] I'm twitter.com/tanmaigo or tanmaig@hasura.io
simplify 7y ago
GraphQL by itself won't save you time, and might even increase it (it's a huge buy-in). You'd still have to implement the logic for those 4 endpoints, except now in a more complicated system. In contrast, tools like Hasura and Postgraphile can potentially save you time because they generate the GraphQL part for you. Then you only need to handle the authN/authZ parts – in theory, at least.
- pkghost 7y ago
  Auth is about 15 lines in an SQL function exposed via the api w/postgraphile, plus whatever lines necessary to define your RLS policies and grants.

by latch 7y ago

karatestomp 7y ago

Last time I looked at GraphQL it was only a time-saver if you could rely on significant amounts of automagic for the GraphQL->DB Query step. So if your use case & stack allow for that, yeah, maybe it'll save you significant time. Its main effect is to move app logic query writing to the frontend, in something that's not SQL, which some folks seem to really like. But it's still got to get turned into whatever your data sources actually speak at some point, just like REST or anything else. If there's nothing magically doing that for you or if the magic turns out to suck, you'll be doing it manually. [EDIT] to make it more clear, here are your possibilities: 1) a. GraphQL queries -> b. Queries for one or more kinds of datastore 2) a. REST requests -> b. Queries for one or more kinds of datastore You shift choices about how to query kinda forward in 1, but that means you need a very general and flexible GraphQL query handler to make step 2 happen, and if that doesn't exist or is insufficient you have to write it. That is, obviously, more work than 2, in which 2b is where the choices you'd make in 1a happen, so that layer doesn't need to be as flexible. TL;DR the apparent flexibility and responsibility-shifting of GraphQL isn't free and is in fact quite expensive (and, if I may, risky)... unless it is free because someone's already done the work, for your particular use case and stack.

tango12 7y ago

If you're up for it, I'd love to chat and see if Hasura could've worked in your case[1]! Especially on the read side, if we're able to model the authz with Hasura your API consumers get a rich read API "for free" and Hasura can delegate the CUD stuff to your existing REST APIs. Hasura aside, GraphQL will save your API consumers time more than anything else. Like the other comment/reply to this, you still have to build a GraphQL server. [1] I'm twitter.com/tanmaigo or tanmaig@hasura.io

simplify 7y ago

GraphQL by itself won't save you time, and might even increase it (it's a huge buy-in). You'd still have to implement the logic for those 4 endpoints, except now in a more complicated system. In contrast, tools like Hasura and Postgraphile can potentially save you time because they generate the GraphQL part for you. Then you only need to handle the authN/authZ parts – in theory, at least.

pkghost 7y ago
Auth is about 15 lines in an SQL function exposed via the api w/postgraphile, plus whatever lines necessary to define your RLS policies and grants.