"LeT's uSe gRaPhQL!" They said.

"It EliMinAtEs cOmpLeX aNd vErBoSe REST coDe!" they said.

Me sitting here for hours waiting for the backend team to fix major regressions every time they push the smallest "updates" to staging... 🤡

Call me a boomer but I can't help but feeling graphQL makes things MORE complex than REST... either that or the backend devs have no idea what they are doing

Maybe a little bit of both?
I'm just now leaving about GraphQL

GraphQL is great.
But you can‘t just say let‘s migrate to graphql and then expext it to magically solve the problems.
First, not everything is better with graphql.
Second, it essentially requires a complete redesign of the APIs to make any sense and to provide advantages over REST.

I would say, only use graphql for new projects. Most of the time it‘s not worth it for projects that have working REST already.

GraphQL is great for aggragaions, and datapipelines.
Bad for complex logic and processing.

I’ve used graphql on 4 production products over the last 4 years

if you have devs who know what they are doing, it can be magical

I think if you have a good understanding of it, you can actually build your graphql implementation piece mail on top of the REST api if you need - I’ve done this for certain endpoints so the functional REST api is accessed and documented through the gql schema

I disagree that it’s great for data pipelines - it can be used that way but it excels in frontend applications where proper implementations allow for pulling only the data you need while going multiple levels deep

🧵

why is it not great for data pipelines? it does not allow streaming responses, so you must load everything and send it in one response. also, if you are querying multiple levels down, a simple implementation of graphql will most likely do a lot of individual additional queries (think about querying a collection of posts and the author. each N post returned will use its resolver and make a separate query for the author)

Nothin is good if it's just crammed in brainlessly.

A Frankenstein is a Frankenstein, no matter how nice you try to cover the stitches.

This applies to everything.

We had the "No SQL" phase... And so many other phases.

Whenever devs or managers are screaming for sth like 4th year olds on sugar and caffeine rush, DON'T give in.

Say no till a solid, sane and sound plan is made.

@Lensflare graphql is _okay_ for the right applications. but for about 99% of use cases, REST is just the better tool. and most of the places where graphql is used, it's only used because some tech-lingo-hyped pointy haired boss said so.

@tosensei I disagree with the 99%.
If used correctly, many more apps would benefit from graphql. The problem is that it‘s not used correctly.

🍌

just as a side note, anyone interested in seeing the power of graphql I’d suggest checking out hasura. very cool graphql engine

Here's the only use case for GraphQL where it clearly outshines REST: you need an API that 1) has multiple target consumers that need signifiantly varying access to its resources, 2) taking advantage of browser cache is not a priority, 3) and you and your target consumers don't mind using Javascript (yes there are gql clients in most popular languages but there are subtle runtime-specific differences and ultimately the best perf & DX with GQL is in NodeJS).

Overall probably not worth the overhead for 95% of apps, but brilliant for the remaining 5%.

i still cringe over the failure of wcf

@Lensflare well, at least so far i haven't encountered a single use case where graphql would be beneficial. at least from a technical point of view.

i can give it more credit, though, if the development process is comprised of few, well-tested backend updates and lots and lots of uncoordinated frontend updates that greatly change what data exactly is needed from the backend. (aka: mismanagement)

Graphql is marvellous. But your api team need to to think about breaking changes just like they should with any api

@bebetter I think frontend is like less th@webketje @AvatarOfKaine there is now wcf for .net core. Sorry.

> feel graphql makes things MORE complicated than REST

Well, unless you had to make multiple REST API requests to get all data I don't see how graghql could make it easier.

if you have a BFF (backend for frontend, meaning the backend tailors endpoints to give the frontend exactly what is needed) that's pretty much as simple and performant as it can get

rest code doesn't need to be verbose