GraphQL can also be a performance nightmare if you aren't rewriting every GraphQL query into a single SQL query.
GraphQL kinda sucks
271–280 of 448 posts
Re: GraphQL kinda sucks
#272Check out EdgeDB, and EdgeQL
Re: GraphQL kinda sucks
#273GraphQL seems to be one of those 'bootcamp technologies'. I see it being advertised as a skill a bootcamp teaches more than I've ever seen used. I can imagine that for a junior developer the endless freedom might be quite paralysising. What I don't understand about GraphQL, is that the majority of data people deal with is simple and relational. It's rare enough to have a deep (more than 4 layers) relational data stru…
You’re right! You don’t understand GraphQL.
Re: GraphQL kinda sucks
#274Having worked in big tech and small startups, I think GraphQL is a brilliant way to solve an organizational problem that massive tech companies have. It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to…
I think an other thing with graphql is it reduces friction when trying to discover what your API should be. So what you can do is some sort of generative graphql thingie when doing your initial iteration, with the client hitting whatever is convenient (in that situation you'd just expose the entire backend unprotected). Once the needs have gelled out you strip it out and replace the graphql queries by bespoke API end…
I just have never had this as a problem having worked on many APIs at many companies. Usually we decide what we want to work on and the frontend/full stack can read the documentation / chat with the backend engineers if it’s not clear. At no point is “discoverability” a issue
Re: GraphQL kinda sucks
#275In the systems where I designed both front and backend and the API I did not need graphQl, but in many of the large companies I have come in to where things have been developed by many people over a significant length of time GraphQL really improved the frontend performance and time to release new functionality once it was introduced.
Perhaps it would have been the case if they just cleaned up and released a new Rest endpoint, but I'm not so sure.
Re: GraphQL kinda sucks
#276Earlier quoted context omitted.
> Given enough experience / skill you can make any technology fairly enjoyable Have you never used MongoDB?
https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo...
The other thing to note is that early on the default configuration was optimised to score really well on trivial benchmarks rather than production workloads - including having important safety features turned off.
A crashing MongoDB instance in default configuration was more likely to lose data irrevocably than a MySQL 3.23 MyISAM setup.
(note that while I still don't particularly enjoy using it, post-WiredTiger MongoDB is a different story so take this as a criticism of the people making choices in the early days, not at all of the current state of affairs)
Re: GraphQL kinda sucks
#277Earlier quoted context omitted.
> It's easy to construct a query which puts unreasonable load on your system. Can you give an example?
Details will depend on your schema, but the moral equivalent of “SELECT * FROM master_table” is a good start.
Have you seen the “turn your database into a graphql schema” products? I shudder at the poor souls who used those products. I mean, I assume they are decent products, but man, it’s got to be so easy to screw it up and literally expose too much…
Re: GraphQL kinda sucks
#278I tried graphql in a microservices environment and had huge headaches over schema stitching. Turns out, if you have lots of objects from disparate sources, graphql don’t like that. Now you must stitch these schemas together into an über schema roll query and use with graphql. Maybe we missed a step. Maybe we misunderstood. Maybe it was a bad decision.
I think Apollo Federation is for that: https://www.apollographql.com/docs/federation/ Worth watching some youtube tutorial videos. Here's one I watched recently (~26mins): https://www.youtube.com/watch?v=v_1bn2sHdk4
Not everything is a graphql api
Re: GraphQL kinda sucks
#279GraphQL 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.
Re: GraphQL kinda sucks
#280Earlier quoted context omitted.
I think an other thing with graphql is it reduces friction when trying to discover what your API should be. So what you can do is some sort of generative graphql thingie when doing your initial iteration, with the client hitting whatever is convenient (in that situation you'd just expose the entire backend unprotected). Once the needs have gelled out you strip it out and replace the graphql queries by bespoke API end…
I just have never had this as a problem having worked on many APIs at many companies. Usually we decide what we want to work on and the frontend/full stack can read the documentation / chat with the backend engineers if it’s not clear. At no point is “discoverability” a issue
The discoverability I’m talking about is not about knowing what the API is, it’s finding out what the API should be.