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