Dmitrii Profile picture
15 Sep, 22 tweets, 4 min read
A small unstructured mini-thread/mini-rant on GraphQL.

I’ve now completed server prototypes for roughly the same functionality in C#, Java, Go (twice), Elixir, and nodejs.

GraphQL exemplifies everything that’s wrong in the industry :D

1/
First, it’s supposed to bring together data from different sources, right?

All GraphQL libraries have no proper examples of that. “Let’s create an array of values and serve that”. No one ever does that in real life.

As a result in reality everything is double the code 2/
Why? Because you get your data from an external service. And usually you present this data in an only slightly different way in GraphQL.

External service may provide a client with a contract id, but you present a client with a full contract from another external service 3/
Oh, screw you. Create a separate model/entity to deserialize the external service’s data, then write a separate model/entity in your GraphQL schema. And often run a generator on that schema to create a *third* model/entity just because.

4/
It’s both significantly worse and significantly better if you don’t go schema first, but define your schema in code. This can be anything from Java’s bearable fluent interface to go-graphql’s horror show.

5/
In schema-first though it often happens that if you need some custom resolver on a single field, nope, you have to write your own model/entity by hand, and probide resolvers on that. Because screw you.

Looking at you gqlgen

6/
You’d think code-first would work. I mean, whatevr you write in code is what you want/need, right?

Wrong.

Enter Elixir’s Absinthe. Schema fields are defined in snake_case. Gets automatically converted to camelCase when requested through GraphQL.

WHY?!

It gets worse 7/
This only happens with data that Absinthe itself sends. But… you get that data from external sources, and those will often have field names in camelCase.

You have to… transform those field names manually to snake_case before providing it to Absinthe.

Because screw you 8/
Goddamn dates.

Everyone needs to work with dates and timestamps. Why the *fuck* GraphQL (and protobuf) don’t have Date, DateTime, Time and Timestamp in their specs?

Becuase their authors have never been in the real world it seems. As a result every single library ends up … 9/
… you though I’d say “implementing those as custom GraphQL scalars”. Oh, sweet summer child.

Some will onlly have DateTime. Some, like Apollo, will have two pages of explanations and code examples but *not* include it in the lib by default. 10/
Some will have them as external libraries that need to be injected and will screw up things like JSON (de)serialzation. Looking at you, graphql-java-extended-scalars. 11/
Some don't implement Date, DateTime etc. “because it’s not in the graphql spec”.

Spec is bad, you exist not to please the spec, but to help people make things. *People*. 12/
Schemas.

Code-first crowd is notorious for not being able to generate the final schema. You need some external tools that will connect to the running server, introspect the schema, and generate the schema based on that.

I literally can’t even

13/
Dataloading.

Some libs think that dataloading is for others to implement. Perhaps. Is there a better way to hook up a dataloader than providing an untyped context object, and then returning a function calling function wrappers from that object in your resolve function?

14/
The whole idea that resolvers should be able to call external services (that’s why they are there to begin with!) is almost a foreign concept in a surprising number of libs.

You can always go the Java route and inject everything everywhere, including your eyeballs. 15/
Many of these issues stem from language and conventions: Java must have beans, and registries, and dependency injection, and config objects, and profiles, and…

Go’s lack of generics leads to 1500 interfaces that are the same thing. Or casting unnamed interfaces to things 16/
Apollo is only marginally better than the rest of the crowd just because JS doesn’t care what objects you through at it.

But yeah, it will not provide useful scalars out of the box because you, the programmer, are meant to suffer

17/
Errors. Oh god, I forgot errors.

Helpful messages are for losers. Figure out “Can’t query field id on type X” yourself, you child.

Stacktraces are for losers. None will be included in the error messages, in any lib IIRC. When something fails, who cares where it fails 18/
Some will gladly dump HTML at you when you accidentally retrieve a 404 page in an external service. Others will “JSON decode error: invalid symbol p at 1:30” at you.

No other messages. It’s your job to write perfect resolvers on the first try, you incompetent turd

19/
I still think GraphQL is bad for external APIs for various reason, to lenghy to list here.

But for the backoffice and exploratory APIs it could be a very nice tool. Especially since backoffice is the one place that has to deal with backend APIs in the frontend

20/
But Christ Almighty, is it ever so painful to write a backend server that prvodes a GraphQL wrapper for your backend APIs in a straghtforward concise manner that doesn’t make your eyes bleed and doesn’t take you on an accelerated path to clinical depression.

21/21
@threadreaderapp unroll, please

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Dmitrii

Dmitrii Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @dmitriid

12 Oct 19
If you follow @troyhunt and @lukew you know how bad things are around passwords, password forms, and password requirements. At the same time you're thinking: "it can't be *that* bad, can it?"

Oh, boy. A thread with nine examples

1/12
My laptop was stolen. So I decided to go through ~300 accounts stored in my 1password looking for weak passwords, 10-year old passwords etc. And updating them.

I updated ~50 accounts. Too bad I was busy changing passwords and not taking screenshots. Here's what I found:

2/12
- If you use a password manager, you will have to copy paste the new generated password into the "New password/Reset password form".

Pasting text will not trigger form validation. You have to at least delete and re-type a character. The most common problem.

3/12
Read 13 tweets
16 Aug 18
Twitter has turned profitable. Algorithmic timelines, ads, likes surfacing etc. works. *For them* Don’t expect them to change that because you don’t like it 1/
Instagram is profitable. Algorithmic timelines, ads, stories, app that refreshes the entire feed when you blink etc. works. *For them* Don’t expect them to change it just because you don’t like it 2/
Facebook is profitable. Algorithmic feed, hate bubbles, fake news surfacing, ads, auto playing videos etc. work. *For them* Don’t expect... 3/
Read 5 tweets
14 Jul 18
Вписаться что ли в драму вокруг @5ht? :)

«О боже, человека травили 10 лет, да как вы могли, сволочи». Начнем с того, что эта виктимизация непонятна никому, кто с Сохацким общался в разных коммьюнити больше одного дня 1/n
Сохацкий — озлобленный на весь мир человек, непризанный никем гений, считающий себя превыше всех. С соответствующей культурой манерой общений.

В те моменты, когда предыдущее публичное поведение ему в чем-то мешало, он выпиливал свои комментарии, посты и т.п. 2/n
Потом все повторялось по кругу. Цикл занимал 2-3 года. Это сейчас его легко выставлять невинно пострадавшей овечкой, потому что все улики неоднократно надежно подчищены и удалены. Но все общение всегда состояло из:

- Макс, вопрос.
- Ты хуй, ты до мьеня не дорос, иди нахуй 3/n
Read 11 tweets
18 Oct 17
This attitude is exactly what prevents webpack from owning its own mistakes. Worse, it kills any discussion around Webpack 1/n
The laws of diminishing returns and all that. You solve a common problem that 80% of people face, then the next 80% etc. 2/n
Provide configurable opt-outs for people who want something else. *not* opt-ins for the most common cases out there
Read 40 tweets
15 Sep 17
Ejecting react-create-app shows just how horribly and hoplessly complicated #Javascript infrastructure has become
I mean, besides the sheer number of moving parts, a third of configuration is about fighting bugs and behaviour in another third
Literally half of the code is "why the EFF isn't this default behaviour?"
Read 34 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!