DEV Community


GraphQL - postponed technical debt or silver bullet?

Roman Voloboev
Full Stack developer and open-source lover
・1 min read

I've never worked with GraphQL long enough, but I get kind of feeling, it gives advantages on the first year of developing, but it takes much more than custom RESTful API later.

Curios, if somebody has statistic or observation on projects aged 3-5 years.
Are there any problems with refactoring?
Does code become too complex and takes much time to implement new features?

Discussion (1)

rhymes profile image

GraphQL is 3 years old and its first stable release is a little over 2 years old, it might be a little early to have enough data to understand if it's a boon or as you say delayed technical debt.

There's a sort of a frenzy around it as well. The obvious cons are caching, potential infinite nesting of the graph and the opaqueness at first glance, but they have been mostly solved as well. There has been a recent thread on HN about the complexity it brings with itself, especially due to Apollo's magic on the client side (people complaining that when Apollo stops working they have no idea what's going on) and the general opinion is that GraphQL might be overkill in the simplest cases which it's understandable:

If you're serving a public-facing API at massive scale, yes, GraphQL will save you bandwidth. If not, what a pain in the *. For most engineers it's a solution in search of a problem.

If you have a simple CRUD API it might be overkill.

I too don't have a long enough experience to prove or disprove your hypothesis.

The known advantages of GraphQL that should help the API evolution are the builtin schema that you carry around for free (I can fire up any GraphQL enabled tool and explore your API without reading the documentation and any GraphQL tool knows typing in advance), schema stitching, proxying of different APIs, deprecation of fields, bandwidth saving and subscriptions.

I don't see a direct correlation (nor an inherent advantage) between refactoring and API layer. If you decouple your code enough it shouldn't matter if the API layer is the public method (internal API) or a REST call or a GraphQL call.

I'm sure big projects might encounter issues with the evolution of their APIs (see deprecations or new endpoints/queries/mutations) but I have not worked with GraphQL deep or long enough to know unfortunately.

Wish we could ask GitHub or The New York Times :D

Quoting Phil Sturgeon's GraphQL vs REST: Overview:

I just hope that not too many people treat GraphQL like a shiny unicorn instead.
Swapping one false idol for another isn't going to make the API world a better place.