- Is it still relevant?<p>- How is the adoption of GraphQL compared to REST APIs?<p>- What popular services are providing a GraphQL endpoint?<p>- When would you use It aside from the cases you want to optimize the access to your service (mobile)?<p>- Are you using in your projects? What work, and what doesn't work?
I personally think it is amazing and relevant.<p>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).<p><a href="https://www.youtube.com/watch?v=H8YnVk2vhzg" rel="nofollow">https://www.youtube.com/watch?v=H8YnVk2vhzg</a><p><a href="https://www.youtube.com/watch?v=zVNrqo9XGOs" rel="nofollow">https://www.youtube.com/watch?v=zVNrqo9XGOs</a><p>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: <a href="https://buildingtoolswithgithub.teddyhyde.io/" rel="nofollow">https://buildingtoolswithgithub.teddyhyde.io/</a>)<p>Graphql is not always the best fit, but it is really a powerful idea.<p>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.
1) I think GraphQL is more relevant than ever. Facebook ran into the same problems like Netflix, Airbnb and Twitter and thus came up with GraphQL [0].<p>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.<p>3)I would use it if I want to have no under-/overfetching, declarative data fetching, microservice API aggregation, ... [3]<p>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 :)<p>[0] <a href="https://www.youtube.com/watch?v=783ccP__No8" rel="nofollow">https://www.youtube.com/watch?v=783ccP__No8</a><p>[1] <a href="https://developer.github.com/v4/" rel="nofollow">https://developer.github.com/v4/</a><p>[2] <a href="https://www.robinwieruch.de/the-road-to-graphql-book/" rel="nofollow">https://www.robinwieruch.de/the-road-to-graphql-book/</a><p>[3] <a href="https://www.robinwieruch.de/why-graphql-advantages-disadvantages-alternatives/" rel="nofollow">https://www.robinwieruch.de/why-graphql-advantages-disadvant...</a>
We tried to migrate an old gigantic legacy software from REST to GraphQL and left it in midway. We were just not convinced by the effort which goes into creating and maintaining the GraphQL layer.<p>We went ahead with JSON RPC<p><a href="https://www.jsonrpc.org/specification" rel="nofollow">https://www.jsonrpc.org/specification</a><p>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.
If you search for "graphql whitepaper", you may find some useful material about that.<p><a href="https://www.google.com/search?q=graphql+whitepaper" rel="nofollow">https://www.google.com/search?q=graphql+whitepaper</a>
To me "migrating from rest to graphql" feels like the new "migrating from monolith to microservices". Everyone is being told to get to graphql because of some benefits they might never need.
We're using GraphQL at Papa. Elixir postgres, absinthe exposing graphql and queries.<p>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.<p>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.<p>Learn about it here: <a href="https://pragmaticstudio.com/courses/unpacked-full-stack-graphql-with-absinthe-phoenix-react" rel="nofollow">https://pragmaticstudio.com/courses/unpacked-full-stack-grap...</a>
I have been using GraphQL professionally as a frontend developer for about 1.5 years and I think it is definitely getting more relevant now.<p>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.<p>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].<p>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.<p>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.<p>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.<p>- [0] <a href="https://www.apollographql.com/docs/react/" rel="nofollow">https://www.apollographql.com/docs/react/</a>
- [1] <a href="https://github.com/FormidableLabs/urql" rel="nofollow">https://github.com/FormidableLabs/urql</a>
- [2] <a href="https://blog.apollographql.com/apollo-federation-f260cf525d21" rel="nofollow">https://blog.apollographql.com/apollo-federation-f260cf525d2...</a>
I recently started using GraphQL/Apollo and so far it feels more "proper" than REST. I particularly enjoy how it handles queries, subscriptions, and the API explorer. It seems like the patterns it encourages could lead to some standardization in areas where developers previously had little guidance.
I'm using it at work to develop an API and I'd say that it's been a great experience. I find that it fits well with our use case.<p>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.