[trollerator23]

I have no idea what Apollo Graph QL is, but it was interesting to search by URL and see the progression of related HN titles and their engagement.

2018 July. Apollo server 2 released woo! (mostly ignored)

2019 Feb. We switched away from Slack woo!

. . . (Some PRs everybody ignored)

2019 June. We got a $22M investment woo!

. . . (Many PRs everybody ignored)

2022 Dec. Oops, we are laying of lots of people...

[alexchamberlain]

Outside of Facebook, Apollo is _the_ GraphQL company, with innovations in the federation space in particular.

[benatkin]

Why use GraphQL? There is tRPC now.

[reducesuffering]

tRPC is for a single team working on Typescript frontend to Typescript backend (that's niche). If you have native mobile clients (different lang) or different teams that need to agree on a contract (GraphQL schema), GraphQL is the recommendation, even from ardent tRPC supporters.

[benatkin]

Yeah maybe. It's a leaky abstraction where the real magic happens in the RPCs in the "resolvers"

[SlickStef11]

Gonna put this article I read earlier this week in here to answer your question: https://wundergraph.com/blog/trpc_vs_graphql

[satvikpendem]

I use GraphQL because my clients are not all TypeScript based. Also I don't necessarily want to write my backend in TypeScript either. My stack is therefore Rust with GraphQL with clients in React for web and Flutter for mobile.

[SketchySeaBeast]

Their HN may have been ignored, but both of the last two companies I've worked with have both used Apollo.

[sergiotapia]

Apollo is synonymous with Graphql at this point.

If you need you consume a Graphql API you most certainly reach out for Apollo on the clientside to query data.

[null_object]

> 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.

[reducesuffering]

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.

[satvikpendem]

Urql client is great, however for the backend, Apollo Server really can't be beat, at least for a NodeJS backend.

[dventimihasura]

Rubbish. For the backend, Apollo Server absolutely can be beat by tools that don't require you to write any code:

https://supabase.com/blog/pg-graphql

https://www.graphile.org/postgraphile/

https://hasura.io/

[satvikpendem]

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.

[dventimihasura]

Yes. I do work at Hasura. Why is that relevant?

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.

[andrewingram]

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.

[dventimihasura]

Rubbish

https://graphql.org/code/#javascript

[dventimihasura]

Apollo is not _the_ GraphQL company, nor is it synonymous with GraphQL. Nobody is those things.

[mfcl]

It's just a way of saying that they are all about GraphQL. They are there for all you GraphQL needs and everything they do is related to GraphQL.

[subpixel]

The folks who made Meteor!

[no_wizard]

I thought they were different entities?

Also, big aside here, but is Meteor still a thing?

[andrewingram]

It spun out of Meteor, which was then sold to another org.

[no_wizard]

I'm interested in this history, any where I can read about all this?

[jpgvm]

Read maybe not, but I was there if you are curious about anything.

I was there during the transition period. Originally joined to work on the Meteor hosting platform that was called Galaxy. Handled integration of Meteor APM (which was an acquisition) both of which got sold off when the old Meteor business was sold.

I then worked on what was called Apollo Optics, the GraphQL APM product. Rewrote the time series backend to port it to Apache Druid (which remains in use today!). Was somewhat unceremoniously let go of during a bad personal period. Don't think I would have stayed anyway though, main reason I stayed as long as I did was I had a really good mentor there that taught me a lot.

Worth mentioning the company had already raised an absolute crap ton when on the original Meteor path, then the following pivot raised even more money. No idea how many rounds of financing the company has been through at this point but to say it exemplified the excesses of cheap money would be an understatement.

Developer tools is a tough business, no-one really wants to pay for that stuff at the low end which means catering to enterprise. Long sales cycles, annoying requirements etc.

[satvikpendem]

Sorry to hear about their letting you go.

To be honest I don't understand Apollo's business model, not once did I feel like I needed to pay for it, its free version solves all my needs.

[justaregulardev]

Here’s an article from TechCrunch (https://techcrunch.com/2019/10/02/tiny-acquires-meteor/) on the acquisition of Meteor by Tiny Capital