4 ms·
> Be careful with anyone with a take that says some technology is 100% bad always. THIS 100%. > It takes very high skill to use GraphQL well. But if you pull
by chpmrc 4y ago
> Be careful with anyone with a take that says some technology is 100% bad always.
THIS 100%.
> It takes very high skill to use GraphQL well. But if you pull it off it can be an incredibly productive system that is friendly to integration and refactoring.
I could not agree more. It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. And then it's hard to imagine going back to something more "primitive" (i.e. what's conventionally called "REST").
After building "RESTful" APIs for years I can confidently say GraphQL (with a decent implementation) is a step up across almost every possible dimension (performance aside because of the additional parsing).
- throwawaymaths 4y agoEh I think "rest for external API access, graphql for internal frontend use" is probably a good thing.
- necovek 4y ago> It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. While this is true, I think the ultimate assesment of a technology is how easy is it for someone skilled at doing similar work to internalize the model and abstractions. A tech stack can become really successful only if this is easy and relatively quick, otherwise, it will meet a lot of resistance. Partly because it's hard to master, but partly because so many people will be misusing it (which makes an even bigger annoyance for someone who's trying to get to a proper mental model). As such, I've come to appreciate only models that majority of developers can easily get right on the first go: or rather, models which are hard to get wrong.