By Michael Paris

REST 2.0 Is Here and Its Name Is GraphQL

By Michael Paris

Abstract network design representing GraphQL querying data

GraphQL is a query language for APIs. Although it’s fundamentally different than REST, GraphQL can serve as an alternative to REST that offers performance, a great developer experience, and very powerful tools.

Throughout this article, we’re going to look at how you might tackle a few common use-cases with REST and GraphQL. This article comes complete with three projects. You will find the code for REST and GraphQL APIs that serve information about popular movies and actors as well as a simple frontend app built with HTML and jQuery.

We’re going to use these APIs to look into how these technologies are different so that we can identify their strengths and weaknesses. To start, however, let’s set the stage by taking a quick look at how these technologies came to be.

The Early Days of the Web

The early days of the web were simple. Web applications began as static HTML documents served over the early internet. Websites advanced to include dynamic content stored in databases (e.g. SQL) and used JavaScript to add interactivity. The vast majority of web content was viewed through web browsers on desktop computers and all was good with the world.

Normal Image

REST: The Rise of the API

Fast forward to 2007 when Steve Jobs introduced the iPhone. In addition to the far-reaching impacts that the smartphone would have on the world, culture, and communications, it also made developers’ lives a lot more complicated. The smartphone disrupted the development status quo. In a few short years, we suddenly had desktops, iPhones, Androids, and tablets.

In response, developers started using RESTful APIs to serve data to applications of all shapes and sizes. The new development model looked something like this:

REST Server

GraphQL: The Evolution of the API

GraphQL is a query language for APIs that was designed and open-sourced by Facebook. You can think of GraphQL as an alternative to REST for building APIs. Whereas REST is a conceptual model that you can use to design and implement your API, GraphQL is a standardized language, type system, and specification that creates a strong contract between client and server. Having a standard language through which all of our devices communicate simplifies the process of creating large, cross-platform applications.

With GraphQL our diagram simplifies:

GraphQL Server

GraphQL vs REST

Throughout the rest of this tutorial (no pun intended), I encourage you to follow along with code! You can find the code for this article in the accompanying GitHub repo.

The code includes three projects:

  1. A RESTful API
  2. a GraphQL API and
  3. a simple client web page built with jQuery and HTML.

The projects are purposefully simple and were designed to provide as simple a comparison between these technologies as possible.

If you would like to follow along open up three terminal windows and cd to the RESTful, GraphQL, and Client directories in the project repository. From each of these directories, run the development server via npm run dev. Once you have the servers ready, keep reading :)

Querying with REST

Our RESTful API contains a few endpoints:

