541–550 of 721 posts
Earlier quoted context omitted.
What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?
From https://graphql.org/learn/queries/ This isn't even close to valid json: { empireHero: hero(episode: EMPIRE) { name } jediHero: hero(episode: JEDI) { name } }
Earlier quoted context omitted.
GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a…
> In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple. You should log deprecation warnings. But also if the client is composing urls/params manually then you are not doing REST, you are doing RPC. Rest APIs should mainly use HATEOAS hyperlinks to obtain a resource.…
Earlier quoted context omitted.
It seems there is a recent trend of using adapters that expose data stores over graphql automatically, which is kind of scary. The graphql usage I'm used to works more or less the same as REST. You control the schema and the implementation, you control exactly how much data store access is allowed, etc. It's just like REST except the schema syntax is different. The main advantage of GraphQL IMO is the nice introspect…
Not particularly scary. For something like Hasura, resolvers are opt-in, not opt-out. So that should alleviate some of your concerns off the bat. For Postgraphile, it leans more heavily on the database, which I prefer. Set up some row-level access policies along with table-level grant/revoke, and security tends to bubble up. There's no getting past a UI or middleware bug to get the data when the database itself is de…
> I can send a GraphiQL URL to most junior devs with little to no SQL experience, and they'll get data to their UI with less drama
But that's like giving direct (read) database access to someone that was taught the syntax of SQL but not the performance implications of the different types of queries. Sure, they can get the data they want; but the production server may fall over when someone hits the front end in a new way. Which is, I think, what a lot of people are talking about when they talk about GraphQL having load issues based on the front end changing their call.
Earlier quoted context omitted.
> anything being pushed by big tech companies usually in 80% of the cases works for them, but its an overkill for smaller scale projects. > asp.net, angular or blazor front-end Since when are these not technologies pushed by big tech companies? A company I worked with got badly burned by AngularJS.
I have used Angular since version 5. I have never had any major issues or problems with it. Think of it this way: GraphQL, Docker, and Kubernetes solve problems that very, very, very few GIANT tech companies have, but not every app will scale to millions of users.
Because of my experience, I feel that your position is making a slim distinction based on your preferences. All the tech you use is built for big corporations, why pick on one set of tech just because you don’t have the specific problems it solves?
For me, for example, K8s properly solves a bunch of problems for my small SaaS business, not least of which is that I can upgrade my three piddly servers without taking my customers offline. My SSL certs get upgraded automatically without downtime. My CICD pipeline is simple. Logging is much easier. And so on.
I don’t understand the disdain for modern, managed K8s at all.
Worked with GraphQL from 2017 to 2021. It was the last tech "hype" I bought into. At first, it made a lot of sense and the thing that got me was the structure. But eventually, I realized how much extra work and duplication of everything there was. At the time, too, things that should have been easy like subscriptions had a nightmare API packed with weird terminology that made implementing simple features a slog. The…
I'd much rather find out the hard way that I need something than find out the hard way that I don't. There was one project where OpenAPI became a bit painful and I rediscovered why GraphQL could make sense, but it didn't reach the threshold.
I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…
GraphQL absolutely feels like a technological solution to an organizational problem. What if your front-end team wants to write crazy queries and your back-end team wants to build their resume doing Real Engineering, but what you actually need is just a CRUD app? Now your backend devs aren't bored writing "business logic" and your front end devs aren't bored waiting for your backend devs. You have a new class of insc…
Sometime in 2022 we switched back to REST endpoints for all of the reasons listed in the OP's article. Didn't hurt that we had hired for more fullstack engineers rather than "frontend only", so they saw exactly why we wanted to make the switch.
EDIT: to be fair, using Graphql and Hasura absolutely did help us iterate more quickly early on. But once we had a firmer idea of what we wanted to build, switching to REST was the right call. One of our most talented engineers wrote some helpers to make sure the frontend types were synced up with the backend types and that pretty much replaced the main benefit of using Graphql.
[0] https://hasura.io/events/hasura-con-2021/speakers/peter-down...
Earlier quoted context omitted.
What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?
From https://graphql.org/learn/queries/ This isn't even close to valid json: { empireHero: hero(episode: EMPIRE) { name } jediHero: hero(episode: JEDI) { name } }
Of course the query itself is not json, why should it be? It describes the shape of a json object, and queries are generally pretty static. But the request to the server is json, the request variables are json, the result is json, and all the json tooling can be used in the responses in our clients.
Honestly, one of the reasons I like GraphQL is the fact that underlying it all is just JSON.
We don't have mobile app and don't even plan, but if we do, we always can implement some rest api.
Earlier quoted context omitted.
and I strongly agree with GP because those arguments https://graphql.org/learn/schema/#arguments > can get to be insaneo with anything other than simplistic "episode: EMPIRE"; I regrettably can't link directly to it but https://docs.github.com/en/graphql/reference/objects#:~:text... shows that stuff can start to be more than the interior field selection, to say nothing of schemas that define complex typed arguments e…
That has some json-ish embedded inside it, but the query itself still isn't json. And even the embedded part isn't valid json without quoting the keys.
JSON is great (though not perfect) as an interchange format, but it’s decidedly not a query language.
Earlier quoted context omitted.
Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.
Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.