161–170 of 182 posts
GraphQL just feels too tied to the datastore on the back end to be generally useful. REST/Swagger is hugely overcomplicated for the basic REST premise of moving objects back and forth.
GRPC is what REST should have been. Ship objects back and forth between multiple languages with minimum fuss.
I have been using straight HTTP requests to query the GraphQL endpoint. Now, wanting to do something more complex, I am disappointed in the state of GraphQL clients. Everyone says use Apollo but it has some serious issues (e.g. caching [1]). Relay seems over-kill/restrictive and none of the other alternatives seem complete. I feel like maybe my life will be a bit easier if I just stick with REST especially since I am proxying an exiting API.
[0]: https://github.com/monostable/kitspace-partinfo
[1]: https://github.com/apollographql/apollo-client/issues/3452
We decided against it. We’re in a java backend and GraphQL in Java with ORM is considerably problematic when trying to create efficient resolvers. We simply ran into one hurdle after another and we were finding ourselves in diminishing returns. The concept is great, and if you write custom SQL queries for each resolver (if necessary), properly caching things that can be cached, and use the first class citizen program…
It's not impossible in Java but it does require a strong grasp of graphql-java's execution model and the DataFetchingEnvironment and associated classes. We accomplish something similar to what you desire when querying our time series database via GraphQL. The big difference between Java and Javascript when it comes to GraphQL is the amount of noise, tutorials and examples on the Javascript side far outweigh other opt…
These last months, I've been working non-stop in a blazing-fast GraphQL engine that beats the rest by an order of magnitude - https://graphql-quiver.com/
Earlier quoted context omitted.
Your graphql library will handle that for you. The server defines data as it knows, the client asks for data that it wants, and the library does the transform work.
What will the library handle ? From my understanding it’s only the query parsing and the data filtering part. Correct me if I’m wrong. You still have to do the data mapping, fetching everything from DB in a reasonable way, and make sure it all makes sense performance wise. All of that will be needed for any API, but it seems to me GraphQL adds the uncertainty on how much data will be exchanged (lots of small queries…
I don't know what your use case is, but it sounds like you should just try it, I can only say that for us (multiple FE experiences, pushing logic to backend), it's been very good. If you have a different usecase, ymmv.
Earlier quoted context omitted.
How does the complexity bite you? Large files, bad error messages, bugs? Something else?
Limited error handling mechanism in Apollo and our backend GraphQL library means I can't use then/catch to reliably handle both network and server errors. Apollo also hijacks state management and somehow decides when to fetch over the network or render a cached response, with no particular logic I can deduce or find documentation for. Then there's the thousand lines of repetitive query code that is a joy to read/writ…
The state management is a problem by default. We wrote our own cache driver to fix it, which is pretty well documented thankfully. "Un-magic it" is a phrase we use a lot.
Earlier quoted context omitted.
If a frontend employee isn't earning a comparable salary to a backend employee, you're either not hiring people of equivalent skillset, or you're underpaying your frontend people. Where the GraphQL burden lies is largely due to who is considered to be its product owner. This varies significantly depending on whether it's an API for first or third parties.
You don't know enough about my products to be so certain about my payment practices. First of all, our backend is extremely complex and our frontend isn't. Our backend devs need a lot of legal and financial training. Other companies will have an inverse situation. Second, there's a glut of frontend devs (at least when I look for them) because bootcamps seem to produce people who are better at frontend than backend. A…
I just found it a surprising comment in isolation because most people I’ve met who’ve developed both frontend and backend skills to a senior or greater level, would argue that frontend is the more challenging of the two.
The bit about idle time is a bit confusing though, can’t you just have fewer devs if there’s not enough work to go around? Or do you always need a lot of spare resources due to unpredictable workloads?
It makes many things easier and many things harder. The lack of really good backend libraries/frameworks outside of NodeJS is the most concerning thing. Also; debugging and monitoring GraphQL APIs sucks . Considerations: - Any subfield of a query can throw an error, but the rest of the fields can succeed, because GraphQL frameworks are allowed to run each field resolver asynchronously. - Because of this, any GraphQL…
I’ve only heard positives about Absinthe for Elixir fwiw.
The common thread between those is that they're all languages with weak type systems, which is a theme in GraphQL land. Strongly typed languages tend to have usability and safety issues with GraphQL; you end up needing codegen or bypassing type safety to make it work.
Earlier quoted context omitted.
What will the library handle ? From my understanding it’s only the query parsing and the data filtering part. Correct me if I’m wrong. You still have to do the data mapping, fetching everything from DB in a reasonable way, and make sure it all makes sense performance wise. All of that will be needed for any API, but it seems to me GraphQL adds the uncertainty on how much data will be exchanged (lots of small queries…
Yes, it handles data filtering, field renaming, etc, which turns out to be a big chunk of work if you're working on APIs to support multiple frontend experiences (the BFF pattern). I don't know what your use case is, but it sounds like you should just try it, I can only say that for us (multiple FE experiences, pushing logic to backend), it's been very good. If you have a different usecase, ymmv.
It was this study: http://olafhartig.de/files/HartigPerez_WWW2018_Preprint.pdf
Overall it acknowledges GraphQL's advantages, while warning that the data retrieval part shouldn't be done naively.
An excerp
> We note that this issue is somehow acknowledged by the Github GraphQL interface and, as a safety measure to avoid queries that might turn out to be too resource-intensive, it introduces a few syntactic restrictions [7]. As one such restriction, Github imposes a maximum level of nesting for queries that it accepts for execution. However, even with this restriction (and other syntactic restric- tions imposed by the Github GraphQL interface [7]), Github fails to avoid all queries that hit some resource limits when executed
Absolutely. Before GraphQL we were making a monumental effort to build a REST API. After deliberating on exactly what REST was and how we’d represent a few red haired resources, we were spending a lot of client time fetching deep trees through resource links. When we moved to GraphQL it solved a lot of the administrative and philosophical headaches and considerably reduced the number of connections, wasted data, and…
What is a red haired resource?
PC police might be on to terms like this nowadays, but by using the term I understood them to mean:
- A less loved resource - A potentially ugly resource - A resource that causes trouble
I really wish everyone would just move to GRPC and be done with it. GraphQL just feels too tied to the datastore on the back end to be generally useful. REST/Swagger is hugely overcomplicated for the basic REST premise of moving objects back and forth. GRPC is what REST should have been. Ship objects back and forth between multiple languages with minimum fuss.
There's no reason someone who wants an expressive query language like graphQL provides couldn't send that query over gRPC, in which case all the benefits are moot, you can do both. But let the rest of us just make regular RPC calls.