661–670 of 721 posts
So that: 1. we enjoy the current tech stack from REST/rpc 2. we gain the ability of quick composition from resolver / dataloader 3. with iteration, we can replace/ refactor endpoint without breaking anything.
for fastapi user, the lib 'pydantic-resolve' can help.
Earlier quoted context omitted.
Curious as to why you think Kafka is broken by design?
1. No reliable way to delete already processed entries. 2. No reliable way to handle queue overflow. Combine both and you are 100% guaranteed to have an incident. (I guess it keeps devops and sysadmins employed, though.)
Rough edges sure. No reliable way to delete processed messages. Well, who’s to say they were processed? It’s a persistent queue, stuff sticks around by construction. Besides, this can be managed with tombstones and turning on compaction for that topic.
How would you want to “handle” queue overflow? You’ve either got storage space, or you don’t, this feels a bit like asking “how do I make my bounded queue unbounded”. You don’t, that’s an indicator you’re trying to hold it wrong.
The configs could be a bit easier to drive, but confusing and massive configs is pretty par for the course for Java apps ime.
Earlier quoted context omitted.
One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new. "Maybe implementing CORBA for message passing is over complicating it." "Maybe us…
This is an eternal struggle for either senior or self-assured developers, convincing others to rein in their enthusiasm / hype. Plus, extroverts (loudmouths) vs introverts (who are correct, but refuse to play the extrovert's game).
I remember working on a Rest API and thinking about (things like) GraphQL... the typical "would it make life easier" and all that.
In the end, as the years have passed, I just stick to the minimum. If there is a tried-and-tested library or something.. I use it. When there is something new, I question it.
Never tried GraphQL. It looks like it can improve my data on one end, but cumbersome when it is hard to reason the data, or get generally complicated, which this article demonstrates.
Earlier quoted context omitted.
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?
This is one of the problems with graphql, there are no docs because the schema is all you need. But that assumes the schema is logical and consistent, which it rarely is. It also means you need to be an expert in the tooling to figure it out, so just dropping in to a graphql api is so frustrating compared to plain old rest
Earlier quoted context omitted.
Ha, I gave this exact speech at the 2021 Hasura Conference [0]. You hit the nail on the head. 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 qu…
Things will be very interesting if we treat each single rest endpoint as a GQL query. With static typing definition and OPENAPI, we can declare the response type first, and then borrow the concepts of resolver and dataloder to easily construct the response we want. Using resolver and dataloader can iterate as fast as GQL, and after the requirement is stable, we can refactor each single endpoint on demand. for FastAPI…
Earlier quoted context omitted.
What kind of "production apps"? A todo list saas? I swear, the older I am, the more convinced I am that people who don't use a RDBMS just don't work on complex systems. Period.
Weird. My experience has been it is the most complex and biggest applications where RDBMS breaks down and you start looking for more scalable options.
Earlier quoted context omitted.
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…
But as people noted, it's not the "can this get the data" unit testing that's a problem here. It's the performance issues. > 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 queri…
And you can both put queries on an allow list, control max query depth, and/or throttle on query cost.
Earlier quoted context omitted.
Postgraphile is great, until you need to debug row level security. Or when you realize you need another tool to make the query type safe.
What troubles have you had with debugging row level security? It has worked very well for me, I've not had issues debugging it. And what do you mean with making a query type safe? Type safety is built in to GraphQL, if you send in the wrong datatype for an input the query will be rejected without even hitting the database.
This is a great write-up. I was already aware of most of the drawbacks that the author wrote about in the early days of GraphQL... Another category of solutions which was ignored completely is CRUD with field-granularity over WebSockets. I've built platform which does just that: https://saasufy.com/ This approach has allowed me to create a library of highly generic components which can be composed into surprisingly c…