291–300 of 448 posts
Its guide "RPC vs GraphQL/REST"[2] explains you when to use GraphQL and when not.
[1]: https://telefunc.com/ [2]: https://telefunc.com/RPC-vs-GraphQL-REST
Earlier quoted context omitted.
> Graphql is a terrible piece of software/paradigm. Says who, exactly? What data are you basing this on? Or is it a completely subjective opinion dictated by frustration likely caused by the lack of understanding of it?
Did you try reading the thread? What do you mean by data? > Or is it a completely subjective opinion dictated by frustration likely caused by the lack of understanding of it? You can ask this this very same question when people say graphql is an amazing piece of software/paradigm, except s/frustration/hype/
And, in general, there's no such thing as a "good" or a "bad" technology, there are dimensions and each dimension is a spectrum: utility, adoption, availability, cost, complexity (although hard to determine), etc. to compress all that down to "hype" or "it sucks" just show how little time has been spent on understanding the nuances I mentioned above.
I don't claim GraphQL is amazing or even good, it just proved to be a great way to build APIs for the projects I worked on. I'm sure someone who builds firmwares for embedded automated plumbing systems would disagree (within that context). If you decide not to adopt it I just hope you do it after a rational, unbiased review of what the tech is capable of and what the shortcomings are, rather than "oh it's over hyped".
> Did you try reading the thread? What do you mean by data?
Please don't question whether someone read the thread or not (which is irrelevant within the scope of this discussion anyway) just because they disagree with you.
Earlier quoted context omitted.
I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.
This is something I’ve wondered as well. Coming from the military and occasionally working with spec-ops, I would say having a few “full stack” teams would be the way to go. I am just a lowly dev though, so what do I know? The separation of front/backend has always been mildly entertaining to me and I’ve worked on both teams. Btw, if you ever want to cause a political mess, just submit a PR to add a new API endpoint…
Earlier quoted context omitted.
From a management perspective, the fiction of the full stack developer that is equally skilled at everything is the easiest. You stick with that until you complicate your architecture (wisely or not) to the point where having specialists outweighs having to manage multiples queues of work and dependencies.
Worse approach imo. Nowadays a full stack dev is an intermediate Fe dev, with junior backend skills. He will make your backend un-maintainable. Get a proper master on a proper contract rate to design your architecture.
Earlier quoted context omitted.
I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.
I think you are saying why not combine specialists on one team vs the “everyone is fullstack+devops” amateur hour dystopia that is becoming all too common?
It is strange to see developers preferring to stay in their isolated environments and not wanting to touch the entire stack.
Earlier quoted context omitted.
100% agree that it’s about dependence on other teams. That said, I’d much rather that we were communicating across a well defined api boundary, rather than a graphql api. You could, of course, very easily do this with an api layer in the middle.
Nobody seems to get the idea of building software out of pieces with well defined APIs any more . I would say it's not possible to build large software without adhering to this principle but I seem to be proven wrong. You can build large poor quality software and just throw more people at it. The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the te…
Compare it to a database, what if you couldn't use random queries with SQL, but only had the option to call stored procedures?
The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. It's easy to construct a query which puts unreasonable load on your system. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. If you want to see the kind of work you actuall…
How is this a GraphQL specific problem?
I'm fine with request batching/complexity overloads/all that craziness. Most GraphQL libraries have some kind of protection mechanism in there, or allow you to artificially split up the request and forward it to your application load balancer.
I'm also fine with a lack of API versioning, especially for internal services.
Hell, I'll even tolerate the lack of dictionaries/maps because you can replicate the same data interchange by putting the key in the object you're requesting most of the time.
What I really want is to do not have to write a custom pagination wrapper type every time I write an API. Let me write a Paginated that contains a list of T and some metadata, dammit! I don't want to dump BookPaginated/PagePaginated/AuthorPaginated into different schemas!
Another thing that bothers me is how types extending an interface need to have each and every field repeated. If I declare interface Car with wheels: Int! then I don't want to have to specify wheels: Int! again inside SportsCar. Any kind of inheritance creates giant schemas and adding new types to the super type means you have to re-insert the same parameter a million times.
Combined with a well-integrated ORM, GraphQL can have serious performance improvements over REST and similar so I definitely prefer it for big applications, but there are so many things that annoy me to no end.
GraphQL can also be a performance nightmare if you aren't rewriting every GraphQL query into a single SQL query.
Same applies to REST APIs if you don’t offer batch endpoints. Most of those n+1 query examples I see thrown at GraphQL would be n+1 GETs in REST.