I did a huge heads down on GraphQL vs AppSync vs Firebase for an app I'm building around document collaboration, annotation and sync for people working with PDFs and web content (https://getpolarized.io/) - it's kind of like an offline web browser.... anyway.
GraphQL is super awesome at what it does but it's definitely not designed for rapid prototyping applications.
The thing about GraphQL is that it's middleware. It's designed to act as really nice glue between multiple backends.
It solves a lot of nice problems like over-fetching too much data, calling too many APIs, etc.
The problem is that you really don't need these to get an app shipped immediately.
The REAL sweet spot for GraphQL is for a company like Netflix or Facebook where you have 1500 APIs and tons of problems with data over-fetch and you have the time to sit down and do things right.
I think I'm going to end up going with Firebase just because you can bang something out FAST and get it shipped.
It's not going to be perfect but you can ship an MVP and start making revenue and/or grow your user base while you figure things out.
GraphQL to REST is a more typical comparison. In this case: designing a GraphQL API is substantially easier to both make and consume; while REST just tells you "here's some guidelines, now go do it however you want", GraphQL enforces a much more consistent view of how an API should look, while allowing clients much more freedom in how they get the data they need.
Where you start running into issues is the surrounding tooling. Integrating a typical REST API into an APM monitoring solution is a cinch, because all of these tools know how to read the incoming requests, HTTP methods, paths, bodies, etc. With GraphQL, you might be left building glue for your APM tool of choice, or just using the highly limited, but at least specialized, Apollo Engine. Enforcing strict rate limiting is easy with REST; very difficult with GraphQL due to how complex and free-form queries are.
Optimizing your backend to support those free-form queries is also (I dare say intractably) difficult; I haven't seen a single backend framework which doesn't actively encourage an N+1 problem on any query which returns multiple objects of data. AppSync as well, my god is that an evil play from AWS; if you've got separate lambda functions serving all the different nodes in your graph, a single query could trigger dozens, or even hundreds, of invocations. Combine that with their guidance to use Aurora Serverless and any casual observer might say that they're actively exploiting the unfortunate ignorance of an engineer trying to jump on the latest trends.
I don't believe any of these things are problems with GraphQL. I think they're issues with ecosystem immaturity, and I hope they get better over time. Frankly, every single backend library I've used sucks; its designed to be awesome on the frontend, and it is.
I think you're right that, right now, its best suited to large organizations. Large organizations can engineer around all of its issues and extract a LOT of value from it. Medium organizations are almost immediately going to run into ecosystem immaturity and scaling issues. Small organizations are going to get the most value from an "all in one" solution, whether that's Firebase, or a simple REST API on App Engine, or something like that.
But I could be wrong in my analysis that its not a core issue with GraphQL, and there are subtle complexities with the API definition language which make scaling it for anyone who isn't Facebook intractable. Time will tell.
Well then you haven't really looked :)
https://join-monster.readthedocs.io/en/latest/
https://github.com/graphile/postgraphile
These are all examples of tools/libs that implement a graphql api without a N+1 issue