Apollo raises $22M to simplify app development(blog.apollographql.com)
blog.apollographql.com
Apollo raises $22M to simplify app development
https://blog.apollographql.com/apollo-raises-22-million-to-simplify-app-development-ee30502c81b3
75 comments
Couldn't agree more. Apollo has shipped multiple broken releases over the past year related to having a massive dependency tree - we're migrating away from their apollo-server system soon.
[deleted]
I like graphql as technology - I find it just a better way than REST for building services, and I like that it's just json - simple easy to debug text responses. I like that there are companies investing in this technology.
But, I don't see how you build a VC funded business out of this - countless examples of infra companies trying to build a business out of OSS technology and they always struggle to get paid because they provide so much value for free.
Docker Inc's struggles come to mind here...
But, I don't see how you build a VC funded business out of this - countless examples of infra companies trying to build a business out of OSS technology and they always struggle to get paid because they provide so much value for free.
Docker Inc's struggles come to mind here...
Our approach (at Apollo) for building a VC funded business out of this is:
1. Build the best GraphQL developer tools we can, focusing on making developers happy. Make sure those tools are open source, and involve the GraphQL community as much as possible when building them, to make sure we're building tools developers actually want to use. With those tools available, make sure any developer who wants to use them can, for free.
2. At the same time, build more advanced tooling and sophisticated GraphQL infrastructure components (that would be costly for an individual organization to build and maintain themselves), that provide a way for businesses and organizations to effectively, efficiently, and securely manage their GraphQL based infrastructure. Give anyone the chance to use these more advanced tools/components for free up to a certain threshold, to see if they're a good fit and if they're worth the money. If all signs point to yes, we then start charging.
Our approach is fairly simple, and has been followed successfully by many companies before us (a simple plan is a good plan). We've been following this approach for a while (before this funding came into place), and things have been going extremely well.
1. Build the best GraphQL developer tools we can, focusing on making developers happy. Make sure those tools are open source, and involve the GraphQL community as much as possible when building them, to make sure we're building tools developers actually want to use. With those tools available, make sure any developer who wants to use them can, for free.
2. At the same time, build more advanced tooling and sophisticated GraphQL infrastructure components (that would be costly for an individual organization to build and maintain themselves), that provide a way for businesses and organizations to effectively, efficiently, and securely manage their GraphQL based infrastructure. Give anyone the chance to use these more advanced tools/components for free up to a certain threshold, to see if they're a good fit and if they're worth the money. If all signs point to yes, we then start charging.
Our approach is fairly simple, and has been followed successfully by many companies before us (a simple plan is a good plan). We've been following this approach for a while (before this funding came into place), and things have been going extremely well.
As a customer, I see a lot of value from Apollo's SAAS, which helps in "productionizing" graphQL. GraphQL has more sophisticated instrumentation and access control needs than simpler APIs like REST/RPC and there are few if any open source projects that can do this. It was a pretty easy buy vs build decision for my team. Granted open source alternatives may pop up at some point.
(disclaimer: I worked at Meteor/Apollo for about 5 years)
I love the callout to how this is continuing the vision for improving application development started with Meteor -- it really does feel that way to me. Apollo, supported by GraphQL is IMO really delivering on the vision of making a lot of aspects of client-rendered app development much more straightforward than they have been in the past.
I love the callout to how this is continuing the vision for improving application development started with Meteor -- it really does feel that way to me. Apollo, supported by GraphQL is IMO really delivering on the vision of making a lot of aspects of client-rendered app development much more straightforward than they have been in the past.
Honest question, what about GraphQL is straight forward? As a web developer I've been curious about its hype for a long time but every time I look at its implementation I balk.
I have a lot of experience with JSON-REST APIs and RPC systems like gRPC and they both seem clearly superior (especially in tandem with code generators) where as GraphQL seems like a ton of extra work on the client and server side for little gain. When asked most developers say its because you can limit which fields you query, and I have to politely explain to them the existence of an SQL SELECT query...
I have a lot of experience with JSON-REST APIs and RPC systems like gRPC and they both seem clearly superior (especially in tandem with code generators) where as GraphQL seems like a ton of extra work on the client and server side for little gain. When asked most developers say its because you can limit which fields you query, and I have to politely explain to them the existence of an SQL SELECT query...
On the front-end, with GraphQL you simply specify exactly the data you want on the client, e.g:
`GET localhost/graphql`, with body
dogs {
...and I get back:
dogs: [
No extra fields. My clients page doesn't care about the dog's UUID, weight, etc. No routes. Everything goes to `localhost/graphql`.
It makes writing clients an absolute joy, and it works gloriously with React. Tell the server exactly what you want, and get exactly that.
On the back-end, every field (name, isAGoodBoy) is a resolver. Maybe it's a simple database call to retrieve that field. Maybe it's some service that pulls crap from an S3 bucket. GraphQL doesn't care. So the level of difficulty of implementing a GQL server is dependent on your back-end. For most folks, you'll just be making calls to a database.
`GET localhost/graphql`, with body
dogs {
name
location {
city
}
isAGoodBoy
...and I get back:
dogs: [
{
Fido,
location: {
Boston
},
true
},
{
Spot,
location: {
Los Angeles
},
true
},
...No extra fields. My clients page doesn't care about the dog's UUID, weight, etc. No routes. Everything goes to `localhost/graphql`.
It makes writing clients an absolute joy, and it works gloriously with React. Tell the server exactly what you want, and get exactly that.
On the back-end, every field (name, isAGoodBoy) is a resolver. Maybe it's a simple database call to retrieve that field. Maybe it's some service that pulls crap from an S3 bucket. GraphQL doesn't care. So the level of difficulty of implementing a GQL server is dependent on your back-end. For most folks, you'll just be making calls to a database.
You can do the same with JSON:API Sparse field-sets. see documentation here https://jsonapi.org/format/#fetching-sparse-fieldsets. Hence what you've above is not really an advantage of only Graphql.
location in the example is a relationship with it's own fields though. We may want to get the top 5 items related to the locations we are fetching for example.
But I think the bigger difference is that we typically expect JSON:API urls to be generated while graphQL queries are more directly edited by the developer. I think that yields an experience that feels more direct.
But I think the bigger difference is that we typically expect JSON:API urls to be generated while graphQL queries are more directly edited by the developer. I think that yields an experience that feels more direct.
> When asked most developers say its because you can limit which fields you query
For me this is one of the biggest headaches I have with a new app I've been assigned to. By allowing all fields to be optional depending on the graphql query, there's no consistency in the objects floating around in your apps data store. When I reference a Person object in my view that I'm using, will phone number be there or not, who knows.
Maybe its better when every single page has to request it's own data, but when the model objects are cached to a data store in an app and shared between views, things get really dicey.
For me this is one of the biggest headaches I have with a new app I've been assigned to. By allowing all fields to be optional depending on the graphql query, there's no consistency in the objects floating around in your apps data store. When I reference a Person object in my view that I'm using, will phone number be there or not, who knows.
Maybe its better when every single page has to request it's own data, but when the model objects are cached to a data store in an app and shared between views, things get really dicey.
A large part of GraphQL is the idea of tightly coupling queries to code, declaratively, combined with smart differential logic.
The original web framework for GraphQL was Facebook's Relay, which essentially lets you declare, in your component, what data you want. Relay stitches together your query and avoids work by figuring out the difference between what data the client has (in its cache) and hasn't.
Apollo's React framework is based around the same ideas. You're supposed to declare the query privately in the component that needs it, and in principle, caching should avoid many unnecessary fetches. For example, if you have:
(There are of course ways to write queries that will always conflict with each other, e.g. by applying different parameters such as filters to nested fields.)
In practice, I'm not sure if Apollo is that smart yet. I think it currently considers any difference in field selections to be a conflicting change, even strict subsets, but I could be wrong.
When used outside of React, GraphQL becomes more like SQL:
The original web framework for GraphQL was Facebook's Relay, which essentially lets you declare, in your component, what data you want. Relay stitches together your query and avoids work by figuring out the difference between what data the client has (in its cache) and hasn't.
Apollo's React framework is based around the same ideas. You're supposed to declare the query privately in the component that needs it, and in principle, caching should avoid many unnecessary fetches. For example, if you have:
// In component A
{
currentUser { id, name }
topStories { id, title }
}
// In component B
{
currentUser { name }
favouriteTopics { id, name }
}
(There are of course ways to write queries that will always conflict with each other, e.g. by applying different parameters such as filters to nested fields.)
In practice, I'm not sure if Apollo is that smart yet. I think it currently considers any difference in field selections to be a conflicting change, even strict subsets, but I could be wrong.
When used outside of React, GraphQL becomes more like SQL:
for (const {name} of (await query(gql`{
users { id, name }
}`)).users {
// ...
}Theoretically, a smart enough GraphQL front-end could recognize multiple filters and do some or all of the filtering client-side, or if impossible, request both from the server. The idea that your client can declare what data it needs rather than leaving it up to the server is the best part of GraphQL, the thing that simplified it the most. But it’s hard to do well, right now. It’s much easier to use code-gen directly to have client and server share knowledge of what’s needed. HTTP2 push adds an interesting twist though, when your GraphQL response could actually trigger additional client code and resources to be sent. Of course this can be done without GraphQL, but you’d still need a server that’s aware of what data the client will use and how. For simple APIs or APIs with many clients that behave the same way, GraphQL is overkill. But even so it’s an interesting alternative to simple REST and simple state management, and unlike Redux, you can trigger multiple events at the same time which can be beneficial if processing their state changes at the same time would lead to a more efficient update. (The Redux alternative is to add some kind of wrapper event, or an event for each combination of events...)
> When I reference a Person object in my view that I'm using, will phone number be there or not, who knows.
Well you know, because your view has a query that asks for a Person object with or without a phone number. The cache (your store) is managed by Apollo not yourself.
Well you know, because your view has a query that asks for a Person object with or without a phone number. The cache (your store) is managed by Apollo not yourself.
I theory yes, but in practice react native development seems to be a grab bag of 3rd party libraries and design patterns. Redux, apollo, some typed objects, some untyped objects, stateful wizard views, stateless normal views. Maybe your objects are defined and queried on the view you are looking at, maybe they came from a previous view.
I‘m not talking about theory here but about my professional experience using GraphQL and Apollo for two years in production code. To be specific: I would hardly have a use-case for Redux when apollo-client already has built in local state handling capabilities. Throw in TypeScript and generate your type interfaces from your schema and your queries and there‘s no second guessing. GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together.
"GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together."
When you say this, I hear "Apollo and GraphQL are fragile technologies that don't play well with others."
Furthermore, technical decisions like which libraries to use are many times not at all related to technical reasons like this, but rather what a particular developer with influence wants to do, based on their own personal preferences. OR, the downsides of decisions to use certain technologies are often not understood until problems begin to creep up, and by then it's too late. Of course, technology companies, especially venture backed ones, don't want to highlight those things to decision makers. Either way, I have a hard time blaming the rank and file developers who probably had no input in the first place.
When you say this, I hear "Apollo and GraphQL are fragile technologies that don't play well with others."
Furthermore, technical decisions like which libraries to use are many times not at all related to technical reasons like this, but rather what a particular developer with influence wants to do, based on their own personal preferences. OR, the downsides of decisions to use certain technologies are often not understood until problems begin to creep up, and by then it's too late. Of course, technology companies, especially venture backed ones, don't want to highlight those things to decision makers. Either way, I have a hard time blaming the rank and file developers who probably had no input in the first place.
One thing to keep in mind is that GraphQL really supports a different use case than something like gRPC or REST.
One of the places where it really shines is providing a queryable API entry point to a graph of interconnected data. This makes it ideal for generally reusable APIs for consumption by a variety of clients (e.g. GitHub's GraphQL API).
gRPC interfaces are typically use-case specific, and performance oriented (though GraphQL doesn't specify any sort of transport protocol, so you could always serialize GraphQL request/responses with protobufs to gain some performance over the wire), making them well suited for server-to-server communication, but not generally reusable.
REST is resource (i.e. nodes in a graph) based, but doesn't necessarily do a good job of making the relationships explicit and easy to traverse (I'm sure there are good HATOAES implementations out there that address this, but I haven't seen one).
Both REST and gRPC have their place, but I think GraphQL is a clear winner when you want to build a single API to service a large number of distinct clients. It really does offer a clear, easy-to-use API abstraction over where ever you might get your data from.
Also, since you call out code generation specifically; GraphQL provides a strongly-typed schema that can be introspected against, and the tooling to parse queries/schemas into abstract syntax trees. A large number of tools have been built with these capabilities including a number of different code generators. I've even used a GraphQL schema to generate a matching XSD (ugh) for import into an internal business rules engine. Made integration a breeze.
One of the places where it really shines is providing a queryable API entry point to a graph of interconnected data. This makes it ideal for generally reusable APIs for consumption by a variety of clients (e.g. GitHub's GraphQL API).
gRPC interfaces are typically use-case specific, and performance oriented (though GraphQL doesn't specify any sort of transport protocol, so you could always serialize GraphQL request/responses with protobufs to gain some performance over the wire), making them well suited for server-to-server communication, but not generally reusable.
REST is resource (i.e. nodes in a graph) based, but doesn't necessarily do a good job of making the relationships explicit and easy to traverse (I'm sure there are good HATOAES implementations out there that address this, but I haven't seen one).
Both REST and gRPC have their place, but I think GraphQL is a clear winner when you want to build a single API to service a large number of distinct clients. It really does offer a clear, easy-to-use API abstraction over where ever you might get your data from.
Also, since you call out code generation specifically; GraphQL provides a strongly-typed schema that can be introspected against, and the tooling to parse queries/schemas into abstract syntax trees. A large number of tools have been built with these capabilities including a number of different code generators. I've even used a GraphQL schema to generate a matching XSD (ugh) for import into an internal business rules engine. Made integration a breeze.
I haven't ever used GraphQL (so take what I say with a grain of salt b/c i could be incorrect), but what gets me intrigued by it is that it helps your engineering organization scale by decoupling the back end and the front end.
Say, for example, that you have a new UI on your app that requires some data stored on your db.
Without graphql, you:
A) Re-use existing REST endpoints and compose data that you need on the front end (but remember that browsers have a hard limit on the number of concurrent api requests. Not to mention that some requests can't be sent until others have arrived back with resource id's). So depending on what endpoints you currently have, this may not be a good option given the latency cost of composing many HTTP requests to get all the required data.
B) You tell your back end devs to create a brand new route that meets the data requirements of the new UI.
With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser.
Say, for example, that you have a new UI on your app that requires some data stored on your db.
Without graphql, you:
A) Re-use existing REST endpoints and compose data that you need on the front end (but remember that browsers have a hard limit on the number of concurrent api requests. Not to mention that some requests can't be sent until others have arrived back with resource id's). So depending on what endpoints you currently have, this may not be a good option given the latency cost of composing many HTTP requests to get all the required data.
B) You tell your back end devs to create a brand new route that meets the data requirements of the new UI.
With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser.
> With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser.
It doesn‘t quite work like that. Someone still has to implement the backend (resolvers). If you want to request dogs from your backend someone still has to implement the dogs query, but (and I think that‘s one of the greatest things about GQL) as soon as it is implemented, you can introspect your backend and see exactly which properties a dog can have. So you know whether the dog object has a name property, or an isHungry property and so on. So now you can specifically ask for a dog and its name if that‘s all your view needs. Another view might only need the breed, so that‘s what you query for...view specific queries.
It doesn‘t quite work like that. Someone still has to implement the backend (resolvers). If you want to request dogs from your backend someone still has to implement the dogs query, but (and I think that‘s one of the greatest things about GQL) as soon as it is implemented, you can introspect your backend and see exactly which properties a dog can have. So you know whether the dog object has a name property, or an isHungry property and so on. So now you can specifically ask for a dog and its name if that‘s all your view needs. Another view might only need the breed, so that‘s what you query for...view specific queries.
It’s understandable that the benefits don’t immediately seem obvious. We have all been working with REST for such a long time that we forgot what didn’t make sense when we were learning REST.
A good way to think about GraphQL is it’s data centric as opposed to operation centric. The unit you work with is the object instead of the operation.
Object level querying instead of operation level querying
Object level auth instead of operation level auth
A good way to think about GraphQL is it’s data centric as opposed to operation centric. The unit you work with is the object instead of the operation.
Object level querying instead of operation level querying
Object level auth instead of operation level auth
Wasn’t the whole point of REST that it was object (resource) centric? Not saying graphql isn’t, but there’s not much of a difference in that regard. If anything I’d say graphql is more about the relationships than the objects.
Graphql is more composable for querying, so that’s nice. In terms of mutations, it’s basically just RPC again (and a lot of us missed RPC when REST became popular). And then it has a model for subscriptions, but they still feel a little like second class citizens support -wise at the moment.
None of these are judgements. Just interesting to compare the 2 ideologies.
Graphql is more composable for querying, so that’s nice. In terms of mutations, it’s basically just RPC again (and a lot of us missed RPC when REST became popular). And then it has a model for subscriptions, but they still feel a little like second class citizens support -wise at the moment.
None of these are judgements. Just interesting to compare the 2 ideologies.
The main value prop for me with GraphQL is that it makes data a composable, declarative dependency of a view.
So it's a clean abstraction layer? Is that abstraction layer easy to understand, intuitive to train new developers on, and faster to implement then traditional API approaches?
- Easy to understand? Yes, I think so. It's very easy to glean what data requirements a component has from its associated GraphQL query.
- Intuitive? Queries and subscriptions, yes. In the same sense that a React component using props is intuitive. Mutations and optimistic updates are maybe marginally less intuitive, but not prohibitively so.
- Faster to implement? Client-side, absolutely, as there's no need to think about how to retrieve data, you just declare what you want, and Apollo fetches what's necessary. It can also keep track of subscriptions / cache invalidation. Server-side, definitely not. The n+1 problem is tougher than with REST + SQL, and it's harder to make single round trips to the DB to fetch nested data.
- Intuitive? Queries and subscriptions, yes. In the same sense that a React component using props is intuitive. Mutations and optimistic updates are maybe marginally less intuitive, but not prohibitively so.
- Faster to implement? Client-side, absolutely, as there's no need to think about how to retrieve data, you just declare what you want, and Apollo fetches what's necessary. It can also keep track of subscriptions / cache invalidation. Server-side, definitely not. The n+1 problem is tougher than with REST + SQL, and it's harder to make single round trips to the DB to fetch nested data.
There are some libraries that hell with that, namely prisma, hasura and postgraphile.
Completely agree. I think web development is a lot simpler and faster without GraphQL.
My issues with it are 1) I already see enough dumb queries (and queries in indefinitely-long loops...) from backend devs, how will the frontend devs have a prayer of writing performant queries with so much distance from the underlying datastore(s)?, and 2) exposing a highly flexible query language to the frontend, given the variety and complexity of GraphQL libraries and the complexity of implementing GraphQL server-side if you don't just use something that does it automagically for you, sets off my spidey-sense "there will be bad security problems here, sooner or later, guaranteed" warnings.
When will people realize that best practices aren't created by Facebook.
Please don't take this as a personal attack, but I was severely dissapointed with Meteor after being a strong proponent for it for several years.
I advocated for its use on several projects and was bitten by major performance bottlenecks and its over reliance on MongoDB. GraphQL implementation is great, but does it support relational dB's yet?
I am happy to hear that it is still doing well, and I may end up using it for some personal projects.
I believe that the problem it is trying to solve is worthwhile. However I became very frustrated when the push for monetization started while the framework itself still seemed like it was in the prototype phase.
Please correct me if I am wrong, but Meteor has a place in my memory similar to an ex that I really cared about but hurt me once more than I could stomach.
I advocated for its use on several projects and was bitten by major performance bottlenecks and its over reliance on MongoDB. GraphQL implementation is great, but does it support relational dB's yet?
I am happy to hear that it is still doing well, and I may end up using it for some personal projects.
I believe that the problem it is trying to solve is worthwhile. However I became very frustrated when the push for monetization started while the framework itself still seemed like it was in the prototype phase.
Please correct me if I am wrong, but Meteor has a place in my memory similar to an ex that I really cared about but hurt me once more than I could stomach.
As someone who also jumped on the Meteor bandwagon, and is now stuck maintaining a project created with it, run away and do not look back.
It is not being maintained by anyone as far as I can tell, more and more packages are breaking by the week it seems like, and the basic 'features' listed 'on the box' of Meteor have never worked.
Save yourself some headache and pick a stack with an active community.
It is not being maintained by anyone as far as I can tell, more and more packages are breaking by the week it seems like, and the basic 'features' listed 'on the box' of Meteor have never worked.
Save yourself some headache and pick a stack with an active community.
1. It is being maintained (albeit less active), version 1.9 is in the works. Communication could improve a lot though.
2. What's so hard about maintaining the Meteor project? It's been mostly backwards compatible since versions before 1.0 (released over 5 years ago, when the JS ecosystem was a very different universe). What other JS framework has a comparible track record towards backwards compatability?
3. Third party packages may break and become unmaintained, but this is just as much true on NPM. In the end Meteor is mostly a build-tool (and a pretty good one, with zero-configuration, code splitting, ...) creating a Node application with full NPM compatability.
2. What's so hard about maintaining the Meteor project? It's been mostly backwards compatible since versions before 1.0 (released over 5 years ago, when the JS ecosystem was a very different universe). What other JS framework has a comparible track record towards backwards compatability?
3. Third party packages may break and become unmaintained, but this is just as much true on NPM. In the end Meteor is mostly a build-tool (and a pretty good one, with zero-configuration, code splitting, ...) creating a Node application with full NPM compatability.
I was afraid I would hear that. Best of luck, don't forget to use all your vacation time.
I'm currently using absinthe which enables a graphql backend on the elixir stack with apollo on the frontend. its been working fantasticly well for me so far. Its backed by postgresql and the hardest part so far has been making sure to batch sql queries for complicated graphql queries.
I haven't used apollo-server but I wrote nodejs code for 8 years and I wouldn't trust it to scale without a lot of effort being put into your DevOps story.
I haven't used apollo-server but I wrote nodejs code for 8 years and I wouldn't trust it to scale without a lot of effort being put into your DevOps story.
Externally, my observation was the monetization of the platform was competing with development. When Galaxy came out, feature work on Meteor slowed down. Hungry VCs wanting their return and rapid growth, I suppose. It would've benefitted more from growing organically longer, before going for monetization.
We love Meteor too, but have been very disappointed by how MDG has seemingly abandoned it. We had so many expectations for things it would be doing by now that never materialized because MDG moved onto other shinier things.
I have experiment Meteor for a while in it early stage, I felt Meteor became complex to manage and didn’t like to stuck in a high technical debts.
Now I would rather wait for V language which seem to solve many limitations found in other languages.
Now I would rather wait for V language which seem to solve many limitations found in other languages.
If you don't needed the reactivity, I can see how you could solve your performance problems easier without Meteor. However, if you actually need the reactivity, what other tools/frameworks give you a similar convenient reactivity system with better performance? And there are some solutions within the Meteor community: https://github.com/cult-of-coders/redis-oplog (with some trade-offs)
Part of me thinks that if Apollo was a good company, they wouldn't need to keep raising this kind of funding by now. There are plenty of alternatives which burned a fraction of what Meteor/Apollo has burned to build this. They're taking funding and attention away from other more deserving projects.
Just to clear this up a bit; Apollo doesn't "need to keep raising this kind of funding". Both Meteor and Apollo have been making money. What's really happening here is that both Apollo and its amazing supporters/investors have witnessed first hand the impact that data graph based technology can have on the lives of developers and the productivity (and bottom line) of companies. To help take all of this further, we've decided now is the time to bring more people on board, so we're substantially growing our team (hence the extra dollars).
> They're taking funding and attention away from other more deserving projects.
I've gotta say, I completely disagree with this statement. Meteor and Apollo have both helped thousands of developers do amazing things, for free. Yes, I work for Apollo, but I'll detach for a sec; I can't think of any open source software company on the planet that deserves this more than they do. I can tell you first hand that Apollo cares deeply about open source software (OSS culture is ingrained into the company right from the top), and goes to great lengths to make developers happy and provide ways for developers to use a large portion of the things it builds for free - no strings attached. When I encounter other companies that act like this, I instantly think they should get anything they need to help themselves flourish and thrive - Apollo is no different.
> They're taking funding and attention away from other more deserving projects.
I've gotta say, I completely disagree with this statement. Meteor and Apollo have both helped thousands of developers do amazing things, for free. Yes, I work for Apollo, but I'll detach for a sec; I can't think of any open source software company on the planet that deserves this more than they do. I can tell you first hand that Apollo cares deeply about open source software (OSS culture is ingrained into the company right from the top), and goes to great lengths to make developers happy and provide ways for developers to use a large portion of the things it builds for free - no strings attached. When I encounter other companies that act like this, I instantly think they should get anything they need to help themselves flourish and thrive - Apollo is no different.
>> What's really happening here is that both Apollo and its amazing supporters/investors have witnessed first hand the impact that data graph based technology can have on the lives of developers and the productivity (and bottom line) of companies
It's just a bunch of wealthy people using their money to force their opinions about software development onto as many developers as possible...
I can guarantee that there exists simpler solutions outside of the GraphQL bubble that far exceed what can be achieved with Apollo in terms of both flexibility and productivity. I could share some links if you are genuinely interested.
It's just a bunch of wealthy people using their money to force their opinions about software development onto as many developers as possible...
I can guarantee that there exists simpler solutions outside of the GraphQL bubble that far exceed what can be achieved with Apollo in terms of both flexibility and productivity. I could share some links if you are genuinely interested.
> [W]itnessed first hand the impact that data graph based technology can have on the lives of developers and the productivity (and bottom line) of companies
Have you quantified this? I'd be curious to see how much productive companies are using GraphQL when compared to creating, e.g., generic REST API's.
Have you quantified this? I'd be curious to see how much productive companies are using GraphQL when compared to creating, e.g., generic REST API's.
The danger with external funding is forced growth before the platform is ready to be monetized.
Actually, this isn't a worry for Apollo. We've been growing and monetizing for a while, and our partners are an amazing group of people who get what we do. They aren't forcing us to do anything.
My observation was Meteor development really slowed down when Galaxy was ramping up. That doesn't necessarily imply that investors forced anyone to do anything, but as an external observer it appeared that resources were substantially re-prioritized, whatever the reason could be. Maybe it wasn't the investors, but someone led that re-prioritization. Maybe there were things going on with Galaxy that required immediate attention, and the team only had so many engineers / devops / testers, etc. It could have been a lot of things.
We really love Apollo and use its open-source software in our GraphQL stack.
With that being said, I really hope Apollo will provide their iOS library some much needed love soon, or clearly imply they're not developing it anymore. They've mentioned they're hiring an iOS engineer maybe a year ago? but largely the repo has gone neglected. I've made some modest improvements for our sake, but PRs generally go unreviewed forever, so it doesn't seem worth writing the tests to get my work in a landable state.
With that being said, I really hope Apollo will provide their iOS library some much needed love soon, or clearly imply they're not developing it anymore. They've mentioned they're hiring an iOS engineer maybe a year ago? but largely the repo has gone neglected. I've made some modest improvements for our sake, but PRs generally go unreviewed forever, so it doesn't seem worth writing the tests to get my work in a landable state.
Hi from the Apollo team! We hired a mobile engineer who is starting within a few weeks. Keep your eyes out for lots of exciting improvements to Apollo iOS soon!
I like GraphQL a lot — but found that writing mutations involved a ton of boilerplate. For example, I'd have to keep writing the same key names over and over again. Anyone else experience this?
You could use input types and reduce the boilerplate to a single parameter, which you then send as an object in the request variables?
yeah that's what i did. inputs also help a bit with code reuse, imho.
Yes, Mutations are still annoying to write. Especially with all the optimisticResponses and pushing things into collections.
I think GraphQL is pretty cool, but my experience with Apollo is mostly negative. The query and mutation components for example - on the surface, they seem pretty useful, however, in reality, its a bad idea to have your view layer directly making API calls - those should be in some other module thats lower level, away from the view and easier to test. But instead, people use these query components everywhere, and all of the sudden, all the app's logic is weaved into the view and very hard to unit test.
Apollo's local state tools are bad in my opinion as well. It might work OK if you just want to keep a few global flags, but anything more, and it gets really verbose. Especially if you want to update state based on current state, you have to first manually fetch the current state, then update it, then save that object back, every time. On top of this, its often necessary to write mutations just to update local state, which are written as GraphQL strings - one mistake in this syntax and you can be stuck trying to debug it for a while. How any of that is easier than just having Redux I still don't understand.
Overall, Apollo feels like a worse version of Angular.js - an app framework thats trying to do way too much. If your app just made basic GET requests and had no other logic, I could see how Apollo could be useful (but why have a framework at all in this case?) However, if you have complex logic or local state, Apollo quickly becomes and opinionated, unwieldy piece of junk
Apollo's local state tools are bad in my opinion as well. It might work OK if you just want to keep a few global flags, but anything more, and it gets really verbose. Especially if you want to update state based on current state, you have to first manually fetch the current state, then update it, then save that object back, every time. On top of this, its often necessary to write mutations just to update local state, which are written as GraphQL strings - one mistake in this syntax and you can be stuck trying to debug it for a while. How any of that is easier than just having Redux I still don't understand.
Overall, Apollo feels like a worse version of Angular.js - an app framework thats trying to do way too much. If your app just made basic GET requests and had no other logic, I could see how Apollo could be useful (but why have a framework at all in this case?) However, if you have complex logic or local state, Apollo quickly becomes and opinionated, unwieldy piece of junk
Thanks for the feedback, and sorry to hear about these issues! I'll try to address them below:
> in reality, its a bad idea to have your view layer directly making API calls - those should be in some other module thats lower level, away from the view and easier to test.
Apollo doesn't force you to cram everything into your view layer. If you want full control over how your interact with your GraphQL backend, you can wrap "Apollo Client" in whatever layer you want. If you're using a view layer integration like "React Apollo", we try to help reduce some of the extra layer boilerplate that can come up, when integrating your view layer with other controller, model, business, etc. layers. Again though, none of this is mandatory, and it's important to understand that components in "React Apollo" aren't directly making API calls. Query, Mutation and Subscription components are just React components, that communicate with Apollo Client behind the scenes. Here, "Apollo Client" is the lower level module that you're referring to, that then takes care of API calls. As for testing, you can (and should if possible) test all parts of your application, be it view layer or lower level API integration points. We provide tools to help unit test React Apollo components with mock/fake data (that can be integrated with any popular React testing library), and there are lots of great ways to unit/integration test Apollo Client (and its associated libraries).
> But instead, people use these query components everywhere, and all of the sudden, the view balloons with logic like parameter validation, error handling, etc... Everything is weaved into the view and very hard to unit test.
React gives you a toolset to work with and manage components. Can you build an application that gets out of control using React? Absolutely. Apollo gives you a toolset that can be used to work with data. Can you build an application that gets out of control with Apollo? Most definitely. Just like the React team, we've taken a lot of steps to help developers avoid these application design pitfalls. We spend a lot of time working on our docs, routinely blog about best practices, and help developers whenever/wherever we can, through various social channels, meetups, conferences, etc. That being said, we've worked side by side with hundreds of developers who are using Apollo happily and productively, and if anything, have found that Apollo's view layer integration has helped them get their countless view layer data integration points under control (and made things easier to test).
> Apollo's local state tools are bad in my opinion as well. To update any state, you have to constantly fetch the current state and then make a modification.
This isn't accurate. Actually, in most cases saving and updating local state is as easy as just running a query/mutation - everything happens for you seamlessly. Apollo Client's local state capabilities have changed quite a bit as of version 2.5, so give a newer version a try (and see the updated docs) to see if that helps.
> This feels a lot more cumbersome than just having redux and reducers.
Redux can definitely come in handy, but it has its strengths and weaknesses (like all tech). One of the core tenants of Apollo Client's local state handling is that it knows how to work with GraphQL out of the box. This means AC's local state handling can be used to do all sorts of great things, that would require more work to accomplish with something like Redux. Things like working with a specialized cache that normalizes GraphQL query responses to speed up cache reading/writing, know how to merge local state with results returned from remote queries so applications get everything they need from local and remote after running a single query, replicate remote GraphQL resolver functionality locally to inject advanced data management techniques on the client side, etc.
> Overall, Apollo feels like a worse version of Angular.js - an app framework thats trying to do way too much. If your app just made basic GET requests and had no other logic, I could see how Apollo could be useful. But anything more complex, and the code becomes a weaving, untestable mess.
Some of the biggest companies on the planet (with amazingly complex applications and systems) are using Apollo and loving it. That being said, we're always striving to do better and welcome constructive feedback like yours. Please consider opening issues in any of our Github repos with your problems and suggestions regarding how we can help make things better.
> in reality, its a bad idea to have your view layer directly making API calls - those should be in some other module thats lower level, away from the view and easier to test.
Apollo doesn't force you to cram everything into your view layer. If you want full control over how your interact with your GraphQL backend, you can wrap "Apollo Client" in whatever layer you want. If you're using a view layer integration like "React Apollo", we try to help reduce some of the extra layer boilerplate that can come up, when integrating your view layer with other controller, model, business, etc. layers. Again though, none of this is mandatory, and it's important to understand that components in "React Apollo" aren't directly making API calls. Query, Mutation and Subscription components are just React components, that communicate with Apollo Client behind the scenes. Here, "Apollo Client" is the lower level module that you're referring to, that then takes care of API calls. As for testing, you can (and should if possible) test all parts of your application, be it view layer or lower level API integration points. We provide tools to help unit test React Apollo components with mock/fake data (that can be integrated with any popular React testing library), and there are lots of great ways to unit/integration test Apollo Client (and its associated libraries).
> But instead, people use these query components everywhere, and all of the sudden, the view balloons with logic like parameter validation, error handling, etc... Everything is weaved into the view and very hard to unit test.
React gives you a toolset to work with and manage components. Can you build an application that gets out of control using React? Absolutely. Apollo gives you a toolset that can be used to work with data. Can you build an application that gets out of control with Apollo? Most definitely. Just like the React team, we've taken a lot of steps to help developers avoid these application design pitfalls. We spend a lot of time working on our docs, routinely blog about best practices, and help developers whenever/wherever we can, through various social channels, meetups, conferences, etc. That being said, we've worked side by side with hundreds of developers who are using Apollo happily and productively, and if anything, have found that Apollo's view layer integration has helped them get their countless view layer data integration points under control (and made things easier to test).
> Apollo's local state tools are bad in my opinion as well. To update any state, you have to constantly fetch the current state and then make a modification.
This isn't accurate. Actually, in most cases saving and updating local state is as easy as just running a query/mutation - everything happens for you seamlessly. Apollo Client's local state capabilities have changed quite a bit as of version 2.5, so give a newer version a try (and see the updated docs) to see if that helps.
> This feels a lot more cumbersome than just having redux and reducers.
Redux can definitely come in handy, but it has its strengths and weaknesses (like all tech). One of the core tenants of Apollo Client's local state handling is that it knows how to work with GraphQL out of the box. This means AC's local state handling can be used to do all sorts of great things, that would require more work to accomplish with something like Redux. Things like working with a specialized cache that normalizes GraphQL query responses to speed up cache reading/writing, know how to merge local state with results returned from remote queries so applications get everything they need from local and remote after running a single query, replicate remote GraphQL resolver functionality locally to inject advanced data management techniques on the client side, etc.
> Overall, Apollo feels like a worse version of Angular.js - an app framework thats trying to do way too much. If your app just made basic GET requests and had no other logic, I could see how Apollo could be useful. But anything more complex, and the code becomes a weaving, untestable mess.
Some of the biggest companies on the planet (with amazingly complex applications and systems) are using Apollo and loving it. That being said, we're always striving to do better and welcome constructive feedback like yours. Please consider opening issues in any of our Github repos with your problems and suggestions regarding how we can help make things better.
"This isn't accurate. Actually, in most cases saving and updating local state is as easy as just running a query/mutation - everything happens for you seamlessly. Apollo Client's local state capabilities have changed quite a bit as of version 2.5, so give a newer version a try (and see the updated docs) to see if that helps."
You are glossing over the fact that there is a 3rd part, writing a reducer! This part is the most cumbersome in my opinion.
Lets say you wanted to keep a counter and increment it in your app. With Redux, you add it to your state, write an "increaseCounter" action, and then write a reducer. This reducer is just a plain function without any dependencies. A unit test for this reducer would just test that the count was updated.
However, with local state management with Apollo, you would either need to 1. write an incrementCounter mutation and an incrementCounter reducer. Inside that reducer, you would have to fetch the current count from the cache, update that count, and then write the results from the cache. 2. Just use `cache.writeQuery` or `cache.writeData`, but in either case, you need to fetch the current state of the cache, modify it, and then write the object back.
The problem with this is that any time you want to modify state, you need to always fetch the current state, and then write the state back. This is bad because
1. its super repetitive 2. it tightly binds the code of "how the state changes" to "how the state is queried and saved"
Overall, this whole approach of having to write a mutation and a reducer for every state change is annoying and verbose. Redux is just overall a better, more convenient pattern to incrementally update a piece of state.
We actually thought about adding a Redux layer on top of Apollo, so that we would just have a single "Redux" mutation that fetches the current state, passes it to a reducer, and then saves the transformed state in the cache to avoid all this fetching and saving, but then were afraid of potential performance issues of homerolling our own Redux, and went with actual Redux instead.
You are glossing over the fact that there is a 3rd part, writing a reducer! This part is the most cumbersome in my opinion.
Lets say you wanted to keep a counter and increment it in your app. With Redux, you add it to your state, write an "increaseCounter" action, and then write a reducer. This reducer is just a plain function without any dependencies. A unit test for this reducer would just test that the count was updated.
However, with local state management with Apollo, you would either need to 1. write an incrementCounter mutation and an incrementCounter reducer. Inside that reducer, you would have to fetch the current count from the cache, update that count, and then write the results from the cache. 2. Just use `cache.writeQuery` or `cache.writeData`, but in either case, you need to fetch the current state of the cache, modify it, and then write the object back.
The problem with this is that any time you want to modify state, you need to always fetch the current state, and then write the state back. This is bad because
1. its super repetitive 2. it tightly binds the code of "how the state changes" to "how the state is queried and saved"
Overall, this whole approach of having to write a mutation and a reducer for every state change is annoying and verbose. Redux is just overall a better, more convenient pattern to incrementally update a piece of state.
We actually thought about adding a Redux layer on top of Apollo, so that we would just have a single "Redux" mutation that fetches the current state, passes it to a reducer, and then saves the transformed state in the cache to avoid all this fetching and saving, but then were afraid of potential performance issues of homerolling our own Redux, and went with actual Redux instead.
I work a little bit with a graphql backend API and apollo in the front, and I still have no idea why this is better than a rest API and regular fetches in the front. I feel like we are moving backwards. Way more code to type out which fields you want back, and the same in the back + the actual resolvers/mutations. I really don’t get any of this..
How does this compare to using CouchDB/PouchDB?
(maybe it doesn't, but at first glance it looks similar in a lot of ways to me)
(maybe it doesn't, but at first glance it looks similar in a lot of ways to me)
CouchDB is a document store style database. GraphQL is more focused on the API layer (how do I query any underlying data sources for exactly the data I need) instead of tying you into one particular database. So, in theory, some of your GraphQL objects might live in CouchDB but others might live in PostgreSQL or a file store.
Ok, that's pretty cool
Thank you for the insight!
Thank you for the insight!
I found that despite the name, making something like a graph crawler is kinda hard in graph ql because you have to write "a new schema for discovery of schema" (all is made kinda hard to query the schema itself)
Interesting article. However, I disagree with the premise. Data management is certainly not the hardest problem in app development.
Everybody knows there are exactly three hard problems in software development:
1. Naming Conventions
2. Off-by-one-Errors
Everybody knows there are exactly three hard problems in software development:
1. Naming Conventions
2. Off-by-one-Errors
I was a huge proponent of GraphQL and used it for many clients. For me, it solved a specific need - I can write an API backend that is scalable across clients (Web, iOS, Android). However, having said that, I have made the mistake of using GraphQL for projects that only have web interfaces with somewhat complex querying (but with vague ideas of expanding to apps later). It wasted so much of my time that I ditched the project halfway and re-wrote everything using normal CRUD interfaces. I use Phoenix + LiveView now, and it's truly a god send to write code without having to touch any Javascript. Not only are my interfaces way lighter, but they also feel very natural and I get server rendered error messages out of the box without having to parse them on my frontend.
GraphQL is a rabbit hole. Don't use it unless absolutely necessary or you have a small to mid-sized team for large scale projects. Atleast on Phoenix/Elixir side of things, it's just not worth the effort - you need to write resolvers apart from your schema/models, handle changeset errors in the frontend (which there is no way to deal with directly as of this comment) and if you're working with VueJS, then good luck. My package.json is so bloated that I am starting to feel it's all just a pack of cards. I can't stress enough how much valuable developer time I wasted getting all these bits and pieces working together. Usually, you can't use one because the other one is outdated, or has some weird Github issue you now need to address. And then that causes another probelm..and another one..[the rabbit hole goes deep]
GraphQL is a rabbit hole. Don't use it unless absolutely necessary or you have a small to mid-sized team for large scale projects. Atleast on Phoenix/Elixir side of things, it's just not worth the effort - you need to write resolvers apart from your schema/models, handle changeset errors in the frontend (which there is no way to deal with directly as of this comment) and if you're working with VueJS, then good luck. My package.json is so bloated that I am starting to feel it's all just a pack of cards. I can't stress enough how much valuable developer time I wasted getting all these bits and pieces working together. Usually, you can't use one because the other one is outdated, or has some weird Github issue you now need to address. And then that causes another probelm..and another one..[the rabbit hole goes deep]
"@babel/core": "^7.0.0",
"@babel/plugin-syntax-dynamic-import": "^7.2.0",
"@babel/preset-env": "^7.0.0",
"apollo-absinthe-upload-link": "^1.5.0",
"apollo-cache-inmemory": "^1.6.1",
"apollo-client": "^2.6.1",
"apollo-link": "^1.2.11",
"apollo-link-context": "^1.0.17",
"babel-loader": "^8.0.0",
"babel-preset-env": "^1.7.0",
"coffee-loader": "^0.9.0",
"copy-webpack-plugin": "^4.5.0",
"css-loader": "^2.1.1",
"file-loader": "^3.0.1",
"graphql": "^14.3.1",
"graphql-tag": "^2.10.1",
"mini-css-extract-plugin": "^0.4.0",
"node-sass": "^4.12.0",
"optimize-css-assets-webpack-plugin": "^5.0.1",
"resolve-url-loader": "^3.1.0",
"sass-loader": "^7.1.0",
"script-loader": "^0.7.2",
"style-loader": "^0.23.1",
"uglifyjs-webpack-plugin": "^1.2.4",
"vue-apollo": "^3.0.0-beta.30",
"vue-loader": "^15.7.0",
"vue-template-compiler": "^2.6.10",
Just want to give a shout out to Hasura (https://hasura.io/) here which removed a lot of these problems for me.
A thousand times yes. I wish my team lead/members would read this and believe it.
This is awesome, congrats!
Does this mean Meteor is dead?
Also, the end paragraph mentions some cloud-based graph management system. Is there any chance they could do a decentralized graph management system (something like https://github.com/brysgo/graphql-gun ) instead of some centralized solution?
I don't want my GraphQL data getting locked in to some vendor. Any reason why I shouldn't worry about this? Thanks!
Does this mean Meteor is dead?
Also, the end paragraph mentions some cloud-based graph management system. Is there any chance they could do a decentralized graph management system (something like https://github.com/brysgo/graphql-gun ) instead of some centralized solution?
I don't want my GraphQL data getting locked in to some vendor. Any reason why I shouldn't worry about this? Thanks!
Meteor, as a framework, was solid for its time. I don't think they could've envisioned how much the JavaScript ecosystem would change after its launch. It tried to solve a great deal of problems that ultimately were solved in smaller, more focused libraries.
Thanks, this is a good take.
I would add: now it's everyone else's job to make those smaller, more focused libraries work together. The time wasted is unfathomable, but the blame for misconfiguration now falls on individual developers, rather than monolithic frameworks. Progress?
I would add: now it's everyone else's job to make those smaller, more focused libraries work together. The time wasted is unfathomable, but the blame for misconfiguration now falls on individual developers, rather than monolithic frameworks. Progress?
At least in terms of tooling, you see things like create-react-app, vue-cli, etc. These toolkits, and their accompanying CLIs, abstract away configuration of babel, webpack, etc.
These are good, but if you need to customize further, you interface with the toolkit (which only allows you to go so far), or you eject entirely.
Many people think it's time wasted to really understand how to setup and use (individually) webpack and babel and friends. I disagree because if you ever do need to dig in to these tools, since you've used them individually, you understand what you need to change.
If you eject from a toolkit but don't understand the underlying tools, you could be up a creek without a paddle. So you can certainly make things simpler, but you can't replace having the experience and understanding of what each individual tool does, and how to interface with it.
I would say the ecosystem changes, in aggregate, are probably a loss for new programmers. You have a much wider API surface to be aware of when using all the tools and how to integrate them. But for a senior front end engineer, it's unlocked the ability to have very fine grained control over the bundles you're creating.
These are good, but if you need to customize further, you interface with the toolkit (which only allows you to go so far), or you eject entirely.
Many people think it's time wasted to really understand how to setup and use (individually) webpack and babel and friends. I disagree because if you ever do need to dig in to these tools, since you've used them individually, you understand what you need to change.
If you eject from a toolkit but don't understand the underlying tools, you could be up a creek without a paddle. So you can certainly make things simpler, but you can't replace having the experience and understanding of what each individual tool does, and how to interface with it.
I would say the ecosystem changes, in aggregate, are probably a loss for new programmers. You have a much wider API surface to be aware of when using all the tools and how to integrate them. But for a senior front end engineer, it's unlocked the ability to have very fine grained control over the bundles you're creating.
The power comes in two fronts. The ease that the cli tools you mentioned to help you gather a solid baseline of these smaller packages, and then, giving you the ability to decompose the features into interchangeable parts by ejecting or just by virtue of how small the packages are. The problem with monolithic frameworks in my opinion lies with the second part, they develop to he opinionated and for valid reasons, but sometimes that create really intense friction when changes need to happen in particular ways.
[deleted]
> Does this mean Meteor is dead?
Absolutely not! We depend on it internally (engine.apollographql.com is a Meteor app), and Galaxy hosting revenue is THE reason we didn't have to raise money until we felt like it, which is why we got to pick our investors in this round.
Behind the scenes, as the lead developer for both Apollo Client and Meteor, I am constantly borrowing technologies from one to benefit the other. Meteor may move more slowly these days, but that's because it's relatively mature. Apollo has to move more quickly because we're still making (and remaking) fundamental decisions.
Even as community enthusiasm for Meteor has slowed, Galaxy revenue has not, and it's honestly not the worst thing for an open-source project if people who came for the hype either (a) find real reasons to stay, or (b) take their hype-thirst elsewhere.
I have some ideas for increasing Meteor contributor engagement that I'll be giving a talk about at the next Meteor Night (tentatively July 9th in SF).
Absolutely not! We depend on it internally (engine.apollographql.com is a Meteor app), and Galaxy hosting revenue is THE reason we didn't have to raise money until we felt like it, which is why we got to pick our investors in this round.
Behind the scenes, as the lead developer for both Apollo Client and Meteor, I am constantly borrowing technologies from one to benefit the other. Meteor may move more slowly these days, but that's because it's relatively mature. Apollo has to move more quickly because we're still making (and remaking) fundamental decisions.
Even as community enthusiasm for Meteor has slowed, Galaxy revenue has not, and it's honestly not the worst thing for an open-source project if people who came for the hype either (a) find real reasons to stay, or (b) take their hype-thirst elsewhere.
I have some ideas for increasing Meteor contributor engagement that I'll be giving a talk about at the next Meteor Night (tentatively July 9th in SF).
(Re: Meteor) Our company is scaling up and we're worried that Galaxy won't be able to handle growing demand - do you have any thoughts on making the meteor system more scalable and affordable as companies get larger?
I love meteor, and don't really want to move our stack off it but it's becoming a more real thing that we have to face in the near future as it's hard to see how it can grow with us!
I can only imagine the reason galaxy revenue is increasing is that the companies started off Meteor 2-3 years ago are now becoming real. I know a few companies in our YC batch that use Meteor.
I love meteor, and don't really want to move our stack off it but it's becoming a more real thing that we have to face in the near future as it's hard to see how it can grow with us!
I can only imagine the reason galaxy revenue is increasing is that the companies started off Meteor 2-3 years ago are now becoming real. I know a few companies in our YC batch that use Meteor.
Most apps are simple, don’t need to send much data around if you don’t put 3-10 user tracker in, and Rest is just really, really simple for most parts.
In every project I worked so far that used GraphQL, developers tend to not care about backwards compatibility of APIs because having tons of optional properties in query responses doesn’t feel nice.
As always, there are exceptions and if it makes sense, sure, go ahead. But be aware of the dependencies and the magic you get into your project. Oh, and don’t use it for file upload, that’s just painful.