Endpoint Description
/movies returns an Array of objects containing links to our movies (e.g. [ { href: ‘http://localhost/movie/1’ } ]
/movie/:id returns a single movie with id = :id
/movie/:id/actors returns an array of objects containing links to actors in the movie with id = :id
/actors returns an Array of objects containing links to actors
/actor/:id returns a single actor with id = :id
/actor/:id/movies returns an array of objects containing links to movies that the actor with id = :id has acted in

Note: Our simple data model already has 6 endpoints that we need to maintain and document.

Let’s imagine that we are client developers that need to use our movies API to build a simple web page with HTML and jQuery. To build this page, we need information about our movies as well as the actors that appear in them. Our API has all the functionality we might need so let’s go ahead and fetch the data.

If you open a new terminal and run

curl localhost:3000/movies

You should get a response that looks like this:

    "href": "http://localhost:3000/movie/1"
    "href": "http://localhost:3000/movie/2"
    "href": "http://localhost:3000/movie/3"
    "href": "http://localhost:3000/movie/4"
    "href": "http://localhost:3000/movie/5"

In RESTful fashion, the API returned an array of links to the actual movie objects. We can then go grab the first movie by running curl http://localhost:3000/movie/1 and the second with curl http://localhost:3000/movie/2 and so on and so forth.

If you look at app.js you can see our function for fetching all the data we need to populate our page:

const API_URL = 'http://localhost:3000/movies';
function fetchDataV1() {

  // 1 call to get the movie links
  $.get(API_URL, movieLinks => {
    movieLinks.forEach(movieLink => {

      // For each movie link, grab the movie object
      $.get(movieLink.href, movie => {

        // One call (for each movie) to get the links to actors in this movie
        $.get(movie.actors, actorLinks => {
          actorLinks.forEach(actorLink => {

            // For each actor for each movie, grab the actor object
            $.get(actorLink.href, actor => {
              const selector = '#' + getMovieId(movie) + ' .actors';
              const actorElement = buildActorElement(actor);

As you might notice, this is less than ideal. When all is said and done we have made 1 + M + M + sum(Am) round trip calls to our API where M is the number of movies and sum(Am) is the sum of the number of acting credits in each of the M movies. For applications with small data requirements, this might be okay but it would never fly in a large, production system.

Conclusion? Our simple RESTful approach is not adequate. To improve our API, we might go ask someone on the backend team to build us a special /moviesAndActors endpoint to power this page. Once that endpoint is ready, we can replace our 1 + M + M + sum(Am) network calls with a single request.

curl http://localhost:3000/moviesAndActors

This now returns a payload that should look something like this:

    "id": 1,
    "title": "The Shawshank Redemption",
    "release_year": 1993,
    "tags": [
    "rating": 9.3,
    "actors": [
        "id": 1,
        "name": "Tim Robbins",
        "dob": "10/16/1958",
        "num_credits": 73,
        "image": "",
        "href": "http://localhost:3000/actor/1",
        "movies": "http://localhost:3000/actor/1/movies"
        "id": 2,
        "name": "Morgan Freeman",
        "dob": "06/01/1937",
        "num_credits": 120,
        "image": ",0,214,317_AL_.jpg",
        "href": "http://localhost:3000/actor/2",
        "movies": "http://localhost:3000/actor/2/movies"
    "image": ",0,182,268_AL_.jpg",
    "href": "http://localhost:3000/movie/1"

Great! In a single request, we were able to fetch all the data we needed to populate the page. Looking back at app.js in our Client directory we can see the improvement in action:

const MOVIES_AND_ACTORS_URL = 'http://localhost:3000/moviesAndActors';
function fetchDataV2() {
  $.get(MOVIES_AND_ACTORS_URL, movies => renderRoot(movies));
function renderRoot(movies) {
  movies.forEach(movie => {
    movie.actors && movie.actors.forEach(actor => {
      const selector = '#' + getMovieId(movie) + ' .actors';
      const actorElement = buildActorElement(actor);

Our new application will be much speedier than the last iteration, but it is still not perfect. If you open up http://localhost:4000 and look at our simple web page you should see something like this:

Demo App

If you look closely, you’ll notice that our page is using a movie’s title and image, and an actor’s name and image (i.e. we are only using 2 of 8 fields in a movie object and 2 of 7 fields in an actor object). That means we are wasting roughly three-quarters of the information that we are requesting over the network! This excess bandwidth usage can have very real impacts on performance as well as your infrastructure costs!

A savvy backend developer might scoff at this and quickly implement a special query parameter named fields that takes an array of field names that will dynamically determine which fields should be returned in a specific request.

For example, instead of curl http://localhost:3000/moviesAndActors we might have curl http://localhost:3000/moviesAndActors?fields=title,image. We might even have another special query parameter actor_fields that specifies which fields in the actor models should be included. E.G. curl http://localhost:3000/moviesAndActors?fields=title,image&actor_fields=name,image.

Now, this would be a near optimal implementation for our simple application but it introduces a bad habit where we create custom endpoints for specific pages in our client applications. The problem becomes more apparent when you start building an iOS app that shows different information than your web page and an Android app that shows different information than the iOS app.

Wouldn’t it be nice if we could build a generic API that explicitly represents the entities in our data model as well as the relationships between those entities but that does not suffer from the 1 + M + M + sum(Am) performance problem? Good news! We can!

Querying with GraphQL

With GraphQL, we can skip directly to the optimal query and fetch all the info we need and nothing more with a simple, intuitive query:

query MoviesAndActors {
  movies {
    actors {

Seriously! To try it yourself, open GraphiQL (the awesome browser based GraphQL IDE) at http://localhost:5000 and run the query above.

Now, let’s dive a little deeper.

Thinking in GraphQL

GraphQL takes a fundamentally different approach to APIs than REST. Instead of relying on HTTP constructs like verbs and URIs, it layers an intuitive query language and powerful type system on top of our data. The type system provides a strongly-typed contract between the client and server, and the query language provides a mechanism that the client developer can use to performantly fetch any data he or she might need for any given page.

GraphQL encourages you to think about your data as a virtual graph of information. Entities that contain information are called types and these types can relate to one another via fields. Queries start at the root and traverse this virtual graph while grabbing the information they need along the way.

This “virtual graph” is more explicitly expressed as a schema. A schema is a collection of types, interfaces, enums, and unions that make up your API’s data model. GraphQL even includes a convenient schema language that we can use to define our API. For example, this is the schema for our movie API:

schema {
    query: Query

type Query {
    movies: [Movie]
    actors: [Actor]
    movie(id: Int!): Movie
    actor(id: Int!): Actor
    searchMovies(term: String): [Movie]
    searchActors(term: String): [Actor]

type Movie {
    id: Int
    title: String
    image: String
    release_year: Int
    tags: [String]
    rating: Float
    actors: [Actor]

type Actor {
    id: Int
    name: String
    image: String
    dob: String
    num_credits: Int
    movies: [Movie]

The type system opens the door for a lot of awesome stuff including better tools, better documentation, and more efficient applications. There is so much we could talk about, but for now, let’s skip ahead and highlight a few more scenarios that showcase the differences between REST and GraphQL.

GraphQL vs Rest: Versioning

A simple google search will result in many opinions on the best way to version (or evolve) a REST API. We’re not going to go down that rabbit hole, but I do want to stress that this is a non-trivial problem. One of the reasons that versioning is so difficult is that it is often very difficult to know what information is being used and by which applications or devices.

Adding information is generally easy with both REST and GraphQL. Add the field and it will flow down to your REST clients and will be safely ignored in GraphQL until you change your queries. However, removing and editing information is a different story.

In REST, it is hard to know at the field level what information is being used. We might know that an endpoint /movies is being used but we don’t know if the client is using the title, the image, or both. A possible solution is to add a query parameter fields that specifies which fields to return, but these parameters are almost always optional. For this reason, you will often see evolution occur at the endpoint level where we introduce a new endpoint /v2/movies. This works but also increases the surface area of our API as well as adds a burden on the developer to keep up to date and comprehensive documentation.

Versioning in GraphQL is very different. Every GraphQL query is required to state exactly what fields are being requested in any given query. The fact that this is mandatory means that we know exactly what information is being requested and allows us to ask the question of how often and by who. GraphQL also includes primitives that allow us to decorate a schema with deprecated fields and messages for why they are being deprecated.

This is what versioning looks like in GraphQL:

Versioning in GraphQL

GraphQL vs REST: Caching

Caching in REST is straightforward and effective. In fact, caching is one of the six guiding constraints of REST and is baked into RESTful designs. If a response from an endpoint /movies/1 indicates that the response can be cached, any future requests to /movies/1 can simply be replaced by the item in the cache. Simple.

Caching in GraphQL is tackled slightly differently. Caching a GraphQL API will often require introducing some sort of unique identifier for each object in the API. When each object has a unique identifier, clients can build normalized caches that use this identifier to reliably cache, update, and expire objects. When the client issues downstream queries that reference that object, the cached version of the object can be used instead. If you are interested in learning more about how caching in GraphQL works here is a good article that covers the subject more in depth.

GraphQL vs REST: Developer Experience

Developer experience is an extremely important aspect of application development and is the reason we as engineers invest so much time into building good tooling. The comparison here is somewhat subjective but I think still important to mention.

REST is tried and true and has a rich ecosystem of tools to help developers document, test, and inspect RESTful APIs. With that being said there is a huge price developers pay as REST APIs scale. The number of endpoints quickly becomes overwhelming, inconsistencies become more apparent, and versioning remains difficult.

GraphQL really excels in the developer experience department. The type system has opened the door for awesome tools such as the GraphiQL IDE, and documentation is built into the schema itself. In GraphQL there is also only ever one endpoint, and, instead of relying on documentation to discover what data is available, you have a type safe language and auto-complete which you can use to quickly get up to speed with an API. GraphQL was also designed to work brilliantly with modern front-end frameworks and tools like React and Redux. If you are thinking of building an application with React, I highly recommend you check out either Relay or Apollo client.


GraphQL offers a somewhat more opinionated yet extremely powerful set of tools for building efficient data-driven applications. REST is not going to disappear anytime soon but there is a lot to be desired especially when it comes to building client applications.

If you are interested in learning more, check out’s GraphQL Backend as a Service. In a few minutes you will have a production ready GraphQL API deployed on AWS and ready to be customized and extended with your own business logic.

I hope you enjoyed this post and if you have any thoughts or comments, I would love to hear from you. Thanks for reading!

  • adnan

    Can you please change the title, their is nothing like REST 2.0 and REST is not GRAPHQL. You only spread wrong information and terminology by these misleading titles, and many beginners assume it to be true, just because their is blog mentioning that.

    • Nilson Jacques

      Thanks for the comment, but I’m afraid the title won’t be changed. It’s a nice turn of phrase that within the space of a headline, communicates the idea that GraphQL improves upon and in fact could be seen as the spiritual successor to REST.

      • Agreed. Anyone who fights the very true “GraphQL can replace REST and do it much better” message doesn’t understand GraphQL and the major REST problems it solves. Yes, the problems GraphQL solve are already solved in the REST world, but solving those problems has been a mess of different attempts and in the end, everyone using REST and wanting those same problems solved has to put together their own “way” of doing it. GraphQL represents A SINGLE way; it’s a relatively simple to understand standard, which everyone can follow. That alone is its biggest advantage.


      • GraphQL is not a replacement..REST and GraphQL live along both are good for certain use cases..there is the hype lately for GraphQL and I hear a lot of people saying we could have gone rather with a REST if you have millions of requests per second for some static content than it is great otherwise REST has many benefits over GraphQL

        • GraphQL certainly is a replacement. If you have GraphQL you don’t need a full blown REST API next to it. That would be a waste of development time. If you already have a full blown REST API, you might not want to replace it with GraphQL, if you aren’t seeing the problems it solves. If you are starting something new, you’d be wise to start with GraphQL, because should your new thing become a large application with many client devices, you’re going to love GraphQL’s ease of use for both the front and backend devs. And lastly, REST has no benefits over GraphQL (not even HTTP caching) and GraphQL has a lot of benefits over REST. Especially it being one single standard for solving a number of REST problems along with the problems of versioning, documentation and introspection, just to name a few.

          • Michael Hibay

            REST isn’t what you think it is.

            If you had a “full blown rest API”, the only thing you would need GraphQL for is queries with joins.

            ReST most certainly does have all of the benefits you mention over GraphQL, just not the CRUD API you believe is ReSTful. Almost every point this article makes against CRUD APIs, is also true or better with a ‘full blown rest api’. and

            You really should heed the advice of others and educate yourself on the topic of RESTful design before you so publicly deride its’ perceived shortcomings (Ironically using a RESTful system which has all the benefits you claim REST doesn’t).

          • > If you had a “full blown rest API”, the only thing you would need GraphQL for is queries with joins.

            This tells me, you don’t understand GraphQL one bit. It is amazing that you think I should heed the advice of others, when you’ve obviously not made a decent attempt to learn about what GraphQL is truly about.


      • So, not only title is wrong, your knowledge is full of crap as well.

        GraphQL is neither meant to replace REST, nor any part of it is doing it as of now. First learn about it before spreading stupidity across.

        • Nilson Jacques

          I would have thought it clear from the article that GraphQL solves certain problems with using REST in web applications. For those use-cases, GraphQL is absolutely intended to be a replacement for REST. It’s a shame our choice of title offends you, but as any publication will tell you, it’s hard to fit nuance and detail into a short title and still persuade people to read!

          • The choice of your title makes it a click and bait title and not the informative one.

            And since you said GraphQL only replaces certain portion of REST, your title indeed is full of crap.

          • Yann

            go write your own articles, instead of posting annoying comments ;)

          • That’s not what he said. He said, GraphQL was developed to solve certain REST problems and it was built intentionally to replace REST because of those pains.


        • Facebook created GraphQL particularly to replace its REST APIs and the problems they were causing and it does replace them successfully. I think it is you who needs to learn more about it. There is nothing incorrect or stupid written here.

          • “Facebook created GraphQL particularly to replace its REST APIs” – says who? Because Facebook definitely never, ever said that, and never intended that as well.

            Even they clearly mentioned the intention were different multiple times over.

            I’ve no idea from where you gather your information, but it’s definitely not from official sources or intended documents.

      • Michael Hibay

        Your reply is very unfortunate because, though I had no previous opinion of SitePoint I now have a negative one. The article’s click bait title is factually incorrect, egregiously disingenuous, and willfully misleading readers where it seems your primary objective is supposedly technical education.

        GraphQL was meant to replace some functionality at Facebook previously using a CRUD API model, not ReST. As an ALTERNATIVE to a ReSTful design, GraphQL uses tunneling which makes certain types of queries – mostly join related – easier, fails to capture many of the ‘performance’ benefits of an actual ReST design. Downgrades in many important properties, and side grades in everything else except an improvement in acting as a joinable datasource. Holding back on the desire to be sarcastic, this does not sounds like a ‘spiritual successor’ to me.

        You should be happy that you have so many knowledgeable people offering to contribute to the improvement of your library, however it appears you would rather maintain the click bait title over educating your users. I understand coming up with a title with hook is tough, but one of your primary constraints should probably be to not outright lie.

        I’ll keep this post referenced for examples of outright falsehoods published under the guise of propaganda.

        • Nilson Jacques

          We take the quality of our content very seriously, and work to try and keep our articles up-to-date and accurate. If anyone points out a factual error with the content of the article then we’ll be more than happy to update it.

          I’m sorry you feel so strongly that the title is misleading, but I think you’re being overly literal in your interpretation. I think very few people would understand from the title that GraphQL is the literal replacement for REST APIs, much in the same way you can say “orange is the new black” and the average person understands it’s meant in a metaphorical sense.

          Anyone who forms their opinions of a topic based on the headline of an article rather than the content is misleading themselves.

          • Michael Hibay

            Absolutely nothing about calling GraphQL REST 2.0 is factually correct, nor is it in any shape or form reasonable. You try to allay the blame of being disingenuous by saying it’s the reader’s job to be mindful yet your sites very existence is to educate the ignorant! They are your target audience! How exactly are they supposed to understand how your title is misinforming them? The article certainly doesn’t go on to clear it up.

            GraphQL is a replacement for some of Facebook’s ‘Rest’ API implementations, or more accurately CRUD APIs. It doesn’t and can’t replace REST, the statement would still be wrong even if Facebooks APIs were actually RESTful. The entire article is based upon a fundamental ignorance of REST, which can be implemented to be equivalent or superior to GraphQL in every way with the exception of supporting joins. That last point can even be argued as possible in a RESTful implementation with support for specific filtering schemes like OData.

            Look in the comments section, many have pointed out factual errors. These aren’t opinions, these are facts. The title isn’t stretching the truth, its flat out false. Now, after factually challenging the entire premise of this article, what will you do about it?

        • I don’t know about others, but first thing I did after reading this article was to unsubscribe from Sitepoint’s RSS feed. It’s not only amazingly misleading article (not just the title), but author is not ready to listen to even sane arguments.

          Also, REST has a proven record of success, and GraphQL has only one record of usage – by the company which created it.

  • Or Carmi

    Greater article! A great introduction to GraphQL!

  • Nuno Ferreira

    Although you do provide a code example how to do the REST query, you don’t provide any code example how to do the GraphQL query.
    It’s only fair that you provide both code examples to be compared against. (preferably using jQuery).

  • Azeem Md

    Looks like it is similar to OData which is more standard query language.

    • Correct, sort of. I disagree with “more standard”. With GraphQL, you can’t avoid the query language, as that IS how GraphQL works. With REST, you can do a REST API without OData, thus, from a standardization standpoint, GraphQL wins out hands down.


  • Ben Bankes

    GraphQL seems great for the “read” part of CRUD. I wonder why creating, updating, and deleting entities was not included in this article.

    • Good point! It should be very clear that “mutating” data is relatively simple with GraphQL too.

      Something else missed, but probably because it is very new, is the fact that GraphQL now also supports subscriptions, which allows for real time updating APIs. So, not only is it possible to mutate data with GraphQL, but those changes, should there be subscriptions available for those changes, will be updated to clients automatically. That is another notch in the belt for GraphQL’s abilities to replace REST APIs and do a better job at it too.


  • Robert Gremillion

    I get these errors when I run inside of the directories. How can I fix this?

    npm ERR! Darwin 16.5.0
    npm ERR! argv “/usr/local/bin/node” “/usr/local/bin/npm” “run” “dev”
    npm ERR! node v7.10.0
    npm ERR! npm v4.2.0
    npm ERR! file sh
    npm ERR! code ELIFECYCLE
    npm ERR! errno ENOENT
    npm ERR! syscall spawn
    npm ERR! imdb-client@0.0.1 dev: `babel-watch src/index.js`
    npm ERR! spawn ENOENT
    npm ERR!
    npm ERR! Failed at the imdb-client@0.0.1 dev script ‘babel-watch src/index.js’.
    npm ERR! Make sure you have the latest version of node.js and npm installed.
    npm ERR! If you do, this is most likely a problem with the imdb-client package,
    npm ERR! not with npm itself.
    npm ERR! Tell the author that this fails on your system:
    npm ERR! babel-watch src/index.js
    npm ERR! You can get information on how to open an issue for this project with:
    npm ERR! npm bugs imdb-client
    npm ERR! Or if that isn’t available, you can get their info via:
    npm ERR! npm owner ls imdb-client
    npm ERR! There is likely additional logging output above.
    npm WARN Local package.json exists, but node_modules missing, did you mean to install?

    npm ERR! Please include the following file with any support request:
    npm ERR! /Users/robertgremillion/.npm/_logs/2017-05-20T13_15_04_653Z-debug.log

    • Nilson Jacques

      Hey Robert, it looks like you need to run npm install first to download the dependencies.

      • Robert Gremillion

        Works now! Awesome. Thanks for the help!

  • tomByrer

    I had thought GraphQL would be REST2.0, but since you have to tune (extra programming) complicated queries, it loses the ‘easy to use’ title for me. More like REST1.5 IMHO. Good in some situations.

  • Ryan H

    Although the title seems to have drawn some controversy, it certainly inspired me to click the bait and take GraphQL more seriously as I progressed through the article.

    Although the comparison has been drawn that REST is set of architectural guidelines and GraphQL is a technology, I think this comparison misses the key point that GraphQL introduces a layer of infrastructure to interact with various aspects of the back-end stack (like a REST API or a triple store) however whilst it is utilising the simplicity of a single end-point and a query language, therefore introducing a new set architectural guidelines that will need to be used in the case of using GraphQL which will also incorporate the well-known guidelines specified under REST so drawing a comparison to an evolution of REST to REST 2.0 is completely warranted imo. (I wrote my dissertation on SOAP, REST and Ontologies. Query languages like SPARQL are the key to interacting triple stores to make big data work for any application so if GraphQL helps to modernised the APIs and increase maintainability whilst also enabling powerful big data type queries over application’s data stores then GraphQL certainly appears the be an evolution of your bog standard REST APIs furthering the power Service Oriented Architecture under which underpins rules that all APIs should seek to implement).

    • Hey. Someone who gets GraphQL too! Welcome to the club.:-) GraphQL is actually more like a typed RPC language. If you’ve also looked at gRPC, you’ll see a good number of similarities.

      As you’ve mentioned, the true beauty of GraphQL is it’s finally one single standard, which also intentionally avoids a number of pains one would get at any type of scale with REST. I think this “one single standard”, or as you put it, “technology”, is what makes it better. REST can be any number of “things” and that makes ubiquitous interoperability between third party services impossible. Everyone has to learn how the other’s REST API works, before they can use it. With GraphQL, if everyone is doing it according to spec, everyone will be sharing and mutating data the same way. And at the same time, it simplifies client code production. In fact, the next logical step is instead of just introspection, it would be to build client code automatically, like gRPC or rather protbuffs offers. You make a call to build the API an voila, you’ve got it.


  • Denis Demchenko

    LOL. Have the author heard about including data? E.g. when you wanna request a list of videos you can include all the videos and all the authors in response? You don’t need to create so many requests as you have shown for REST. Looks, like you don’t know how to use REST.

  • “which it does not replace but rather compliments”

    In what use cases would GraphQL compliment REST? It is strange to me that this misconception is being said so often and even by someone who says they are an advocate of GraphQL. Yes, even Facebook says you should probably do authentication over a separate API. Transferring files might be another. But, where else should a RESTful API be used next to a GraphQL end point and why would it be needed?

    Put another way, where Facebook and now Github use GraphQL, they don’t have complimenting REST APIs next to it. From my understanding, they simply aren’t needed, because GraphQL covers any data retrieval or mutation requests. So, I am wondering if you know something they don’t. If you do, I’d love to learn it too. Maybe I am wrong in my understanding.


  • You are right that it’s not only a technology, but also a spec. However, it is a spec, which is defining a technology. :-) It’s sort of splitting hairs, wouldn’t you say?


Get the latest in JavaScript, once a week, for free.