Comment by hashmap

Comment by hashmap 2 days ago

3 replies

> GraphQL isn’t bad. It’s just niche. And you probably don’t need it.

> Especially if your architecture already solved the problem it was designed for.

What I need is to not want to fall over dead. REST makes me want to fall over dead.

> error handling is harder than it needs to be GraphQL error responses are… weird. > Simple errors are easier to reason about than elegant ones.

Is this a common sentiment? Looking at a garbled mash of linux or whatever tells me a lot more than "500 sorry"

I'm only trying out GraphQL for the first time right now cause I'm new with frontend stuff, but from life on the backend having a whole class of problems, where you can have the server and client agree on what to ask for and what you'll get, be compiled away is so nice. I don't actually know if there's something better than GraphQL for that, but I wish when people wrote blogs like this they'd fill them with more "try these things instead for that problem" than simply "this thing isn't as good as you think it is you probably don't need it".

Dibes 2 days ago

If isomorphic TS is your cup of tea, tRPC is a nicer version of client server contracting than graphql in my opinion. Both serve that problem quite well though.

  • hashmap 17 hours ago

    I do like the look of this! It seems like it nicely provides that without like kicking you into React, which I have ended up having to draw a hard line against in development after my first couple experiences not only with it, but how the distributions in AI models make it a real trap to touch. I'll swap this in in one of my projects and give it a go. Thanks!

    • Dibes 16 hours ago

      No problem! I hope you have a good time with it!