My Review of GraphQL Summit 2019

I have been to the GraphQL Summit 2019 hosted by Apollo in San Francisco. I was very excited since GraphQL is the technology I use and learn about every day. Overall, it was an excellent opportunity to see the increasing penetration and impact of GraphQL. Speakers frequently quoted this number from the npm survey: 23% of Javascript developers are using GraphQL. Naturally, many talks focused on scaling GraphQL from large companies such as Shopify, Paypal, and Expedia. The technology is not just for greenfield projects or startups anymore. But, their mobile talk lineup was relatively weak, possibly indicating the immaturity of GraphQL on mobile.

Talks were primarily divided into two categories: client-side and server-side. I mostly went to the client-side ones. Of those I went to, I enjoyed Fine-Tuning Apollo Client Caching for Your Data Graph, Client-side GraphQL at scale, and, The GraphQL developer experience the most. The followings are my notes on the talks I attended. I hope the notes guide you to find something interesting.

Day 1

The GraphQL developer experience by Danielle Man (👍)

From the start, Danielle made a good point about the real benefit of GraphQL. It’s not just about minimizing payload or reducing round trips. It’s about the productivity boost from the integrated experience with typed API, normalization, and intelligent caching. React, Prettier, and VS Code solved the challenges of component structure, formatting, and type intelligence. Now GraphQL solves the next big problem, data fetching. I like that she went into the whys of GraphQL and also gave an end-to-end view of the tooling. I recommend it to those whose GraphQL journey is just starting.

State Management in GraphQL using React Hooks & Apollo by Shruti Kapoor

I was a little disappointed with Shruti’s talk since I didn’t find it that relevant to GraphQL. As she focused mostly on React hooks, this is your talk if you aren’t familiar with hooks.

Fine-Tuning Apollo Client Caching for Your Data Graph by Ben Newman (👍)

Ben talked about the new features in the upcoming Apollo Client 3. I found the material very relevant because my team is already seeing a huge performance bottleneck from Apollo Cache. There were several exciting features: Garbage collection, declarative cache config (though it doesn’t statically check the config yet), and improved pagination handling. Since most of the features are about performance, the talk is meaningful for those using Apollo Client at scale already.

Scaling GraphQL Beyond a Backend for Frontend by Michelle Garrett

As a frontend developer, it can be frustrating trying to adopt GraphQL since you find yourself dependent on backend counterparts. Michelle talks about how you can go around the inertia by using a GraphQL middleware (or BFF). Though I believe client-side resolver is the lighter weight approach, it was inspiring to see her org, eventually turning around thanks to the superior developer experience. She then continues to talk about her plan to adopt a federation. This talk is appropriate for those interested in figuring out the GraphQL adoption strategy.

Apollo Lounge (not a talk)

I spent an hour in between talks to talk to Hugh Willson, one of the Apollo engineers behind Apollo Client 3, about the performance bottleneck I saw in the beta release. The problem was that the Apollo Client took a long time to respond to a large query response (a tree of about ~2000 objects) even with the denormalization turned off. Due to the time constraint, we didn’t get to the bottom of the issue. But it was nice to see how an Apollo engineer goes about debugging the client and also get reassured that my configuration was not a problem.

Game Of Types: A Song Of GraphQL And TypeScript by Steven Musumeche

After seeing Danielle’s talk, Steven’s talk didn’t feel new to me. Especially because I am following the development process he outlined almost precisely. But if you ever wonder how all these generated types (whether they are from Apollo Tooling or GraphQL Code Generator) fit into your type system, this talk is for you.

(Video is not yet available.)

Day 2

useSubscription: A GraphQL Game Show by Alex Banks

The most entertaining talk I have ever been to. Alex made GraphQL subscription via WebSocket unforgettable. However, as I went to the talk expecting to see GraphQL streaming (a misunderstanding on my part), I ended up getting a little disappointed. If you are building a real-time app, watch this talk when it becomes available.

How do you get changes made to GraphQL? by Orta

Even though GraphQL’s governance mostly feels irrelevant, it matters to all of us. Orta talked through how the current GraphQL Foundation came about and how he saw through the changes. This talk isn’t for everyone, but if you like to contribute to the spec one day, watch this.

The future of GraphQL tooling and DX by Daniel Woelfel

The whole talk felt like a sales pitch of his company, OneGraph. But Daniel indeed showcased many inspiring tools leveraging: a point-and-click GUI to build a query, an Excel plugin to import GraphQL data into a spreadsheet, and a type checker for queries embedded in markdown documents. The talk was more inspirational than useful.

Building a faster checkout experience at PayPal with GraphQL by Vishakha Singh

Vishakha focused on how minimized payload and some intelligent caching using GraphQL improves PayPal’s performance. But honestly, I didn’t have a lot of take-away.

