GraphQL Query Generator
blog.graphqleditor.com
GraphQL Query Generator
1–10 of 49 posts
Re: GraphQL Query Generator
#2Nice library, especially for testing and chaos engineering. Great Idea!
Re: GraphQL Query Generator
#3We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation.
Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints?
Re: GraphQL Query Generator
#4We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…
I concur. If you’re building an api that people can consume it makes sense because the consumer can pull only what they want. Other than that I think it’s pointless.
Re: GraphQL Query Generator
#5We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…
You are not alone. All my evidence is anecdotal, but in the last year, I sat in at least two meetings with younger devs proposing to use and older devs cautioning to use GraphQL.
I'm sure it has its uses (API with multiple frontend clients, which are changing fast), but for the classical CRUD-App, where Backend-Changes/additional routes are not super costly, I do not see the appeal.
Re: GraphQL Query Generator
#6We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…
>Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints?
You're not alone. I went down the GraphQL path a year and a half ago. I was telling everyone it was going to be the future, then I got tired. GraphQL requires a lot of configuration and setup to get working right. The decent implementations of GraphQL are all proprietary solutions like Apollo. When you feel like you're spending half your time setting up a simple backend and API, it's a red flag.
Despite efforts made to improve GraphQL, things like caching are still a nightmare are in comparison to the out-of-the-box browser caching you get with a traditional REST endpoint (because GraphQL implementations all use POST by default). No plugin I tried for Apollo gave me proper caching, I even tried to hack something together at one point.
The smaller payloads are definitely great and being able to query for specific pieces of data is fantastic, but it's a lot of work and it's not perfect. I found using it can make a simple app incredibly complex, then you have to maintain the schemas, implementing data loaders requires some work to get done right. There is a reason a lot of backend developers push back against the suggestion of using GraphQL.
Don't get me started on things like authentication, file uploads and protecting your server from being DDoSed or driving up your cloud computing bill by someone creating expensive queries. There are solutions to these things, but they require more configuration and work to get right. The fact out-of-the-box someone can create a GraphQL server and essentially make themselves vulnerable to a big AWS bill or have their app brought to its knees trying to fulfill an intentionally complicated query is kind of concerning, these things should be default settings.
I went back to REST about six months ago and never looked back.
Re: GraphQL Query Generator
#7We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…
In my last job we considered it was well (2.5-3 years ago I think), and decided it wasn't worth implementing the GraphQL server part for just a limited set of clients that could basically use a small set of REST endpoints. We were building a video streaming app exclusively for the Belgian market, so bandwidth was not a concern.
GraphQL shines when you have a big(ish) data model with a high variety of queries you want to run on the client. It's also cool if you get it for free with your tech stack, I think. But if you have to implement a complex GraphQL server stack yourself to work with existing data sources it's definitely not always worth it.
Re: GraphQL Query Generator
#8We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…
Although I haven't used it personally, I can see it being very useful for APIs where the "objects" involved contain many fields/relations. Rather than coming up with a limited set of filter/query parameters, you can take advantage of a query language with tooling.
That being said, one of the things that irks me about most* GraphQL implementations is that they seem to do joining entirely server-side. This makes sense if you have to join data across multiple services, but if you're only dealing with a single data back end (like a database) then you can't take advantage of JOINs.
If anyone knows otherwise, feel free to correct me. As I said, I don't have any practical experiences with GraphQL.
*I'm aware there are one or two GraphQL libraries that support JOINs, but most do not.
Re: GraphQL Query Generator
#9We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…
I understand where are you coming from, and you're probably right.
BUT
I'm using graphql with type-graphql and graphql-modules, on a personal project and it's gonna be just me coding it.
I guess I enjoy it for development?
Re: GraphQL Query Generator
#10We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…
> Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints?
I've used GraphQL on a couple projects I've worked on and I still don't understand all of the hype. Thankfully I've never had to set it up from the ground up but even as an end user I don't truly understand how I'm benefitting from it.