2022-04-05
2225
#graphql
Samson Omojola
101941
Apr 5, 2022 ⋅ 7 min read

GraphQL vs. gRPC vs. REST: Choosing the right API

Samson Omojola I'm an experienced software engineer. I love creating applications with responsive, beautiful, intuitive, state-of-the-art designs. I'm skilled in HTML, CSS, JavaScript, Ionic, React, PHP, Laravel, and Flutter.

Recent posts:

Using Aoi Js To Build A Bot For Discord

Using aoi.js to build a bot on Discord

Explore how the aoi.js library makes it easy to create Discord bots with useful functionalities for frontend applications.

Rahul Padalkar
Apr 17, 2024 ⋅ 9 min read
Web Components Adoption Guide: Overview, Examples, And Alternatives

Web Components adoption guide: Overview, examples, and alternatives

Evaluate Web Components, a set of standards that allow you to create custom HTML tags for more reusable, manageable code.

Elijah Asaolu
Apr 16, 2024 ⋅ 11 min read
Using Aws Lambda And Aws Cloudfront To Optimize Image Handling

Using AWS Lambda and CloudFront to optimize image handling

Leverage services like AWS Lambda, CloudFront, and S3 to handle images more effectively, optimizing performance and providing a better UX.

Nitish Sharma
Apr 12, 2024 ⋅ 12 min read
Building Web-Based Terminal Components With Termino.js

Building web-based terminal components with Termino.js

Explore Termino.js, an open source library for integrating web-based terminals into applications, in this introduction article.

Chibuike Nwachukwu
Apr 11, 2024 ⋅ 6 min read
View all posts