Client-side GraphQL at scale by Chris Sauvé (👍)

Shopify’s admin app has ~1000 GraphQL queries and ~700 entities. The company came up with a couple of useful libraries to mitigate this complexity. One library filled the gap in Apollo Client’s type system using collocated d.ts for GraphQL documents, which I found smart. Another autogenerated mock data based on GraphQL schema. I plan to adopt both of them at my current projects. If you are pressed for time, you don’t need to watch the talk since the documentation on the libraries do an excellent job of explaining what they do.

Edit: All videos can now be found here. I linked the videos to my review as well.

Young Reacts #46

It was a stressful week for me. I ended up having 6 out of 9 scheduled chats, with both hits and misses. While I learned quite a bit and met some interesting people I would like to keep in touch going forward, I felt burned out by the end of the week. Devoting this much time hampered both my work and personal life. I will probably allocate less time and be more selective in accepting 1:1s in the coming month.

Anyhows, this week covers quite a few topics on infrastructure. I hope you enjoy them! I am going to get some more rest…

Photo by Cris Saur on Unsplash

People ❤️

On Messing Up Your Remote Team—And Then Getting It Right

Remote workers at the nascent stage did not work out despite the commitment from the founding team to build a remote team. After setting up a needed structure for clear direction and communication, they were able to perform at a high level.

Daily Stand-up Injection of Guilt

The author’s assumption of general mediocrity and complacency is not my cup of tea. I also believe some form of pushing information (or status meetings) can lead to serendipitous findings. But I do agree that employees should be educated on what’s expected of them and how their work impacts the business. (See open-book management)

Software Engineering 🌐

Deploy on Fridays, or Don’t.

I pushed to achieve Continuous Integration/Continuous Deployment wherever I worked. Continuously deploying is not always the best course action, and you need to make a risk/reward tradeoff. How likely will this change cause failures? How impactful will the failures be? If the deployment at the given moment is not worthwhile, there is no shame in waiting for the right time.

The State of Serverless, circa 2019

Serverless and JAM stack are gaining significant steam thanks to their “no-code” architecture. They may not be appropriate for large tech companies, but they provide easy wins to the resource-constrained.

DevOps: Now and to the Future

A slide deck on a comprehensive overview of the DevOps movement with more in-depth readings.

Confluent Schema Registry for Kafka

I never thought of this, but I can see that the number of schemata keeps increasing over time in the event-driven architecture, which could make maintenance a nightmare. Schema Registry is a solution where you can store the schemata and load them to parse a JSON per the stored schema dynamically.

Business 💸

GitLab reset –hard bad1dea: Biz U-turns, unbans office political chat, will vet customers

One memorable quote that I wholeheartedly agree with: “Deciding not to turn down customers on “moral/value” grounds is still a “moral/value” choice.”

Young Reacts #45

This week, I have 7 1:1s with strangers to talk about their careers and mine. I feel fortunate to have these opportunities to give and learn. Hopefully, some will evolve into long-term, mutually-beneficial relationships.

person holding piece of paper with phone a friend written text

Photo by Dustin Belt on Unsplash

People ❤️

Thriving on the Technical Leadership Path

I read quite a bit about and now have my own opinion of how to what makes a senior engineer. This article goes beyond and describes the next steps a senior engineer could follow.

Software Engineering 🌐

A product manager’s perspective on technical debt

You can think of tech debt as how you think of financial debt. Just as you would sometimes finance your investment via bank loans, you can pay for your product bets using the tech debt. It’s apt that the VP of Product at Capital One write this article.

dunglas/vulcain

A very cool project to leverage HTTP 2 features (multiplexing and server-push) to solve many problems GraphQL aims to solve: over/under fetching, and the n+1 problem. The project also reuses HTTP caching, which GraphQL can only use with predefined queries.

Pick your poison

Whatever architecture choices you make, GraphQL or REST, or Javascript or Typescript, remember that you will face unique challenges specific to you and your team.

Business 💸

The rise of the global first startup

I got two things that changed my thinking on remote work. First, Silicon Valley may have the best engineering talents, but the good ones are everywhere. Second, remote work is getting more accessible, thanks to the new tools. I hope to work in a completely remote environment to get better at remote work in the next few years.

State of Play: Six Trends Revolutionizing Games

I always thought games are the worst kind of software to develop due to a marketing-driven, fixed deadline, and the inability to verify ideas. But contemporary games work more like SaaS products, which could remove some of the pressure.

freeCodeCamp/chapter

Meetup users came out hard against the service’s plan to charge them, which was expected. But I am still surprised that the disgruntled users are now building open-source alternatives. This series of events shows how easy and cheap it is to start new services.

When Money Meets Values

