Graphql vs. rest

Welcome To The New Revolutionary Era of API’s !

First of all, I want to clear that GraphQL is not any database most of the people think!

_GraphQL.

Choosing GraphQL gives you easy to design and amazing to consume API. It also rewards you with effortless consistency between the APIs. By its nature, GraphQL is contract-driven and comes with introspection, which is something REST lacks out-of-the-box.

The cost you pay is that your clients have to read the docs (GraphQL schema) at the development time and hardcode the affordances (queries and mutations). This hardcoding of the development-time knowledge leads to clients tightly coupled to the server, but the same also applies to so-called-REST APIs.

Using GraphQL also leaves you vulnerable to what HTTP protocol and the whole internet infrastructure already solved: Scaling, performance, network communication mechanics, and concepts like content, language negotiation, and many others. Some of these can be “added” to a GraphQL API but are not included in-the-box. Adding the functionality that otherwise comes with HTTP leads to bike-shedding. And unfortunately, these home-made-solutions destroys the genius of consistency between GraphQL APIs.

Conclusion

Some similarities and differences already:

- Similar: Both have the idea of a resource, and can specify IDs for those resources.

- Similar: Both can be fetched via an HTTP GET request with a URL.

- Similar: Both can return JSON data in the request.

- Different: In REST, the endpoint you call is the identity of that object. In GraphQL, the identity is separate from how you fetch it.

- Different: In REST, the shape and size of the resource is determined by the server. In GraphQL, the server declares what resources are available, and the client asks for what it needs at the time.