7 Replies to "GraphQL vs. gRPC vs. REST: Choosing the right API"

  1. Your description of REST cons is a good example of some common misconceptions about REST APIs. This largely stems, I think, from thinking of resources as rows/documents in your database… and this just is not the case.

    I’m not aware of anything in the REST specification that requires full transmission of a resource or even all the resources when you GET a REST endpoint. Plus any REST API I’ve worked with allows you to use “fields” and “query” query parameters to filter how many resources and how much of each resource is returned. Some APIs even default to only returning the id and an e-tag for the resource which you can later use for optimistic locking requests… and you can’t really ask for a smaller payload than that.

    Further, versioning a REST API because of fields being added isn’t necessary. You can always add information without re-versioning because the consuming code is already ignorant of it. It’s only when you remove fields where this is a problem. Or you just create a new endpoint with the new “version” of the resource and add another link in your HATEOAS that will allow applications to grab that instead.

    And lastly, I fail to see how having many vs a single endpoint affect batch processing unless you are needing to have atomicity. But even then, this can be resolved by creating a new REST endpoint that represents the collection of batch requests to the server. You make a single POST there that contains the information required to process the request, and then a GET against that endpoint can return the status of the request while PUT, PATCH and DELETE could be used to modify the request of delete it if the server has not begun processing it yet.

  2. My question to you is…. Did you check out Ankr’s api toolkit and public RPC protocol before you did this article??? Im not affiliated with Ankr but their products are top notch…

  3. There are some serious “assumptions” made here. Caching, for one, seems to be thought of a good thing and, while it is in some cases, it is the very first thing disabled (e.g. when access control is needed) in others and/or being only a necessary evil to make the thing perform acceptably (usually with REST). This also assumes a trivial implementation of GraphQL without any of the advanced frameworks, many of which are available. GraphQL requests cannot be circular and deep repetitive requests actually benefit from server-side query optimization available in those frameworks and server-side transaction caches even if we ignore any others. Think what would happen if you needed the same data with REST… hint: worse, much, much worse). Finally, the learning curve: I will claim that GraphQL, due to embedded documentation, standardization and tooling is much easier to learn for API users than any other. REST is absolutely the worst of all. On the server side, implementing GraphQL properly isn’t easy and requires some investment – explaining the common misconceptions. But REST is horrible in its own way as, no, NO, not everything is or should be a “resource”. There are actions, different kind of mutations, notifications all of which are horribly represented in REST (they aren’t really).

    1. It doesn’t come across to me like you’re judging REST fairly here. I totally believe what you’re saying reflects your experience with REST APIs, but REST is such a buzzword that anyone using an HTTP API calls it a REST or RESTful API when it either doesn’t conform to the standard or uses it too narrowly as a simple CRUD wrapper over a database.

      For example, we use REST to model actions and all sorts of mutations in our API to the point where we rarely, if ever, use verbs outside of GET and POST. Every type of action has a corresponding collection of actions against its base resource. Like /protocols/:id/submissions would be a collection of all the submission actions requested against a particular protocol. We practice CQRS so a POST against that collection causes our domain to decide whether or not to accept the command, and if it does, the protocol aggregate makes the appropriate state changes and persists them to the database.

      So yeah, if an API architect is trying to shoehorn every kind of activity into the HTTP verbs against a single /protocols/:id endpoint, then sure: actions, mutations and notifications aren’t represented well if at all. But they are in our REST API just fine. Well, not notifications, but that’s because we don’t have a use case to allow an external application to manually trigger them… we have an internal RxJS event stream that notification listeners subscribe to which in turn generate notifications when particular events occur.

      Also revisiting the learning curve issue: a proper REST API implements HATEOAS. That means that you should be able to give a user a single entry-point endpoint, and once they GET against that, you are told exactly what you can do via hypermedia. All appropriate actions with their endpoints and HTTP verbs allowed are returned along with any payloads.

      For us, this allows our API to completely drive what is displayed on our front end apps because if something isn’t authorized due to security or just the workflow state, the URL for the resource isn’t returned so the front end doesn’t even have the knowledge of how to make the request at all. The only thing the app has to know is 1) the entrypoint and 2) the link structure. We can change the entire structure of our endpoints so long as the link structure remains the same so we achieve pretty minimal coupling.

      But here’s the point: a properly constructed REST API should mean that all a human needs is the entrypoint. From there, you can just sit there with Postman and navigate through and explore the API with the information you get back… even completing business workflows and what not. You’ll need additional documentation for any payload requirements, but from what I understand, you need to have some idea of the schema a GraphQL server is running to run your mutations so I don’t see these as particularly distinct learning curves. And if you’re experience is that there is a big difference, again, I’d imagine it’s related to poor implementation on the REST side… which could be an argument in favor of GraphQL. Maybe it’s just harder to create a functional, yet difficult to understand GraphQL API, whereas it’s easy enough to make something awful “look” like a REST API.

      1. Very good explanation.

        Most people would call any ‘back-end-only-application-over-http’ a “REST” server. Where this is 100% incorrect.

        Base GET: List every field, a list of (ideally with a default page)
        POST: Insert what is minimally (at least) required [to insert anyways].
        PUT: Update providing only what fields needs updating [with any required keys].
        DELETE: Delete

        To be RESTful it MUST conform to using the proper verbs and explicitly doing what those verbs represent. It was explained in the article beautifully.

        Many applications expose endpoints that are actually routes that create a ‘headless’ application for manipulating what should be built with a graphical user interface, “programatically”. They essentially are “actions”, in a MV(a)C application, where the (a)ction [C]ontrollers allow some parameters through the route (not a query string – which is where the mistake is made in interpreting that the application is RESTful); while the application itself is mostly comprised solely of GET and POST requests. This is not REST. This is only a “server-side application designed without a dedicated GUI.

        A good RESTful programming initiative demonstrates beautifully how functionally tactful a REST server really is; and they are a beautiful implementation the only caveats exist those that are in the nature of REST being something derived in recognition that those VERBS were intended to do what they do to data in a database – now, in abstract practice – to files in a file server historically (Apache never came with support for PHP, NodeJS didn’t exist when Nginx was invented – they served and manipulated files originally – and the rest is history). In that sense, if one were to construct an engine (in PHP, leveraging the later added mod_php module in Apache, or by inventing a “GraphQL module for Apache”) that would manipulate a JSON file appropriately upon accepting a request (rather than a database) they could honestly make it work (and it would work) essentially identically to GraphQL. At that point the nuance to it would be the same nuance GraphQL has – some distinction in implementation. GraphQL is essentially the recognition of what REST does [now] and how, and a specific solution in place of it that isn’t always the best choice.

        The advantage GraphQL has (in use, not design) is SOLELY in that when viewing how we want a request to work (when using GraphQL); A request can easily provide ONLY the data requested, whereas in REST (derived as it is to wrap a database) you will need to know modifiers or alternate URIs (if they exist). However, you presume correctly that this is essentially very easy to explore and view as not being an issue at all; simply a distinction in use.

        With GraphQL a user must create their requests with only the information they need to have it limited, and with all the information if they need all; while in REST you can make the simplest request to get all the information and use an alternate URI or add a modifier to get more minimal information.

        It is extremely easy to make RESTful applications look horrible, and while easy to use REST correctly and make it look powerful and awesome it does require knowing what you’re doing in implementing it. Those diving in blind can easily, again, make it work – and make it look – horrible in implementation; it’s a concept applied over a set of technologies – there’s a lot of room for error! Ironically, it is extremely easy to make GraphQL look powerful and awesome – even by those diving in blind. It’s harder to make it look horrible, because its easy to blame the learning curve on inability to make it work – even poorly for a use case. You don’t get to decide on the implementation for GraphQL; its provided for you.

        Throwing ElasticSearch on top of GraphQL doesn’t suddenly make it better than a RESTful application; it provides a framework for doing something with GraphQL that would otherwise require experience and proper implementation. It cannot, in contrast and design, be compared to the nuance of poor implementation of a RESTful application – the latter is such a specific derivation of a technology with a much broader use-case.

        Honestly, comparing GraphQL to REST, regarding much of the argument, is like comparing a “Rocket ship” to “Transportation”. The original author did make an assumption: That the RESTful application was properly implemented.

        In the end RESTful APIs are the simplest, and the most popular, for a reason. The person you’re responding to is the one making very strong assumptions (namely that the RESTful application is not implemented properly, where GraphQL by design only has its implementation) – and its clear that they are distinctly favoring GraphQL, and biased against the idea that its not always the best to use; which often happens when someone makes a risky decision to devote themselves to one technology and dislikes the idea that something else could ever be a better choice – and apt to argue.

        I think anyone could read into the social psychology of it a bit more, but that just starts getting into unnecessary topic.

        Those coming to this article for a read should not be deterred. There are fewer functional use-cases to GraphQL over REST. They both have their place; though there exist other solutions (arguably more effective) where GraphQL would perform better in place of a RESTful service.

        I think if one is interested, they should try GraphQL out, and those interested in REST should keep in mind that it is easy to use a “framework” that supports REST the wrong way ⇨ in either case, pay strong attention to detail, read up on theory and practice, and pick what will functionally do what you need – most effectively and efficiently.

  4. This has been a great comment thread, I learnt a lot.
    @kevin and @Richard, any open-source project which would be good models to study from?
    For someone who is starting out, these articles are the easiest starting point, but one should keep learning and realize initial sources of guidance can be limited, and one should keep digging into nuances from diverse authoritative sources.

Leave a Reply