GraphQL kinda sucks

but beginner to mid level developers are lead down the path of USE GRAPHQL especially on youtube... and this is just unfair and wrong.

The good:

- It makes working with describing the data you want easy

- It can save you bandwidth. Get what you ask for and no more

- It makes documentation for data consumers easy

- It can make subscription easier for you to use

- Can let you federate API calls

The bad

- It is actually a pain to use, depending on the backend you are using you'll have to manage

two or more type systems if there are no code first generates in your language

- It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be

some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere

- No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03

Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for

Invest your time in a simpler solution then running to GraphQL first

thanks for reading my ted talk

please any senior dev's drop your wise words so that any new dev's can avoid tarpits

In reality, of course API versioning is needed.

The "prevailing wisdom" is people who like the tool, don't like its limitations, and want to pretend it isn't a problem.

.

> That said, versioning of a graphql api has been done at scale before. Shopify has done it

Perl people will happily point out that object systems exist for Perl.

Having it not be a standard, uniform part of the core tool is a severe limitation. Shopify needed this rudimentary feature, and tried to give it away because others need it to, and the tool vendors aren't willing (or able) to deliver.