Test: Is GraphQL Right For You?

Although GraphQL is more powerful, REST is simpler and easier to operate. Take this quick test to see which architectural style you should use for your next project.

You may have heard that REST is dead, and that GraphQL is the new norm for API centric architectures. Of course, it’s more complicated than that. But to see if GraphQL is a good match for your next project, you kind of need to spend a day reading about pros and cons.

Unless you take this two minutes test with no code, no schema, and no bullshit.

Is your architecture API-centric?

• A: No, the server delivers HTML
• B: Yes, the server delivers JSON (may include Server-Side Rendering, too)

What’s the client platform?

• A: Desktop only (PC or Mac), so mostly on Wi-Fi / Ethernet
• B: Desktop and/or mobile, so it includes usage on mobile networks

Does frontend performance matter?

• A: No, the end user doesn’t pay or has no alternative
• B: Yes, any lost second impacts the revenue / reputation

What’s the frontend deployment frequency?

• A: At most every six months
• B: Monthly or Weekly. We’re Agile!

What’s the API Size?

• A: Small (less than half a dozen routes)
• B: Moderate to large

How long will the API last?

• A: A few months (it’s a proof of concept, or a perishable product)
• B: Several years — which means it’ll change over time

What’s the API complexity?

• A: Small (CRUD-only, few or no relationships, simple filters, no complex query)
• B: Moderate to large (sub resources, aggregates, event sourcing, subscriptions, )

Do you already have a working REST backend?

• A: Yes, with clients already running on top of it
• B: No, it’s a new project

How many backends do clients request?

• A: One (usually a SQL database)
• B: More than one (several databases, search index, message queue, other REST backends, etc)

Do you have complex caching rules?

• A: Yes, implemented as route patterns rules in a reverse proxy
• B: No, it’s mostly all-or-nothing

How large is your tech team (frontend+backend developers)?

• A: 1 to 4 developers
• B: At least 5 developers

What’s the frontend and backend teams situation?

• A: Siloed (each team has their own backlog)
• B: Colocated (the two teams share the same backlog)

Is the team fluent in modern JavaScript?

• A: No, but we do jQuery stuff
• B: Yes, ES6 and webpack and functional programming FTW

What’s your preferred language?

• A: Loosely typed (PHP, JavaScript)
• B: Strongly typed (Python, Java, TypeScript / Flow)

If you have a majority of B answers, it’s a good idea to investigate more about GraphQL for your project. Otherwise, REST is good enough for your case, don’t waste time and money adding a new layer of complexity to your architecture.

This post was extracted from the Dive Into GraphQL series, which provides a (way) longer answer to the question “Is GraphQL a good fit for my next project?”. If you want more arguments in favour or against GraphQL, you’ll find them all there.