summaryrefslogtreecommitdiff
path: root/memos/WM-028.txt
diff options
context:
space:
mode:
Diffstat (limited to 'memos/WM-028.txt')
-rw-r--r--memos/WM-028.txt143
1 files changed, 143 insertions, 0 deletions
diff --git a/memos/WM-028.txt b/memos/WM-028.txt
new file mode 100644
index 0000000..57b837f
--- /dev/null
+++ b/memos/WM-028.txt
@@ -0,0 +1,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>