[topspin]

I'm experiencing some frustration with this. Click on this principledgraphql.com site and you find it's 'Apollo.' Nearly everywhere you look on the Internet regarding GraphQL you find 'Apollo' being injected.

I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing some enormous value by naively just using GraphGL without involving Apollo?

That is a sincere question. What is the deal here?

[billdybas]

They're one of the few companies who are building GraphQL developer tools, so they have a financial incentive to have their name associated w/ GraphQL.

This piece, while somewhat valuable, is largely content marketing. First they sell you on the idea of "best practices." Then they'll follow up w/ a tool that, surprise, does all those "best practices" for you. "The modern marketer creates their own demand." Prisma is another GraphQL company that produces content like this.

[unleashit]

It's called marketing and they're pretty good at it. They do provide some useful tools however if you want to use them and don't just blindly follow the docs (which are selling you on things you may/may not need).

[wawhal]

Apollo's marketing game has been ridiculously on point. They are the only GraphQL client in the ecosystem that is fully compatible with any GraphQL compliant server [0]. And since it is pretty good, whenever one has to talk/market/propose anything about GraphQL in the community, they end up cross-marketing for Apollo.

[0] Relay has its own spec and can be used only if the server supports it. Other GraphQL clients are either not well maintained or do not support as many features as Apollo does (caching, subscriptions are two features that come to mind)

[andrewingram]

FWIW: You don't have to follow any of the Relay spec to use Relay. Though you'll lose many of the benefits if you don't at least use globally unique 'id' fields on each major type. Connections are optional, the node interface is optional.

[strken]

Back in the Relay Classic days, the Apollo client library was a lot easier to use and a lot less heavyweight than Relay. My team ripped out Relay and replaced it with Apollo early in development because we felt Relay was too confusing. Relay Modern may be better; I haven't used it.

They're also intending to make most of their money by promoting GraphQL as a tool, so low rates of adoption are an existential risk for their company, while Facebook only needs GraphQL as a PR and recruitment tool.

[andrewingram]

Ironically Relay Classic only needed a babel plugin, whilst Modern has a separate compiler you need to use. That said, the main issue with Relay is that it still has poor documentation, so it can't really compete with Apollo in that regard.

But I'm not going back to a world without data-masking at the component level, so Relay is the only choice for me right now (though I wish it wasn't).

[Existenceblinks]

Thanks for telling it's everywhere. I immediately closed the tab when spotted the first "Apollo". Actually when I saw the title "Principled", I almost not-clicking it. Also these frontend stuff REALLY like "modern" word so much.

[andrewingram]

I'm trying to think back here, but I've been using GraphQL in production (at two different employers) for over 3 years, and I don't think there's any Apollo code in any of those systems.

Apollo Server is an improvement over baseline graphql-express, but for the most part it's nothing you can't easily add yourself. Having compatibility with Apollo Engine is useful if you end up wanting to use their monitoring tools. Pretty much everything else is just down to how much you want to buy into their ecosystem.

[DownGoat]

It depends on your needs, on the server side you are probably not missing much. Apollo tracing might be nice if you want some statistics on how your graph is consumed.

The client side depends on the client, we have a Angular SPA that extensively uses Apollo Client together with some code generation tools. The benefits we see from this are:

* The whole schema is automatically defined in frontend, so it is easy to keep types in sync between frontend and backend. * .gql files are scanned, so services that consumes the queries/mutations are automatically generated with correct typing. * The Apollo Client cache makes it easier keep the data updated across different components.

This greatly reduces the boilerplate code our developers have to create, and it makes it much easier to share type definitions from backend to frontend without having to worry about them getting out of sync. We are still exploring different tools, to see what we might benefit from.

[dmitriid]

1. It's marketing, as someone mentioned. If the first thing that comes up when you search for GraphQL is Apollo, it's good for business.

2. Marketing aside, they are one of the very few (if any) solutions that provide tools that fill the glaring gaps in GraphQL and make it easy(-ish): caching, auth etc.