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
|
Document: WM-028 P. Webb
Category: Project 2018.02.10
Socii Dispatch 02
Abstract
Launching is hard
Body
TL;DR: Socii's alpha[1] is out in the wild and obviously *very* rough
around the edges. Let me tell you what I've learned since my
last dispatch.
1. GraphQL
Yours truly, two weeks ago[2]:
> GraphQL[3] is awesome. However, I've been building REST APIs for
> the past month and have two microservices to handle things thus
> far and that means I'm not transitioning to GraphQL until maybe
> version 1 of Socii is solidified.
HAH. Mere *days* after I published those words, I ran into an
issue where I needed to display comments and for those comments to
show pertinent info like:
- author's
- name
- username
- avatar shape
- avatar source
If I stuck with REST, here's what my query path would've
looked like:
- query story service for original post (already have user info
from earlier query)
- query story service for comments to the original post
- for each comment, query user service for comment author's
aforementioned info
This is way too much work to get four pieces of info for a
comment. Keep in mind that I'd get the *entire* user object with
each query to the user service as well. Here's how I achieved this
with GraphQL:
```javascript
const query = `{
post(replyTo: "${postId}") {
author
content
createdAt
id
favoritedBy
notes {
favorites
replies
reposts
}
repliedBy
replyTo
repostedBy
slug
}
}`;
```
Couple things to note here:
1. GraphQL pros will tell me to use variables instead of what I'm
doing here with `postId` in a template literal but MEH.
2. The `author` parameter does a little extra stuff on my GraphQL
service to reply back with name, username, and avatar info.
3. The post schema is quite large but I don't need all of it to
display them. What you see in this query is what I get back. No
wasted data, how neat is that?
This took me around three days to fully grok and to be quite
honest, I am not really sure if I do. 😅 It works though!
There are *several* articles and dissertations out there with a
clickbait-y title bemoaning the demise of REST thanks to GraphQL
and well…no. REST is battle-tested and still pretty damn good. In
fact, I'm still using it for anything that isn't a `GET` request.
When you're `POST`ing or `PUT`ing, I think REST reigns supreme and
quite frankly, I don't feel like rewriting that code.
Let me have a year with ol' graphy before I do something crazy.
2. WebP
WebP[4] is an image format invented by Google as an alternative to
JPG and PNG for small (but visually comparable) images. I like the
idea of paying almost nothing for image storage so my interest was
piqued early in Socii's development.
The cost savings I've seen during testing have been massive. I had
two folders named "raw" and "processed". After converting 10 or so
large images (screenshots and the like), the "raw" folder was ~5MB
while the "processed" folder was ~1MB. At scale, that's some
impressive cost savings. The visual parity was indistinguishable
to me as well.
Of course, Chrome is the only browser that natively supports
it[5]. I found a polyfill that works for non-Chrome users (like
myself, Firefox is best for me) and I thought it'd be usable in
production. It is *not*.
I am now reversing my decision to use WebP exclusively and will
optimize images uploaded to Socii. Decoding WebP in the browser is
slow, even with the WebAssembly-converted polyfill and scrolling
is horrendous. That's *terrible* user experience. I found another
image format called FLIF[6] but the current polyfills are also not
production-ready.
Things I've learned
1. Estimates are dumb because people are dumb. Even if you account
for that, you'll still be off.
2. GraphQL is still awesome. I'm glad it took up my estimate time
to learn it.
3. We need better image formats on the web and browser vendors
need to get onboard.
That's all for now, see ya! 🕸
References
[1] <https://hub.socii.network>
[2] </WM-026>
[3] <http://graphql.org>
[4] <https://developers.google.com/speed/webp>
[5] <https://caniuse.com/#search=webp>
[6] <https://github.com/FLIF-hub/FLIF>
|
