211–220 of 241 posts
Earlier quoted context omitted.
I write all of my openapi specs by hand. It's not hard.
I imagine you are very much in the minority. A simple hello world is like a screen full of yaml. The equivalent in graphql (or typespec which I always wanted to try as an authoring format for openapi https://typespec.io/ ) would be a few lines
I think you're over fitting your own experiences.
I get the impression that GraphQL only got popular because it was backed by behemoth Facebook. But the other graph query language "Cypher" always seemed a lot more intuitive to me. Are they really trying to solve such different problems? Cypher seems much more flexible.
Cypher tries to solve problems closer to storage. GraphQL was designed to add types and remote data fetching abstractions to a large existing PHP server side code base. Cypher is designed to work closer to storage, although there are many implementations that run cypher on top of anything ("table functions" in ladybug). Neo4j's implementation of cypher didn't emphasize types. You had a relatively schemaless design th…
GQL-SQL - for queries.
GraphQL, more for REST??
Earlier quoted context omitted.
i do a lot of data shenanigans and it's just annoying to work with when some saas goof doesn't consider that orgs are in the business of warehousing the piss out of entire platforms worth of data that they are paying saas guys a million dollars a year for just so they can marry it together with other reporting. all roads lead to damn reporting. so if you want to woo clients but only have graphql then you should proba…
@grok: summarise this post in two sentences.
Earlier quoted context omitted.
@grok: summarise this post in two sentences.
GPT: "GraphQL is fine for frontend apps, but it’s a pain for enterprise data pipelines where the real job is bulk ingestion, warehousing, and reporting—work that REST APIs handle far more cleanly without forcing engineers to reverse-engineer undocumented schemas and babysit resolvers and rate limits. Organizations pay SaaS vendors to extract value through reporting, not to do bespoke GraphQL gymnastics, and the indus…
Earlier quoted context omitted.
Can you elaborate? I've used URQL and Apollo with graphql code gen for type safety and am a big fan. What about relay is so compelling for you? I'm not disagreeing, just genuinely curious since I've never really used it.
Try gql tada it’s much better than graphQL codegen
Funny that the top three threads are about how the author misses the real benefit of GraphQL and proceed to assert three different benefits. Perhaps its varied applications is one to consider :-)
There is a pattern where GraphQL really shines: using a GraphQL native DB like Dgraph (self-hosting) and integrating other services via GraphQL Federation in a GraphQL BFF.
Sounds like a great way to completely lock yourself into an ecosystem you'll never be able to leave!
Migrate data to another GraphQL DB and join its GraphQL schema to the supergraph. The only pain point could be DB-specific decorators, but even those could be implemented at the supergraph level (in the Federation server) if needed.
Even migrating to a non-GraphQL DB is feasible: you could just write your own resolvers in a separate GraphQL server and join that to the supergraph. But that would be more of a ecosystem lock already :)
Really, any manner of SQL database is more of an ecosystem lock than a GraphQL database behind Federation.
Earlier quoted context omitted.
> For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observa…
Doesn't even need to be a proxy, you can lay out your controller and endpoints like this just fine in most modern frameworks
> GraphQL isn’t bad. It’s just niche. And you probably don’t need it. > Especially if your architecture already solved the problem it was designed for. What I need is to not want to fall over dead. REST makes me want to fall over dead. > error handling is harder than it needs to be GraphQL error responses are… weird. > Simple errors are easier to reason about than elegant ones. Is this a common sentiment? Looking at…
If isomorphic TS is your cup of tea, tRPC is a nicer version of client server contracting than graphql in my opinion. Both serve that problem quite well though.