Apollo raises $22M to simplify app development

As a user of GraphQL with Apollo since a year, I still don’t see how it simplifies app development. Actually, having such a huge dependency in the code feels more like a liability.<p>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.<p>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.<p>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.

I like graphql as technology - I find it just a better way than REST for building services, and I like that it&#x27;s just json - simple easy to debug text responses. I like that there are companies investing in this technology.<p>But, I don&#x27;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.<p>Docker Inc&#x27;s struggles come to mind here...

(disclaimer: I worked at Meteor&#x2F;Apollo for about 5 years)<p>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.

Part of me thinks that if Apollo was a good company, they wouldn&#x27;t need to keep raising this kind of funding by now. There are plenty of alternatives which burned a fraction of what Meteor&#x2F;Apollo has burned to build this. They&#x27;re taking funding and attention away from other more deserving projects.

We really love Apollo and use its open-source software in our GraphQL stack.<p>With that being said, I really hope Apollo will provide their iOS library some much needed love soon, or clearly imply they&#x27;re not developing it anymore. They&#x27;ve mentioned they&#x27;re hiring an iOS engineer maybe a year ago? but largely the repo has gone neglected. I&#x27;ve made some modest improvements for our sake, but PRs generally go unreviewed forever, so it doesn&#x27;t seem worth writing the tests to get my work in a landable state.

I like GraphQL a lot — but found that writing mutations involved a ton of boilerplate. For example, I&#x27;d have to keep writing the same key names over and over again. Anyone else experience this?

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&#x27;s logic is weaved into the view and very hard to unit test.<p>Apollo&#x27;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&#x27;t understand.<p>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

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&#x2F;mutations. I really don’t get any of this..

How does this compare to using CouchDB&#x2F;PouchDB?<p>(maybe it doesn&#x27;t, but at first glance it looks similar in a lot of ways to me)

I found that despite the name, making something like a graph crawler is kinda hard in graph ql because you have to write &quot;a new schema for discovery of schema&quot; (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.<p>Everybody knows there are exactly three hard problems in software development:<p>1. Naming Conventions<p>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&#x27;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.<p>GraphQL is a rabbit hole. Don&#x27;t use it unless absolutely necessary or you have a small to mid-sized team for large scale projects. Atleast on Phoenix&#x2F;Elixir side of things, it&#x27;s just not worth the effort - you need to write resolvers apart from your schema&#x2F;models, handle changeset errors in the frontend (which there is no way to deal with directly as of this comment) and if you&#x27;re working with VueJS, then good luck. My package.json is so bloated that I am starting to feel it&#x27;s all just a pack of cards. I can&#x27;t stress enough how much valuable developer time I wasted getting all these bits and pieces working together. Usually, you can&#x27;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]<p><pre><code> &quot;@babel&#x2F;core&quot;: &quot;^7.0.0&quot;, &quot;@babel&#x2F;plugin-syntax-dynamic-import&quot;: &quot;^7.2.0&quot;, &quot;@babel&#x2F;preset-env&quot;: &quot;^7.0.0&quot;, &quot;apollo-absinthe-upload-link&quot;: &quot;^1.5.0&quot;, &quot;apollo-cache-inmemory&quot;: &quot;^1.6.1&quot;, &quot;apollo-client&quot;: &quot;^2.6.1&quot;, &quot;apollo-link&quot;: &quot;^1.2.11&quot;, &quot;apollo-link-context&quot;: &quot;^1.0.17&quot;, &quot;babel-loader&quot;: &quot;^8.0.0&quot;, &quot;babel-preset-env&quot;: &quot;^1.7.0&quot;, &quot;coffee-loader&quot;: &quot;^0.9.0&quot;, &quot;copy-webpack-plugin&quot;: &quot;^4.5.0&quot;, &quot;css-loader&quot;: &quot;^2.1.1&quot;, &quot;file-loader&quot;: &quot;^3.0.1&quot;, &quot;graphql&quot;: &quot;^14.3.1&quot;, &quot;graphql-tag&quot;: &quot;^2.10.1&quot;, &quot;mini-css-extract-plugin&quot;: &quot;^0.4.0&quot;, &quot;node-sass&quot;: &quot;^4.12.0&quot;, &quot;optimize-css-assets-webpack-plugin&quot;: &quot;^5.0.1&quot;, &quot;resolve-url-loader&quot;: &quot;^3.1.0&quot;, &quot;sass-loader&quot;: &quot;^7.1.0&quot;, &quot;script-loader&quot;: &quot;^0.7.2&quot;, &quot;style-loader&quot;: &quot;^0.23.1&quot;, &quot;uglifyjs-webpack-plugin&quot;: &quot;^1.2.4&quot;, &quot;vue-apollo&quot;: &quot;^3.0.0-beta.30&quot;, &quot;vue-loader&quot;: &quot;^15.7.0&quot;, &quot;vue-template-compiler&quot;: &quot;^2.6.10&quot;, </code></pre> When DHH ranted about these, I never believed him and I always thought he was not upto par with JS frameworks. But turns out, everything he said was true. Turns out, you don&#x27;t need GraphQL at all for most use cases when you can simply get away with something like Tubrolinks or LiveView.

This is awesome, congrats!<p>Does this mean Meteor is dead?<p>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 <a href="https:&#x2F;&#x2F;github.com&#x2F;brysgo&#x2F;graphql-gun" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;brysgo&#x2F;graphql-gun</a> ) instead of some centralized solution?<p>I don&#x27;t want my GraphQL data getting locked in to some vendor. Any reason why I shouldn&#x27;t worry about this? Thanks!