---
title: "GraphQL for BFFs: navigating the trade-offs"
date: 2020-10-22
layout: slides
lang: en
ref: graphql-for-bffs-navigating-the-trade-offs
published: false
---
# GraphQL for BFFs
Navigating the trade-offs
???
1. slides já estão online, com sugestões incorporadas
2. artigo online
3. tupy: começar pelos slides é mais fácil
---
# Mobile is **hard**
---
## Immature ecosystem
???
Compared to desktop, browser and server ecosystem, which are many years older.
iOS SDK released on 2008, which is:
- the same year Python 3.0 was released;
- 1 year after Clojure's release and 13 years after Java's and JavaScript's
release;
- 10 years after GTK release
---
## Almost no competition
???
Effectively a duopoly, better than a monopoly, but meh.
Closed, walled gardens.
Less competition, lower quality.
Compare to: browser ecosystem, desktop ecosystem
---
## Little to no control over the environment
???
Bad on Android, worse on iOS.
---
## Our usage of GraphQL
History goes here
???
savings: React Native, GraphQL, TypeScript, stormshield
---
# Proposal
Adopt GraphQL as the default for BFFs
---
## Target
**data fetching** and **chaining**
???
It is not about:
- over fetching
- different clients with different data requirements
---
## Goal
Move **complexity** out of mobile to the backend, get more **dynamicity** out of it
???
The complexity doesn't vanish or shrink, it just shifts.
https://media.tenor.com/images/ce1962c14da22c969e664560e098b2bc/tenor.gif
---
# Alternatives
AKA, why not "just use a RESTful BFF"?
---
## REST
???
It doesn't address JOINs
---
## Fulcro
???
For 10 reasons for using GraphQL, 8~9 are shared for Fulcro.
The other 1~2 aren't so relevant:
- data > syntax: already false for Swift, Kotlin, Dart
- attributes > aggregates: already false for Swift, Kotlin, Dart
---
## Falcor
---
## SOAP
---
# Implications
---
## Invalid arguments
---
### "GraphQL isn't RESTful"
🤷
???
Similar to saying "REST isn't GraphQL"
---
### "GraphQL has a bad caching story"
True, but we don't do HTTP caching
---
### "query-params can be used for selection in a BFF with REST"
👎
???
This isn't RESTful, and is an *ad-hoc* querying format
---
### "over-fetching isn't a problem"
???
That is not the main reason for GraphQL
---
### "library X for GraphQL is bad"
---
## Valid arguments
---
### "Throttling by query complexity is hard"
---
## Lessons learned
---
### Error handling
---
# Takeaways
---
## None of the points are specific to Flutter
---
## GraphQL enables declarative **dynamicity**
---
## Thank you!
References:
1. these slides: [{{ site.tld }}/slides.html]({% link slides.md %})
2. [prose version of this presentation]({% link _articles/2020-10-22-graphql-for-bffs-navigating-the-trade-offs.md %})
3. "[Clients in control: building demand-driven systems with Om Next](https://www.youtube.com/watch?v=Zb18iPjDgwM)", by António Nuno Monteiro
4. "[Om Next](https://www.youtube.com/watch?v=MDZpSIngwm4)", by David Nolen
