---
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: FIXME [{{ 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