> If you need you consume a Graphql API you most certainly reach out for Apollo on the clientside to query data.
Over the last couple of weeks I’ve been assessing whether to use Apollo in a Swift iOS application. If your backend is using GraphQL then it’s almost impossible to find even a StackOverflow answer from anyone not using Apollo.
But when I tried it out, I found the package was cumbersome to use, and the generated code was over-dimensioned and inelegant, and the dependency itself pulled in other dependencies.
With bitter experience of using other packages in the past, which start out as helpful, but which end up a burden to the codebase, I decided to write some queries and mutations by hand. And it was super-simple.
Eh, https://github.com/urql-graphql/urql is considered the improved re-architected project that doesn't contain the legacy baggage from the beginning of GraphQL like Apollo does.
Do you work for Hasura, based on your username? You've been spamming the same comment looking at your comment history.
Anyway, these are all tools to generate a backend based on your database which might work for simple situations but breaks down for more complicated ones. I also don't want to give my backend away to Hasura or Supabase either.
No. I have not been spamming the same comment. I have made several related comments, which I'm free to do just as anyone else is.
Now, YOU'RE free not to use Hasura Cloud (a fine cloud-managed product by a company I work for) or Supabase (a fine cloud-managed product by a company I don't work for). You're also free to use Hasura CE (a self-hosted OSS Docker image), Supabase (another self-hosted OSS Docker image), or Postgraphile (another self-hosted OSS Docker image) if you don't want Hasura or Supabase to host your application. You're even free to believe these tools work only for simple situations but break down for more complicated ones. The thing is, other people are equally free to make other judgments.
If you work for a certain company and you recommend it, you should disclose that you work for said company. Your comments are also near copy-pastes of each other so I wouldn't call them merely related at all.
For the record I have used Hasura before, both cloud and self-hosted versions. At the time Hasura didn't have serverless functions so it was very difficult to do anything custom even with workarounds. Now it seems Hasura has serverless functions now but now I feel that I shouldn't need to tie my backend and code to a database product lest anything happen to said product, lock-in sucks. That they are OSS or self-hosted does not make them any less susceptible to lock-in. I could also use, for example, Vue, also an OSS product, but if something happens to the primary contributor and no one else wants to maintain it, now I either have to deal with bugs slowly creeping in over time or rewrite my frontend.
So, no thanks, I'd rather keep my own backend and not use a BaaS product.
They’re certainly good at getting their name out there, but their libraries seem to be waning in popularity in most of the places people discuss GraphQL.
I’ve personally never used Apollo stuff in prod —- there’s always been a more suitable alternative, but I’ve always appreciated their code for being quite clean. Federation is an interesting technology, but I haven’t had cause to use it yet.
Over the last couple of weeks I’ve been assessing whether to use Apollo in a Swift iOS application. If your backend is using GraphQL then it’s almost impossible to find even a StackOverflow answer from anyone not using Apollo.
But when I tried it out, I found the package was cumbersome to use, and the generated code was over-dimensioned and inelegant, and the dependency itself pulled in other dependencies.
With bitter experience of using other packages in the past, which start out as helpful, but which end up a burden to the codebase, I decided to write some queries and mutations by hand. And it was super-simple.