3 ms·

Think about an API like a control panel for a machine. It is precisely designed for an operator abstracting away the details of the machine's electrical schemat

Think about an API like a control panel for a machine. It is precisely designed for an operator abstracting away the details of the machine's electrical schematic and every component. It is user focused. GraphQL is like opening up the entire machine, stripping off the panels and working on live circuits. IMO GraphQL is great to quickly develop something. If your front-end is making 18 queries to REST API and you're making a case for how awesome GraphQL is, I think perhaps your REST API design needs to be properly thought out. I personally like to start with GraphQL, once everything is ready and I know what I want, write proper API endpoints. They can be REST-ful or REST-less. One API call for one function the front-end needs to perform. If the wiring in the machine changes and need fancy brushless motors are added, the operator doesn't need to worry about it. They can always replace the control panel with a new v2 version if they want additional features, but we guarantee that v1 version will continue to function. This is beautiful design. APIs don't have to be REST-ful and they should not be some kind of an analog of the backend database schema. API - it is in the name, "Interface".

lukeramsden 6y ago
> IMO GraphQL is great to quickly develop something. If your front-end is making 18 queries to REST API and you're making a case for how awesome GraphQL is, I think perhaps your REST API design needs to be properly thought out. I personally like to start with GraphQL, once everything is ready and I know what I want, write proper API endpoints. They can be REST-ful or REST-less. One API call for one function the front-end needs to perform. I think a good way of doing this is to use Postgraphile/Hasura to make a quick and easy GQL API, and then when you move to your "proper API endpoints", you can use Postgraphile in schema-only mode [0] at first, and then you have the ability to arbitrarily change endpoints to use custom SQL queries instead of using Postgraphile to build your query, while leaving other, simpler endpoints to still use Postgraphile. [0] https://www.graphile.org/postgraphile/usage-schema/ https://www.graphile.org/postgraphile/usage-schema/
- systemvoltage 6y ago
  That's very helpful, thank you!

lukeramsden 6y ago

> IMO GraphQL is great to quickly develop something. If your front-end is making 18 queries to REST API and you're making a case for how awesome GraphQL is, I think perhaps your REST API design needs to be properly thought out. I personally like to start with GraphQL, once everything is ready and I know what I want, write proper API endpoints. They can be REST-ful or REST-less. One API call for one function the front-end needs to perform. I think a good way of doing this is to use Postgraphile/Hasura to make a quick and easy GQL API, and then when you move to your "proper API endpoints", you can use Postgraphile in schema-only mode [0] at first, and then you have the ability to arbitrarily change endpoints to use custom SQL queries instead of using Postgraphile to build your query, while leaving other, simpler endpoints to still use Postgraphile. [0] https://www.graphile.org/postgraphile/usage-schema/ https://www.graphile.org/postgraphile/usage-schema/

systemvoltage 6y ago
That's very helpful, thank you!