- How is the adoption of GraphQL compared to REST APIs?
- What popular services are providing a GraphQL endpoint?
- When would you use It aside from the cases you want to optimize the access to your service (mobile)?
- Are you using in your projects? What work, and what doesn't work?
These two videos are worth watching for the reasons: in short, it's a great way to aggregate legacy backend services. And, your client data shapes are much better, and this makes a difference when optimizing your server side (without knowing how your clients use the data, you can't really optimize, which REST doesn't tell you).
https://www.youtube.com/watch?v=H8YnVk2vhzg
https://www.youtube.com/watch?v=zVNrqo9XGOs
But, the reality is that even the biggest providers of public APIs, GitHub being the biggest example, have major holes in their offerings. For example, you can't yet make commit mutations in their API, which means you can't edit git data using their graphql API, though you can edit GitHub data... (My O'Reilly book is still relevant for this reason: https://buildingtoolswithgithub.teddyhyde.io/)
Graphql is not always the best fit, but it is really a powerful idea.
In the same way that people suggest you learn a new language each year even if you don't necessarily switch to using it full time, learning graphql will make you really think through how you access APIs.
2) The most popular one I know is GitHub's GraphQL API [1]. I made the difficult decision to rely on their API to teach GraphQL in my free book [2]. So far, there were no breaking changes for me and people love it to learn GraphQL from a client's perspective.
3)I would use it if I want to have no under-/overfetching, declarative data fetching, microservice API aggregation, ... [3]
4) Using it in personal projects and one client of mine is using it in one application to aggregate multiple microservices (each one speaking GraphQL) into one GraphQL API gateway. So far, everything works like expected. We didn't hit any rate limiting and caching issues because of the N+1 problem yet. But we are prepared for them :)
[0] https://www.youtube.com/watch?v=783ccP__No8
[1] https://developer.github.com/v4/
[2] https://www.robinwieruch.de/the-road-to-graphql-book/
[3] https://www.robinwieruch.de/why-graphql-advantages-disadvant...
We went ahead with JSON RPC
https://www.jsonrpc.org/specification
JSON/RPC is much simpler to implement and consume. You just have to expose server-side functions as endpoints and when it comes to build authentication and Authorization you can build using (Python or Typescript like) Decorator or just a Higher Order Functions which wraps the functions to be exposed to control the input and output in aspected oriented way.
It's great for our frontend team, makes things simpler for them. Mobile also benefits from less queries. Also it's great for aggregating data from multiple sources.
It does come with more plumbing, but you get better and better at it with muscle memory. If you're a tiny team, I wouldn't use it.
Learn about it here: https://pragmaticstudio.com/courses/unpacked-full-stack-grap...
I can't speak for many services that use GraphQL since we always have our own backend that we use. But I can speak a bit from my experiences using it with a number of different backends.
So first up: The number one thing GraphQL does really well is the tooling. You can have anywhere from a full-featured client for your SPA with Apollo [0] to a simple client for just one-off requests like urql[1]. You can have your schema be automatically turned into type definitions for TypeScript so everything is strictly typed from the backend to the frontend. Do you want to adopt microservices? You can offer your frontend-devs a single GraphQL-endpoint with schema stitching or Apollo Federation[2].
Also great is the ability to compose queries how you see fit. Need a sub-sub-sub entity of whatever you're querying? If the schema is properly set up, that is easily done in one request, while with REST you are potentially looking at up to 4 requests that need to be made. So from a UX-perspective it is also quite nice because there may be lower latency.
Since GraphQL is different from REST, it does require a different way of thinking by the backend developer. I've worked on one project where the developers weren't quite thinking in GraphQL, so they had fields that referred to objects by their ID instead of referring to it directly. That coupled with not having a unified schema in a microservices environment meant, that the end result wasn't much better than just using a REST API.
So I would recommend GraphQL for projects where, like the name suggests, you have a complex graph of objects or entities you need to regularly traverse. I wouldn't use it for things where in most cases a single REST-Request is all that's needed.
- [0] https://www.apollographql.com/docs/react/ - [1] https://github.com/FormidableLabs/urql - [2] https://blog.apollographql.com/apollo-federation-f260cf525d2...
I find it works well for when we need to collect information from several places at once which in our older API required several requests to REST endpoints. Now we have a single request and a much faster response time.
What's your use case? Also, how difficult is it to create and maintain the API? I hear nothing but good things about it from the frontend people, but some of the backend people I've asked about it just mutter to themselves about increased complexity then run away. Which also makes me think I need to become friends with backend people who don't mutter to themselves, but one thing at a time.
The stack is GraphQL Yoga and Prisma which simplifies things quite a bit!
