3 ms·

I may be biased from my past experience, but graphql tends to make codebases a nightmare if you aren't the one that initially set up the system and abstractions

by mdtusz 5y ago

I may be biased from my past experience, but graphql tends to make codebases a nightmare if you aren't the one that initially set up the system and abstractions - it's (IMO) unnecessarily complex and blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs. After Rust, I think typescript is my favourite language to write these days because of how expressive the type system is - my only complaint is that there's no clean way to bind an interface implementation to a pure data shape like you can in rust and you're forced to either use classes or some sort of DIY binding to an object prototype. As long as types are kept simple (i.e. avoid weird type tricks unless you actually need them) debugging is usually fairly straightforward assuming you have appropriate tooling setup with your editor/ide. My biggest gripe with Go is that I find myself wanting more expressivity - not just to minimize boilerplate, but to constrain the data flows and how parts of the code are allowed to fit together.

lucian1900 5y ago
And nulls. It’s frustrating that Go programs crash so often with code the compiler allowed.
ervine 5y ago
> blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs. I'd love to hear more on this, I've been feeling this way for a while when using graphql-code-generator and apollo-client with react. It feels like there's no layer between data coming into the view from the backend. Because the queries / mutations are strongly typed with typescript, we end up passing the shape of the request around as a Type, so anytime we want to change our queries, we end up having to touch a lot of application code, instead of having a nice layer between that would handle the transformation. This is exacerbated by the use of apollo-client's `useQuery` and `useMutation` hooks, which really seem to encourage you to make the requests directly from your views. At first this all feels amazing, but once the codebase is large enough, I am really start to feel like not having a data transformation layer between the requests and the views is insanity, but everything in the documentation and ecosystem seems to encourage you to do it the way I described above. This may not be at all what you meant, but I'd love to hear your thoughts, I haven't seen anyone else really talk about this.

by mdtusz 5y ago

lucian1900 5y ago

And nulls. It’s frustrating that Go programs crash so often with code the compiler allowed.

ervine 5y ago

> blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs. I'd love to hear more on this, I've been feeling this way for a while when using graphql-code-generator and apollo-client with react. It feels like there's no layer between data coming into the view from the backend. Because the queries / mutations are strongly typed with typescript, we end up passing the shape of the request around as a Type, so anytime we want to change our queries, we end up having to touch a lot of application code, instead of having a nice layer between that would handle the transformation. This is exacerbated by the use of apollo-client's `useQuery` and `useMutation` hooks, which really seem to encourage you to make the requests directly from your views. At first this all feels amazing, but once the codebase is large enough, I am really start to feel like not having a data transformation layer between the requests and the views is insanity, but everything in the documentation and ecosystem seems to encourage you to do it the way I described above. This may not be at all what you meant, but I'd love to hear your thoughts, I haven't seen anyone else really talk about this.