1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
---
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
|
