4 ms·

Software architecture really needs to acknowledge the human aspect of building platforms. GraphQL is great solution to organizational problem of slow communicat

by tootie 5y ago

Software architecture really needs to acknowledge the human aspect of building platforms. GraphQL is great solution to organizational problem of slow communication and/or misaligned incentives between frontend and backend teams. GraphQL is essentially a self-service approach where API developers can create a flexible, open-ended data access plane that end users can consume as they wish. That incurs a lot of extra technical complexity, but obviates a lot of organizational complexity. That could be a very valid concern if your backend is public or otherwise serves a really diverse group of clients. The most efficient and effective API integration projects I've done is where the API and frontend teams are tightly knit, working off a shared backlog and able to pass a chain of requirements from design, to contract writing, to development on both sides and get really tight alignment. That lets us create very tightly optimized REST endpoints that are very cache-friendly and can deliver precise payloads to optimize both round trips and bandwidth. It's actually easier to build because requirements are really clear, but comes at the cost of doing all that communication to align on requirements.

dhzhzjsbevs 5y ago
Pretty much this sums it up. I still don't understand the need for graphql. Then again, it only takes me 5 minutes to add a new endpoint that just dumps back a specific SQL query result. I think a lot of companies make adding endpoints into a big deal, often a whole new file or class with documentation and tests. An SQL query doesn't need tests. I think another part of it is that SQL still scares people. That is, I'd put graphql in the same camp as active record, orms, and other silly attempts at creating a query language to avoiding using a query language.
- eurasiantiger 5y ago
  >An SQL query doesn't need tests. Have you ever done financial stuff on SQL? Transaction processing or even just CRM/billing? Spend 15 minutes imagining a single query that fetches invoices, combines them with bank transaction data and produces a categorized list of unpaid-but-not-late, unpaid-and-late, not-fully-paid-but-not-late, not-fully-paid-and-late, fully-paid-in-time and paid-too-much invoices for this year’s billing cycle, selected from tables that contain info for all historical years too. You want to have tests for those.
  - dhzhzjsbevs 5y ago
    You'll need tests for those on graphql too. I was referring to how hard some companies make it to ship basic code. The graphql setups I've had to work with are all far more complicated than a function that returns an array and if your framework needs more than that to dump it out on an http request, you've got problems, but SQL isn't it.
    - eurasiantiger 5y ago
      GraphQL also has advantages that are otherwise difficult to realize, at least without an API schema. Request and response validation and object-level caching come to mind. How would you otherwise share cached objects between API endpoints? Need to set up a custom redis integration. With GraphQL, such things often come in nicely wrapped packages.

by tootie 5y ago

dhzhzjsbevs 5y ago

Pretty much this sums it up. I still don't understand the need for graphql. Then again, it only takes me 5 minutes to add a new endpoint that just dumps back a specific SQL query result. I think a lot of companies make adding endpoints into a big deal, often a whole new file or class with documentation and tests. An SQL query doesn't need tests. I think another part of it is that SQL still scares people. That is, I'd put graphql in the same camp as active record, orms, and other silly attempts at creating a query language to avoiding using a query language.

eurasiantiger 5y ago
>An SQL query doesn't need tests. Have you ever done financial stuff on SQL? Transaction processing or even just CRM/billing? Spend 15 minutes imagining a single query that fetches invoices, combines them with bank transaction data and produces a categorized list of unpaid-but-not-late, unpaid-and-late, not-fully-paid-but-not-late, not-fully-paid-and-late, fully-paid-in-time and paid-too-much invoices for this year’s billing cycle, selected from tables that contain info for all historical years too. You want to have tests for those.
- dhzhzjsbevs 5y ago
  You'll need tests for those on graphql too. I was referring to how hard some companies make it to ship basic code. The graphql setups I've had to work with are all far more complicated than a function that returns an array and if your framework needs more than that to dump it out on an http request, you've got problems, but SQL isn't it.
  - eurasiantiger 5y ago
    GraphQL also has advantages that are otherwise difficult to realize, at least without an API schema. Request and response validation and object-level caching come to mind. How would you otherwise share cached objects between API endpoints? Need to set up a custom redis integration. With GraphQL, such things often come in nicely wrapped packages.