[HN Gopher] Ask HN: Does Anyone Like GraphQL?
___________________________________________________________________
Ask HN: Does Anyone Like GraphQL?
I personally think that GraphQL is one of those technologies that
has a wide gap in how useful it actually is. For smaller projects
it's easy to setup, write out your schema, and get going. Likewise,
for much larger more complex projects some of the benefits you can
get out of GraphQL can warrant the use of it. But there is a
massive gap in the middle where it just seems unnecessary. 98% of
the literature I have seen about GraphQL has always been positive,
and it seems to have become the standard recommendation for
anything from starting a small web app as a side project, to
running a fortune 500 company. I'm fairly sure that this is because
a lot of larger tech companies use GraphQL in some way, so there is
this misconception that using it must be the correct choice for all
use cases, but who knows. I have worked with GraphQL in a few
different companies now, and in all except the largest company
where there was a dedicated team of engineers that worked on the
GraphQL implementation for the company, I have felt strongly that
we would have been better off with a more boring approach like
REST. I am curious to hear others perspectives on this, do you
like using GraphQL? do you disagree with me and think that it is
actually a good solution for the "middle ground" of use cases?
Also, I do think that GraphQL has some cool features and I'm not
trying to write it off as a useless tool with no benefits. Like all
tools, it has it's place but I think that where it's really helpful
is not where people end up using it in the vast majority of use
cases.
Author : langsa
Score : 18 points
Date : 2023-06-06 20:51 UTC (2 hours ago)
| gumballindie wrote:
| I like it because it can inflate my invoices. It makes projects
| last longer but at least i amuse myself when people write gql
| injections without knowing what they are. But otherwise i find it
| like yet another fashion tool, a symptom of engineering for the
| sake of engineering.
| itsjustjordan wrote:
| Like most technologies it depends on how you're using it. When I
| first starting working in GraphQL, paired with a React frontend I
| used it in an a similar way to REST, pull the data and then do
| all the logic of what to display on the frontend.
|
| For me I saw the most benefit when I used the schema to define
| what to display in the frontend, all the logic of what to display
| is done on the server and my frontend just becomes simple
| components that render the pulled schema.
| sbegaudeau wrote:
| In my company, we are building a set of monolith applications
| based on frontend and backend modules that we can compose (Spring
| jars and React npm packages). As the maintainer of several of
| those modules, I don't know how my modules will be integrated in
| each monolith and I don't know exactly how all the complete
| frontend of each monolith will interact with each API.
|
| Having the ability to define small schemas for each module gives
| us a great way to communicate the contract provided by a backend
| module and the parts of the API required by its associated
| frontend module.
|
| It can be extended very easily and it gives each monolith the
| ability to ask for anything they want. On top of that we are
| using a ton of subscriptions so having the ability to use a
| common language even for the websocket parts is great.
|
| So in the end, the ability to request anything from the API, the
| simplicity to extend and compose APIs and the support for
| subscriptions are features that we would have needed in REST
| which are "included" in GraphQL.
| langsa wrote:
| This is an interesting use case, I could see why GraphQL would
| be useful here where the contract between frontend and backend
| modules is not known in full and can change often.
|
| Out of curiosity, is the reason for the contract between these
| modules not being fully known / being able to change often
| because of how your company wants to use them or is there
| another reason? I'm just wondering if the reason for this is
| wanting to be able to reuse modules across different projects
| for multiple clients or writing integrations for other tools or
| something totally different.
| rvcdbn wrote:
| I think you have to ask yourself "compared to what?".
|
| Compared to REST, I would argue auto-generated GraphQL clients
| are superior (compared to auto-generated REST clients based on
| something like OpenAPI).
|
| Compared to gRPC, I think it has the advantage that it's much
| easier to use in the browser and many people seem to prefer text-
| based protocols for debugability.
|
| What are you comparing it to?
| langsa wrote:
| Mostly comparing it to REST. The main turn off for me
| personally is it really seems like you have to reinvent the
| wheel to get caching to work correctly with GraphQL for non
| trivial use cases. Not saying that it works perfectly out of
| the box if you choose REST instead, but you can get pretty far
| without needing to optimize anything.
|
| Why do you prefer auto-generated GraphQL clients?
| ruler88 wrote:
| auto-generated GraphQL clients works really well if you have
| a larger codebase and large team. You can think of it as a
| forced high quality documentation.
|
| If you are working in a small project with just a few engs.
| The additional lift for GraphQL might not be worth it.
| Especially if the team is not already well versed.
| langsa wrote:
| I agree with you there, having GraphQL force adherence to a
| schema is definitely a good thing for a larger team, but
| smaller teams will probably get bogged down without
| previous experience
| sergiotapia wrote:
| Used it in multiple companies, never said "Wow this is great!" -
| always said "fuck this would be 10x simpler in REST".
|
| The only benefit I have personally experienced is that since we
| have mobile apps more often than not with Apollo, having the
| graphql for both mobile _and_ web react is nice.
|
| But with Phoenix Liveview that benefit quickly erodes for me. I
| say good riddance.
| Rodeoclash wrote:
| I've only ever found use in GraphQL when it is paired with other
| technology. Namely Relay (and to some degree Apollo although I'm
| not as deeply familiar with it as I am with Relay).
|
| Being able to co-locate data queries with components in React has
| been a huge game changer for me when writing reasonably complex
| frontend apps. However, GraphQL on its own never struck me as
| being any more beneficial than Rest.
| chrisquinnr wrote:
| >I have felt strongly that we would have been better off with a
| more boring approach like REST
|
| What led you to this feeling? I know you want to hear from people
| on why GraphQL is good, but why would REST have been a better
| choice in that situation? I'm interested as someone who works
| with both day to day.
| paulddraper wrote:
| REST is simpler to implement and understand.
| ipaddr wrote:
| The tone from the author is less complexity. It's a backend vs
| frontend debate. GraphQL can be magic from the client side but
| on the server side you have tons of boilerplate weighing you
| down.
| langsa wrote:
| Thanks for your reply, I would love to hear more about which
| one you prefer in general REST or GraphQL, or if you have
| different situations where you choose one or the other and why.
|
| Here were some of the things I noticed when comparing to REST:
| - Caching can become a nightmare and requires a lot of effort
| to get working correctly for non trivial use cases /
| you cannot really use the already "built in" cache control
| headers in the browser with GraphQL - Another
| caching one, but you almost are required to have some kind of
| server side cache in addition to the client side
| cache, it can quickly become disorienting trying to figure out
| exactly where something is cached and why, or why you
| are getting stale data, etc... - Some abstractions
| in GraphQL can make the code hard to follow / read in my
| opinion (data loaders for example) and also make it
| hard to follow where the data is actually coming from
| especially in federated subgraphs - Error
| handling in GraphQL can be really unintuitive and more work is
| needed to not have the error response come back as a
| 200 status code (or handle it correctly if it is an error
| inside of a 200)
___________________________________________________________________
(page generated 2023-06-06 23:02 UTC)