This past week, I couldn’t let go of how China threw its weight against the NBA and Blizzard. When the money and the values collided, the organizations’ knee jerk reactions were to give up their values. It was unbelievable how fast they tried to appease their Chinese fans.

This series of events reminds me that leaders need more than technical or management skills. We need values as our guiding principles. Throughout our careers, we will be put into a position where we need to make similar tough calls. And it’s not just international politics; we need to think about racial and gender inequality, global warming, privacy, and more. The choices we face may not be as visible. But the tradeoffs and the consequences will be just as real. It will be crucial for all of us to have values we can be proud of and base our actions on those values.

Check out this week’s newsletter here!

Recap over my month-long 1:1 experiment

I concluded my month-long 1:1 experiment with Korean engineers last week. Of 16 people that signed up, I ended up talking to 5. I learned three lessons.

First, this format scales linearly. Sixteen hours a month was the most I could spend without affecting my work or my personal life. I loved talking 1:1, but it is also very time-intensive.

Second, the attendance was poor. Many people (11 out of 16) didn’t show up, so I ended up wasting valuable opportunities to talk to someone else. I was so disappointed. I hope this could be solved by adjusting my availabilities and sending notifications.

Finally, most conversations revolved around these three topics: how to become a “Senior Engineer,” how to solve technical problems they face at work, and how to find jobs abroad.

I am planning another month-long experiment at the moment and will share it next week.

Changing Tide

About 2~3 years ago, most of rising Github repos were in Javascript or related to Frontend development. It was an exciting time to follow the nightly updates. So many projects to try and learn!

But no more. Most starred repos are now Go or wiki-like projects. I am not discounting these repos. I am just disappointed about the lack of movement.

Empathetic Persuasion

One bad habit of mine is to share materials to make a point instead of making a point myself. But my attempts usually weren’t successful despite the merits of those materials. I wondered why people didn’t see the “light.” But, recently, why sharing articles, reports, or some data rarely persuades anyone clicked in my head.

Persuasion and following commitment do not originate from our rational mind especially if the problem space is complex and the benefits and the costs are not obvious. Rather, they happen at the emotional level. So you change behaviors when you have others feel your pain.

For example, if I want to avoid slow review turnaround time and resulting big pull requests, the best way to persuade is to vividly describe how I feel that longer review cycles slow down my projects.

It is not easy to do, I know. I also keep forgetting this. But next time I feel the urge to share an article, I will take a step back and think about the pain I have at the moment.

English as Second Language Colleagues

Recently I was appalled to hear that my friend, who is a software engineer, was denied an internal transfer because his potential manager did not want a non-native English speaker on his team. As a native Korean speaker myself, it was unsettling to hear such a story. I thought that in this day and age, especially at Silicon Valley, we have figured out how to work together with those from different backgrounds.

I realize I don’t see many conversations around how this lack of fluency impacts some of us. I suspect that’s because most writers and speakers are already fluent in their languages. So we don’t talk about this issue and put the onus on the individuals.

We can’t expect people who spent most of their lives in different languages to understand all connotations and cultural subtext. It is not going to happen no matter how hard they try. Even some native speakers have a hard time communicating well. If we believe that communication is a two-way street, we have to meet in the middle.

Yes, I get that it makes communication more difficult. But we, collectively speaking, hired each of us because everyone was deemed qualified to do the job. Then, it is on all of us to create an environment where we all can be successful.

How? I admit I don’t have a great idea. But I will start by setting up 1:1s to build the relationship and the context. That will provide a sometimes necessary bridge for the lapses. If I notice how well or badly we communicate, I will share that too. And I will always try to remember that none of us is perfect. Language proficiency, or the lack thereof, is just another imperfection some of us have.

Promise.any and Promise.allSettled

One benefit of Javascript proposal process is that there are always new things to learn and to make things more interesting. Promise.any and Promise.allSettled are not revolutionary but they will enable a new, more concise way to code. You can read more about them from here.

A caveat I found is that Promise.allSettled will never reject. It does make sense but at first I found myself thinking, “so when does it reject and what does it reject with?” I am interested to see how this behavior will be typed in Typescript.

Don’t Just Link, Summarize

This came up during a meeting to review how we organize our work (basically JIRA).

In this day and age, everything is linkable; whether it be a Slack thread, a Zendesk ticket or a Google Doc. So in order to give “context,” it is tempting to just throw a link in a conversation. But you can do more than that.

I wouldn’t say linking does not have its own value because discovery is a real problem. However, every one of us is overloaded with information. We can’t be expected to go down every rabbit hole of links. So, help us out a little. Give us a link, and summarize it a little for us: What’s in it? Why do you think this context is useful? This will save us good 10-20 minute for every link and we will appreciate you going extra mile for us.