281–290 of 448 posts
Earlier quoted context omitted.
Nobody seems to get the idea of building software out of pieces with well defined APIs any more . I would say it's not possible to build large software without adhering to this principle but I seem to be proven wrong. You can build large poor quality software and just throw more people at it. The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the te…
This is one of the strengths of gRPC, it forces and centralizes the (mostly type safe) API design from the get-go. Also tends to use a lot less bandwidth.
Until they solve the stateful part, I’m not using it or recommending it to be used anywhere. Bandwidth is cheap, type safety is overrated, and compute is expensive.
Earlier quoted context omitted.
This isn’t remotely a problem. Field by field granular security is trivial to implement in GraohQL
I have to disagree with you there. It is possible, but it causes other annoying problems. For example, field-level security pretty much means every field could be null at any time. Depending on your graphql server implementation, this might cause an entire request to fail rather than just that field to be omitted, unless you change your schema to where everything is nullable. Checking every field can also easily lead…
hasn't been a problem for years in the ts, python, and .net communities
> It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
unions, embedded types, and custom resolvers, OR better api design
> No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
this one is actually insane. /api/v1/graphql. sounds like you are new to apis
---
all of the complaints i hear about graphql have come from people who are early in the process of learning it and/or have built up faulty assumptions through malpractice
The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. It's easy to construct a query which puts unreasonable load on your system. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. If you want to see the kind of work you actuall…
It's also not that hard to implement attribute filtering with REST endpoints. People make a big deal about being able to control the shape of your API responses with GraphQL, but this completely achievable with standard REST APIs as well.
[0]
A very simple convention for including nested resources in a JSON API: https://www.jsonapi.net/usage/reading/including-relationship...
A totally cool but kinda over the top library that exposes a REST API over your database with a very GraphQLesque query string syntax that supports recursively nested resource inclusion, filtering, etc.: https://postgrest.org/en/stable/api.html#nested-embedding
I feel like there’s two approaches that one could take to approach queries: a series of programming commands (the way most ORMs work), or an attempt at “plain language” (SQL and GraphQL).
Both approaches are fine, but if one wanted to take the latter approach… why not just use the syntax of SQL? It’s better in every conceivable way that GraphQL, equally legible but much more powerful.
GraphQL is idiot baby talk, I’m baffled by why we have to waste time dumbing down expressions for no clear payoff.
However, I think GraphQL vs REST is a false dichotomy. One could probably maintain a GraphQL endpoint as well as a REST API, and use whatever is most appropriate for the use case of the client. People really should stop treating GraphQL as some kind of complete replacement for a REST API or "the new way of doing things" or acting like "the days of REST APIs are counted".
Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers. Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly,…
I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.
The separation of front/backend has always been mildly entertaining to me and I’ve worked on both teams. Btw, if you ever want to cause a political mess, just submit a PR to add a new API endpoint to the backend team that “doesn’t have the time” to work on it. Woah boy, they will get mighty pissed. As a backend engineer these days, it would be a blessing to get free work from another team… I don’t know why they were so pissed that one time.
We recently had to design an HTTP API, and we wanted to have as much automatic stuff as possible. I mean: * Autogenerated documentation * Autogenerated wrappers for scripting languages * Autogenerated validator for requests and responses For a REST API, you can get most of these things with swagger or stuff like that, but clearly it's an afterthought. If you have a schema, it's all much more natural and elegant. But…
> But the most important thing you get with GraphQL is batching. Doesn't HTTP/2 make this mostly obsolete? One of its big features is request multiplexing. Regarding the auto-generated code bit, are auto-generated GraphQL clients a thing? It seems like it would be doable, but I haven't found any (at least for the languages I'm using).
Earlier quoted context omitted.
> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment). There…
The GP is right. GraphQL is especially annoying because it looks so close to JS/JSON, yet since no thought was put into how it might integrate into existing typed languages its actually surprisingly difficult to build a type-safe API around it. And yes, SQL is "bad" because you write query strings. The funny bit is that GraphQL may be just as hard to model in a type-safe way as SQL is, if not a little harder. At leas…
Says who?
> [...] its actually surprisingly difficult to build a type-safe API around it.
Again, says who? The consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process. Are you telling me that it's easier to build type safe APIs based on examples of what JSON each endpoint might output?
> And yes, SQL is "bad" because you write query strings
Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point.