Using Elixir+Absinthe solves most of these problems and the idea that a non-self documenting API doesn’t need every field to be secure is quite frankly a ridiculous thing to label as a problem for GraphQL, maybe the self documentation encourages better security practices, who knows!?
After 6 years, I'm over GraphQL
521–530 of 721 posts
Re: After 6 years, I'm over GraphQL
#522I 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…
I think a lot of people like GraphQL because it provides strongly typed API interfaces. But I've been able to hack together a better REST alternative in full-stack typescript codebases. And my solution doesn't need to compile any kind of client or intermediary.
GraphQL gives you the ability to compose fragments, so if the UserDetail component and UserPaymentInfo component both use the user’s name, it is loaded once.
With ad hoc solutions like tRPC, you end up fetching the same field multiple times (and probably doing some sort of network waterfall), or you give up on data masking and composability. And if you have enough engineers, data masking and composability are critical to maintain velocity.
Re: After 6 years, I'm over GraphQL
#523Earlier quoted context omitted.
REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…
Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code
GraphQL gives you this. https://relay.dev/docs/guides/persisted-queries/
Re: After 6 years, I'm over GraphQL
#524One context it works well in is something like PostGraphile. You basically spend very little time developing the back end. This obviously does not scale to very large projects.
Re: After 6 years, I'm over GraphQL
#525GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…
Does TAO help? I imagine it's a lot easier to embed all this additional logic and metametametadata in a single service than distribute.
Nah, it's one level up having basically everything as an Ent (ORM object) with an associated data access policy that does that.
Re: After 6 years, I'm over GraphQL
#526Earlier quoted context omitted.
Its not JSON over XML. They're saying JSON REST won over _XML and SOAP_.
Those two are kinda orthogonal, and while there was some overlap for adoption, it was fairly common to serve XML over REST early on (because more languages and frameworks had proven-quality XML parsers out of the box, so it was easier for the clients to handle). JSON won in the end mostly because it was easier to handle in JS specifically, which is what mattered for the frontend. Then other languages caught up with t…
To claim that pretty much every .NET project adding Newtonsoft.JSON as a first step was somehow a problem is just strange. No adequate team would claim this to be a problem.
Re: After 6 years, I'm over GraphQL
#527Earlier quoted context omitted.
I think a lot of people like GraphQL because it provides strongly typed API interfaces. But I've been able to hack together a better REST alternative in full-stack typescript codebases. And my solution doesn't need to compile any kind of client or intermediary.
GraphQL gives you the ability to compose fragments, so if the UserDetail component and UserPaymentInfo component both use the user’s name, it is loaded once. With ad hoc solutions like tRPC, you end up fetching the same field multiple times (and probably doing some sort of network waterfall), or you give up on data masking and composability. And if you have enough engineers, data masking and composability are critica…
swr can handle the first issue you mentioned just fine.
Re: After 6 years, I'm over GraphQL
#528Earlier quoted context omitted.
I’ve only been a consumer of a GraphQL API, so I don’t know what it’s like to maintain, but I mostly enjoyed using it. Of course the documentation on some kinds of query syntax was too sparse, (this is for Shopify) but I could see how it might be nice for certain kinds of cases. If you run a platform it might be a good option to offer in your API. For shopify afaik there are equivalent calls in both REST and graphql…
Can you elaborate on lack of syntax docs? As far as I understand one of the big big huugge benefits of GraphQL is that you get the strongly typed schema via the introspection query, so you can build queries with some confidence, that as long as the schema (version) is the same it should be syntactically okay. What did Spotify do compared to this?
I think it wasn't just the schema structure, it was the API abstractions implemented in the schema.
If I remember correctly it was something about Shopify discounts, which can be applied multiple times and across different modalities- percent, dollar amount, etc. and what those were called in the API, and how they were represented and to which object they were applied to.
Then once I had figured that out, then understanding how to construct the query.
But of course my problem was more from the point of view of, "I just want to get x done". As the consumer of the API I wasn't as concerned about fully understanding the entire set of abstractions and schemas.
Re: After 6 years, I'm over GraphQL
#529And with spec first and OpenAPI Spec we are back to the methods and tools, that we hadwith WSDL/XSD and SOAP/XML like 20 years ago. We went full circle. :) I love IT
The problems with GraphQL where so obivious in the first 5 minutes that I looked into that. Looks smart and flexible - but isn't
Re: After 6 years, I'm over GraphQL
#530> Tab Grouping, Vertical Tabs, and our handy Sidebar will help you stay organized no matter how many tabs you have open — whether it’s 7 or 7,500.
Not sure if this will be good. This reads like they will add Vertical Tabs as a Sidebar, like all the other vertical tab-addons doing it now. But since the Quantum-update there is demand for a second sidebar dedicated for tabs, because as it's now, sidebar is really annoying to use.
But maybe it will at least add some improvements which the other addons can built upon.
> More streamlined menus that reduce visual clutter and prioritize top user actions so you can get to the important things quicker.
Oh gosh, no! Why make them even worse than they are already now?