[burtonator]

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.

[013a]

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.

[ruslan_talpa]

> 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

Well then you haven't really looked :)

https://join-monster.readthedocs.io/en/latest/

https://github.com/graphile/postgraphile

https://www.prisma.io/

https://subzero.cloud/

These are all examples of tools/libs that implement a graphql api without a N+1 issue

[013a]

Those are great resources. But all of them appear to be tightly coupled with a SQL storage backend. That's valuable, but what I believe the ecosystem needs is a generic system which can "pre-compile" a GraphQL query into a backend language data structure which the developer can then transpose into a database query.

I think Facebook's Dataloader is more close to a solution.

[BenjieGillam]

PostGraphile is built on Graphile Engine which is completely backend-independent (like GraphQL itself). This is what we use in PostGraphile for the "look-ahead" functionality, allowing you to build a database/API/backend query that represents a full GraphQL query as one action. You can read more about it here, though it's currently not as well documented as PostGraphile itself. https://www.graphile.org/graphile-build/

[macca321]

Almost like a Language INtegrated Query (LINQ) in C#?

OData did exactly this years ago, and got heavily criticised for giving too much querying power to the client side, as (without expert usage on the server side to whitelist the query) a client could run queries that would overload the server.

You're damned if you do, and damned if you don't.

[tirumaraiselvan]

We at Hasura[0] use a GraphQL to SQL compiler approach[1] so its just ONE query no matter the size of the Graphql query.

[0] https://hasura.io [1] https://blog.hasura.io/architecture-of-a-high-performance-gr...

[hakanito]

Facebook released DataLoader [1] to help reduce the number of database invocations. As long as you write your queries to fit the loader pattern it's pretty straight forward. Been trying out a golang port [2] for a month or two and it really (really!) improves performance.

[1] https://github.com/facebook/dataloader [2] https://github.com/graph-gophers/dataloader

[cheriot]

GraphQL shifts complexity to the server instead of the client. That can be an advantage when there's multiple clients or just one client iterating faster than the underlying logic. There's certainly a short term cost to GraphQL compared to REST, but there's a lot of use cases with positive ROI outside FANGs.

When read and write becomes real time sync, though, I've always thought Firebase was under appreciated.

[vlozko]

I'm not entirely sure I agree that it shifts complexity. I think there's more complexity on both the client and the server end. I work extensively with GraphQL on the client end (iOS) and there's certainly more work involved compared to a REST endpoint for more larger applications. Notably:

* The mapping of the response to the types used in your app balloons. There's heavy use of Swift's Codable to map the JSON result to objects. I'm finding in a lot of cases where I'd be making queries and I don't need the resultant root object but rather a value one or two levels deeper. This has caused me to write a number of "shell" types to help streamline the decoding process.

* Different GraphQL requests can query for different fields on the same type, thus forcing your app to have to different types for arguably the same thing or have optional fields in more places that I would like.

* There's security implications with exposing your backend to any kind of request. GraphQL supports hashed queries so that the entire request isn't sent over each time and prevent the abuse that can result from an exposed API. Setting up and supporting this infrastructure takes some amount of resources.

* More complex to provide response metadata, such as cache control and request/response IDs. Granted, some of this could/should be moved to the response header but more complex types are trickier to handle.

That all being said, I'm quite happy with the trade offs compared to using REST, including:

* With REST, some of the endpoints ended up returning massive results as they had to support Android, iOS, and Web use cases. It's really hard to audit what fields were still in use by the app and the ROI on cleaning up the endpoints was minimal.

* Related to the above, it's easier to deprecate certain fields and make the changes on all the platforms appropriately. Given that GraphQL supports tracing of queries/fields usage, it's a lot easier to know when a field is no longer in use and be able to clean it up. Granted, this is more of a backend plus vs a client but it provides a much more smoother migration process for the client.

* Explicit declaration of non-null fields. Fantastic for mapping types. The entire GraphQL query fails if a resolver returns null for a non-null-defined field, giving the app a piece of mind with regards to type safety.

I agree there's definitely a short-term cost but a big ROI.

[jchb]

> tons of problems with data over-fetch

What is the GraphGL story on caching and closest point of presence redirection? We build a mobile app that consumes various "enterprisy" HTTP-based APIs. Often, due to how the APIs are designed to support a range of different frontends, we have to either fetch more data than we need, or do a bunch of granular requests where we would prefer to do a single large one. But most of the time that is outweighed by the fact that many responses are cached in CDN (Content Delivery Network). Since our users are spread out globally, going to the origin server for every response would in many cases imply a latency of 100-200 milliseconds, which wouldn't be acceptable.

[krschultz]

It depends, the GraphQL spec isn't all that opinionated on caching. There's a little bit of guidance on the matter but not much. [1] The implementation of GraphQL that you choose might be more "batteries included" though.

[1] https://graphql.org/learn/caching/

[baby]

Agree with you, for small apps it looks like this is a lot of effort for little benefits. For large companies that deal with huge APIs, maybe it's good.

[cdaringe]

Hard disagree for many cases. GraphQL APIs are free with db reflection tools--ga ga ga ga GREAT for prototyping. Shoutout to postgraphile.

[BenjieGillam]

Thanks!

[hamandcheese]

GraphQL is not comparable to Firebase, it is comparable to implementing your own REST/gRPC/Thrift API.

When comparing apples to apples, GraphQL is amazing for rapidly iterating.

I think the biggest risk with GraphQL is it’s too easy to just mirror your data structures as an API.

Also, unrelated to the above, but we use Firebase for a few auxiliary real-time needs at work and it goes down constantly.

[he0001]

>When comparing apples to apples, GraphQL is amazing for rapidly iterating.

Rapidly iterating what?

[hamandcheese]

Mostly the frontend. I’m comparing to a React+Redux+REST app where for every new resource you have to:

- create a new action - turn that action into requests via some middleware - denornalize and put in your store - maybe write a selector to get the data you need from your store

[k__]

Did you use AWS Amplify?

I had the impression it was like Firebase for quick prototypes (saw someone build a product in only 4h once), but you get CloudFormation templates out of it, which makes it much more flexible in the long run, when you customize more and more.

[ivanhoe]

Not necessarily, on small projects that are being rapidly developed it's very common that you need to change many times the data structures returned by api, as front-end is iterating on the design and ideas and figures out the new pieces of data that they need. Mapping the results of DB queries into complex structures & entities, and juggling it to fit the latest needs of front-end/app devs used to take a big chunk of my back-end dev time (and nerves). GraphQL can extremely simplify and speed up these iterations.

[davidjnelson]

You may also enjoy heroku for hosting an mvp. Pricy, but straightforward to scale and set up a staging env for testing release candidates on, plus lots of great features like automatic db backups. And since it’s built on aws it’s easier to shift some microservices onto ec2 later as needed.

[alwaysreading]

Totally agree. GraphQL makes perfect sense for a large app with many endpoints but there isn’t a lot of benefit for smaller apps. I’m involved in an app now that “has to use GraphQL” but could easily be done with a restful api without the additional overhead of what is essentially middleware.

[adamnemecek]

I think it’s dope if you are fundamentally querying a graph. Doing it manually is repetitive.