2019-06-26
2020
#graphql
Sean Smith
3263
Jun 26, 2019 ⋅ 7 min read

GraphQL vs. REST: What you didn’t know

Sean Smith Software engineer.

Recent posts:

Stop Writing REST APIs From Scratch in 2025

Writing REST APIs by hand is a thing of the past. Frameworks like tRPC, Fastify, and Hono eliminate boilerplate with schema-driven design, improving speed and safety.

Ikeh Akinyemi
Oct 14, 2025 ⋅ 3 min read
good dx is not enough component libraries featured image

Good DX isn’t enough: Why your component library still fails your team

Great developer experience feels amazing, until your design system starts breaking down. Here’s why good DX isn’t enough and what makes teams scale successfully.

Peter Aideloje
Oct 14, 2025 ⋅ 9 min read
react 19.2 what is new and what to expect

React 19.2 is here: Activity API, useEffectEvent, and more

Discover what’s new in React 19.2, which features long-awaited features like the Activity API and the useEffectEvent Hook.

David Omotayo
Oct 13, 2025 ⋅ 7 min read
ai dev tool power rankings

AI dev tool power rankings & comparison [Oct 2025]

Compare the top AI development tools and models of October September 2025. View updated rankings, feature breakdowns, and find the best fit for you.

Chizaram Ken
Oct 13, 2025 ⋅ 9 min read
View all posts

4 Replies to "GraphQL vs. REST: What you didn’t know"

  1. As you said, I see the pros and cons on both, but as you also mentioned, both have advantages and some cool behaviors.

    I prefer trust on REST APIs for operations such as create/post, update/put and delete/delete.
    But the approach taken for retrieving different sections/resources at once given by GraphQL is nice and it is something that I missed sometime while coding richer on BE/FE applications following strictly REST APIs…

    So… Once it is possible to limit timeouts and max depth queries via GraphQL (https://www.howtographql.com/advanced/4-security/) I think it worth try have balance usage on both approach, and even mix others, like QueryDSL for Java…

    Just to conclude, I have to agree totally that when mixing different approaches sometimes looks a messy and not attractive… Specially if developers look at you traditional REST API and suddenly reaches a resources which is retrieved via GraphQL, looks a bit odd/weird, not to say a Frankstein.

Leave a Reply