5 ms·
The main issue of GraphQL is awful tooling, especially outside of the js. For example, we have done small rewrite of Apollo Android library and achieved like 1
by ex3ndr 6y ago
The main issue of GraphQL is awful tooling, especially outside of the js.
For example, we have done small rewrite of Apollo Android library and achieved like 100x performance boost simply by writing as it should be written. Literally very minor changes and better DB.
Typesafe codegeneration? Still feels very beta anything your could find.
Compare it to something like grpc that have strict typed clients for almost anything.
- rattray 6y agoThis was a big reason we decided not to release a GraphQL version of our REST API at my previous employer. Most backend languages have poor gql clients, if any at all. Better to just provide a nice, typesafe client library generated from OAS.
- hobby-coder-guy 6y ago> Still feels very beta anything your could find. ?
- stephen82 6y agoWhen should we expect an article about this? I'm all eyes and ears!
- georgyo 6y ago100% this! Outside of JS, the tooling seems non existent. What's so amazing to me is that it is really easy to spin up a server that talks graphql in any language. But there is no client support. And hand crafting queries is a million times worse than reading the rest documents Oh, you want to get a list of items by owner, you can do that but you'll also have to paginated the inside and outside list. And the client will have to follow these pages while also having a deep understanding of your model. Without good client tooling, graphql is a nightmare.
- initplus 6y agoIt's easy to spin up a server. Spinning up a server that can actually access your data in a way that has reasonable performance is another matter entirely.
- dudul 6y agoWhat kind of client side support do you need? You send a query document in a POST and get JSON back. I'm pretty sure all languages have an http client and a json library. How is pagination worse than the REST equivalent? I guess I could see a case for client side caching based on IDs, but unless you couple this with subscriptions thats kind of brittle.
- georgyo 6y agoThe main different on pagination, is that you pages return inside an object. And you have have several different objects that all have different pages. With rest, you can only paginate that particular call. You cannot really paginate different results in that one call. At most you can do is say get the list of objects at this endpoint. And that is far easier to grok than graphql's pagination in even the simple case. I mean, just look at the official guide on this: https://graphql.org/learn/pagination/ https://graphql.org/learn/pagination/ And that only covers a simple use case!
- balfirevic 6y ago> With rest, you can only paginate that particular call. You cannot really paginate different results in that one call. Where did you get this idea that REST in any way dictates how you do pagination?
- dudul 6y agoI've implemented the connection spec many times and I find it very clear and usable. Graphql allows you to paginate several collections in the same call, but you certainly don't have to. You can do just like REST and do one at a time.
- andrewingram 6y agoDunno if it'll help at all, but I did write a thing about GraphQL connections that may clear up some things: https://andrewingram.net/posts/demystifying-graphql-connections/ https://andrewingram.net/posts/demystifying-graphql-connecti...
- k__ 6y agoIs it so hard to create a GraphQL client? As far as I know, JS clients Lokka and Urql are pretty small and cloud be easily ported to a different language.
- philplckthun 6y agoI think this is the important point here; it’s not hard to call GraphQL and even create a client starting from copying @urql/core for instance, but I suppose at some point if you want the same benefits on your other platforms normalized caching will be of interest, which means it isn’t as trivial to get to feature parity. So I think it’s still a valid point
- BenGosub 6y agoHand crafting GraphQL queries is pretty easy, with auto-suggestion built into every client like GraphiQL for example.
- dalu 6y agoBut but isn't GraphQL the swiss army knife where you don't have to write queries anymore as some posters suggest? My point remains, why write queries when you can query endpoints and write filters easily without having to learn a new query language?
- deleted 6y ago[deleted]
- jensneuse 6y agoWith WunderGraph I actually want to go the other way around. Instead of having a "smart" GraphQL client I let users write their Queries/Mutations/Subscriptions in GraphiQL. I'll then take the operations and generate a fully typesafe "dumb" client which has no clue about GraphQL at all. The Operation gets persisted as an RPC which the dumb client can then call. Feels like GraphQL, behaves like GraphQL but is very lightweight, performant and secure at the same time. All it takes is one code generation step but I think that's acceptable. GRPC does it the same way.
- Etheryte 6y agoI would argue that even in JS the tooling is bad compared to other options. If you can't get autocomplete, strict types, etc out of the box without backflips, it isn't really worth whatever other benefits you may be getting.
- sizt 6y agoapollo tooling would be less awful if you mindfully contributed your improvements back to the community
- speedgoose 6y agoI have only used GraphQL in JavaScript and Rust, and the tooling was perfectly fine for me.
- ingas 6y agoStrange, but my impressions are opposite. We are using hasura (which is written in Haskel), I'm interested in dgraph.io (which is golang). I had terrible experience writing graphql-service in typescript. I finished it but I did not liked it's strange behaviour and bloated docker image size. I rewrote it in 2 days with graphql-go/go and then it became OK: predictable behaviour and ~16Mb docker image. I'm thinking about rewriting another service too. On client side I used: - python client `gql` - .NET `graphql-dotnet` - Apollo client - graphqurl - js client from hasura team The worst impressions are from Apollo. Starting from their documentation. IDK why they explain everything starting from UI.