GraphQL: The enterprise honeymoon is over
johnjames.blog
GraphQL: The enterprise honeymoon is over
1–10 of 241 posts
Re: GraphQL: The enterprise honeymoon is over
#2Yup, honeymoon is over. Now is the time for the adult, long-term, and productive relationship.
Re: GraphQL: The enterprise honeymoon is over
#3i wrote this a few weeks ago:
https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14...
400 lines of QL vs one rest DELETE / endpoint
Re: GraphQL: The enterprise honeymoon is over
#4Yup, honeymoon is over. Now is the time for the adult, long-term, and productive relationship.
Exactly! Once its working, it can be very healthy. And especially on the client. For a very, very, very long time. We started using GraphQL at the very beginning, back in 2015, and the way it has scaled over time -- across backend and frontend -- has worked amazingly well. Going on 10 years now and no slowing down.
Re: GraphQL: The enterprise honeymoon is over
#5i wrote this a few weeks ago: https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14... 400 lines of QL vs one rest DELETE / endpoint
Feels like a schema design issue?
If your REST backend exposes a single path to remove an item, are there any reason why your GraphQL schema doesn't expose a root mutation field taking the same arguments?
Re: GraphQL: The enterprise honeymoon is over
#6i wrote this a few weeks ago: https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14... 400 lines of QL vs one rest DELETE / endpoint
Feels like a schema design issue? If your REST backend exposes a single path to remove an item, are there any reason why your GraphQL schema doesn't expose a root mutation field taking the same arguments?
yeah tell shopify, it's their api!
Re: GraphQL: The enterprise honeymoon is over
#7Earlier quoted context omitted.
Feels like a schema design issue? If your REST backend exposes a single path to remove an item, are there any reason why your GraphQL schema doesn't expose a root mutation field taking the same arguments?
yeah tell shopify, it's their api!
Exactly. If it's that verbose and painful for a public API like Shopify/GitHub (where the 'flexibility' argument is strongest), it makes even less sense for internal enterprise apps.
We are paying that same complexity tax you described, but without the benefit of needing to support thousands of unknown 3rd-party developers.
Re: GraphQL: The enterprise honeymoon is over
#8I tried graphql with hasura and it was pretty neat, but it still just seemed easier to use RPC or REST.
Re: GraphQL: The enterprise honeymoon is over
#9i wrote this a few weeks ago: https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14... 400 lines of QL vs one rest DELETE / endpoint
wut
we have a mixed graphql/REST api at $DAY_JOB and our delete mutations look almost identical to our REST DELETE endpoints.
TFA complains needing to define types (lol), but if you're doing REST endpoints you should be writing some kind of API specification for it (swagger?). So ultimately there isn't much of a difference. However, having your types directly on your schema is nicer than just bolting on a fragile openapi spec that will quickly become outdated when a dev forgets to update it when a parameter is added/removed/changed.
Re: GraphQL: The enterprise honeymoon is over
#10Yup, honeymoon is over. Now is the time for the adult, long-term, and productive relationship.
Exactly! Once its working, it can be very healthy. And especially on the client. For a very, very, very long time. We started using GraphQL at the very beginning, back in 2015, and the way it has scaled over time -- across backend and frontend -- has worked amazingly well. Going on 10 years now and no slowing down.
We haven't been using it as long but it's definitely saved us from things that were "impossible" to associate in our microservice backend.