

In this post, I'll explore what it is to measure, how to measure, and some things I keep in mind when measuring API (application programming interface) latency, specifically in the domain of APIs served over the HTTP protocol. 

**Disclosing OpenAPI ChatGPI**

It's December 2022 and the internet is awash with the potential of [OpenAPI's ChatGPT](https://chat.openai.com/chat). Coincidentally, I'm also writing one of my more technical posts for the first time in a while. As a part of this post, I'd like to join the conversation of what it means to create content, ethically, in what is seemingly the dawn of a new digital age. I believe prompts could serve as citations; however, since ChatGPT will change, there's no guarantee that it will respond the same provided the same prompt. On the other hand, the internet as a whole isn't static, so maybe future citations will look something like *Prompt: Help me understand XYZ. \[Prompted: Dec. 6th, 2022\]*, similar to how [IEEE citations](https://libguides.murdoch.edu.au/IEEE/all) use *\[Accessed: Dec. 6th, 2022\]*.

In places where I've used OpenAPI's ChatGPI, I'll disclose it which will look like this throughout the post:

<blockquote className="gpt-blockquote">
  <p>
  <b>Nick</b>: Hey ChatGPT, I'm going to write a blog post where I credit you when your responses are used. Say "Thanks" in a minimal fashion
  </p>

  <p>
  <b>ChatGPT</b>: Thanks.</p>

</blockquote>

If ChatGPT gets too wordy, I'll use `[REDACTED]` where necessary.

**Context, why, and errata**

This post and its follow-ups are an example of the experience that comes along with human trial and error, which over time has become a sort of guide for how I tackle performance problems. <span class="underline">I don't claim this to be exhaustive or absolute</span>. 

The motivations for writing this and the subsequent posts are:

1. I'm writing for my future self who will refer back here.

2. There's a lack of literature on the topic.

3. I still have more to learn.

4. I'd like the internet to be faster. If I can contribute to that in any way, that's meaningful to me.

At the moment, I don't have plans to open source my blog, so if you find errors or issues, please create issues using this GitHub repository:
[https://github.com/olingern/blog-issues](https://github.com/olingern/blog-issues)


# Measuring

There's an old question[^1] dating back to 1883 that gets at the heart of what it means to observe an event: 

> _"If a tree falls in the forest, does it make a sound?"_


Scientific American goes on to explain that there would be vibrations but no sound. It's a very interesting question and it gets to the heart of what it means to **observe** something. Vibrations exist with or without human observation, but it's our interpretation of that sound in either pressure level or frequency (_the number of times per second that a sound pressure wave repeats itself_)[^2] which we measure in decibels and hertz. 

There is a clear and important distinction between observing and measuring, though. To measure something, we need a mechanism — such as our ears or a ruler — to establish the measurement whereas observation, in my mind, is employing the methods of measurement. Much has already been said about observability and I'm not sure what I can offer in this uncanny valley that exists between [Site Reliability Engineering](https://sre.google/) and Software Development — but what I can offer is a simple metaphor for how I think about it. Observability, to me, is akin to periodically checking your speedometer as you travel down the highway. Speed on the highway is important to us because it's a function of safety for ourselves and others. Using a speedometer, you're able to check whether you're within the legal bounds of the speed limit. From time to time, you find yourself below or above the legal limit, but you bring yourself back within that acceptable range with the help of your speedometer. Now, imagine a world without speedometers. You no longer have a way to measure the miles or kilometers per hour you're traveling, thus the observability of the machine you're running is significantly blunted. Sadly, this is the state of many systems on the internet.

From here on out, I'll be focusing strictly on measuring API latency but measurement and observability go hand in hand.

When approaching performance problems, measurement is really the crux of tackling them. We could refer back to our previous question about a tree falling in the woods and ask, _If a website makes an API call, is it slow?_ Obtuse, I know. Similar to how we can measure sound in decibels, we can (_and typically do_) measure latency in milliseconds, abbreviated _ms_, when talking about API performance. Every so often, you might see µs which stands for microseconds and the unfortunate might see seconds. It's unlikely you'll see an API respond in microseconds but you might see DNS lookups[^3] happen in that unit of time.

Just to clarify the relationship between microseconds, milliseconds, and seconds. Here's a couple of conversions between the three.

```text
1 second = 1,000 milliseconds = 1e+6 microseconds
1 millisecond = 1000 microseconds
```


But, what is latency?

<blockquote className="gpt-blockquote">
  
  <p>
  <b>Nick</b>: Hey ChatGPT, what is latency?
  </p>

  <p>
  <b>ChatGPT</b>: Latency is the amount of time it takes for a data packet to travel from one point to another. In other words, it is the time delay between when a request is made and when a response is received. [REDACTED]. Latency is typically measured in milliseconds (ms) or microseconds (µs).</p>

</blockquote>

Maybe you're like me and played Starcraft in your teenage years. You could often blame your losses on latency:

> SuperPwn: gg 
>
> Nick: gg, lag

Though in our case, we aren't concerned with the latency of things outside of our control. Sometimes, someone will experience high latency due to their hardware, such as someone dialing up your landline phone when connected to the internet via a 56K modem or — for the younger generation — traveling into an area where 4G and its successors are not supported. We're only concerned with how fast our application can respond not with how fast the clients can receive.

### Baselines

This is your starting point. You could also think of this as beginning to train for running a mile. You establish that you can run a mile in 9:00 minutes on an indoor treadmill (_a controlled environment_) and you would like to improve to 8:00 minutes, which would be an 11.11% improvement `(9 x 60 - 8 x 60) / 540 * 100`

If you're just embarking on the journey of learning about how to measure APIs, it's tempting to open Chrome's network tab, hit refresh ten times on a page that calls the API you want to measure, take that **average**, and then say, "Great, done." That doesn't take into account all the different conditions that can impact users. For you, the endpoint responds in less than 50ms but for your friend, the endpoint responds in 1-2 seconds. This is because their cat, Fluffy, laid on their keyboard while pressing "A" for 30 seconds before being shooed away and somehow managing to click "save" in the process. The large size of the JSON payload causes your friend to experience higher latency than you do. 

So, we need to find our starting point but we also need to flesh out _how_ we talk about our starting point before defining our baselines.

### Percentiles

Let's say we had access to all of our response times in milliseconds and they looked something like the below array. In real-world applications, we'll need much more volume for proper measurement, but for demonstration / educational purposes a small set is much easier to reason about and work with.

```javascript
const responseTimesInMs = [45, 20, 15, 19, 2300, 20, 42, 33, 26, 25];
```

Before we continue on, make a mental note about what is or is not interesting about these response times. What is the user experience like? Is it consistent?

With very little knowledge, we could generalize that these response times are **mostly** consistent with one exception: _2300ms_.

We also could calculate the average for this set of response times:

```javascript
const avg =
  responseTimesInMs.reduce((prev, curr) => (prev += current)) /
  responseTimesInMs;

console.log(avg); // 254.5
```

To the folks who remember their statistics, you would quickly spot that _2300ms_ is an outlier and should be removed to get an average of _27.2ms_. This is not wrong, but bear with me for a bit and I promise that I'll make my case.

Another way to look at this data is in **percentiles**. Let's ask ChatGPT about percentiles

<blockquote className="gpt-blockquote">
  
  <p>
  <b>Nick</b>: Hey ChatGPT, what is a percentile in a dataset?
  </p>

  <p>
  <b>ChatGPT</b>: A percentile in a dataset is a value that separates a certain percentage of the values in the dataset from the remaining values. For example, the 50th percentile (also known as the median) is the value that separates the lower half of the dataset from the upper half of the dataset. The 75th percentile is the value that separates the lower 75% of the dataset from the upper 25% of the dataset.</p>

  <p>
  <b>Nick</b>: How do I calculate a percentile?
  </p>

  <p>
  <b>ChatGPT</b>: To calculate the percentile of a dataset, you can first rank the data in ascending order. Then, you can use the following formula to calculate the percentile:</p>


</blockquote>

To summarize a percentile calculation

1.  Sort the values from least to greatest.
2.  Calculate the index for the percentile you're interested in.
3.  Find the value in the sorted list at the calculated index.

There are varying ways to calculate the percentile index floating on the internet. Depending on how you ask ChatGPT, it will give you varying formulas. For our purposes we'll use this formula and pseudocode to calculate the index:

```text
- idx is the desired percentage, divided by 100, multiplied by the array length
- if the result is a float, round to the nearest integer
```

Let's put it into action. 

```javascript
// Step 1, sort the list
const responseTimesInMs = [45, 20, 15, 19, 2300, 20, 42, 33, 26, 25];
const sorted = responseTimesInMs.sort((a, b) => a - b);
console.log(sorted); // [15, 19, 20, 20, 25, 26, 33, 42, 45, 2300]

// Step 2: Index calculation. 
// Where p is percentile. Shortened to keep within codeblock
const getIdx = (p) => Math.round((p / 100) * responseTimesInMs.length) - 1;

// Step 3: Define the percentiles we're interested in
const percentiles = [20, 40, 50, 60, 80, 90, 99];

// Loop over each percentile, calculate the idex, and then print the value out
for (const p of percentiles) {
  const idx = getIdx(p);

  console.log(`Percentile: ${p} | responseTimesInMs[idx]: ${responseTimesInMs[idx]}`)
}
```

Our final output for our `for` loop:

```bash
Percentile: 20 | responseTimesInMs[idx]: 19
Percentile: 40 | responseTimesInMs[idx]: 20
Percentile: 50 | responseTimesInMs[idx]: 25
Percentile: 60 | responseTimesInMs[idx]: 26
Percentile: 80 | responseTimesInMs[idx]: 42
Percentile: 90 | responseTimesInMs[idx]: 45
Percentile: 99 | responseTimesInMs[idx]: 2300
```

Now, we have some data that we can talk about! What we can extrapolate from this data is that 50% of our users will experience a response time of 25ms or less, 90% 45ms and less, and finally 99% 2300ms and less. 

So, as the percentile increases, we're including more of our data and since our response times are sorted — there's a linear relationship between an increase in our percentile and our response times.

**Nomenclature Update**

From here on out I'll refer to different percentiles by `pPercentile` where `p` is pronounced as it is by itself and where `Percentile` is an integer. So, the 50th percentile would be `p50` and pronounced "p fifty."

**Meaningful percentiles**

In the real world, p95s get thrown around the most and specifically for a single API endpoint and aggregates. By working with the p95, we're implicitly filtering out outliers in large data sets like our earlier instance of 2300ms. You could imagine a large set of response times where ~1-2% of users experience extreme latencies. When optimizing 5% and less latency, there are both diminishing returns and impact, system and business, depending on your scale. If you're a tech giant, that can be hundreds of millions of dollars, but if you're a startup with 1000 daily active users (DAUs), who on average generate ~8 API calls per session, 5% is only 400 of your daily 8000 total daily volume and likely not a significant source of user experience improvement or revenue optimization.

p50's are also meaningful as they are synonomous with the **median** in our data, so p50s and p95s allow us to generalize in terms such as: *About half of our users have an experience of _X_ ms and nearly all of our users have an experience of _Y_ ms*. 

# Hands on

At this point, we have enough to put percentiles into practice.

**Establishing a mock API**

The mock API will use plain old JavaScript and Node 14.x, but the current LTS should always work. If you don't have Node installed, [nvm](https://github.com/nvm-sh/nvm) is a great piece of software for installing and managing Node.js versions.

I'll be using OpenAPI's ChatGPT to generate a Node.js mock server with the prompt:

> Write a Node.js application with one endpoint /measure that produces a JSON 200 but with a random delay between 0 and 3 seconds

Setup the project

```bash
mkdir measure && cd measure
npm init -y && npm install express
```

Let's create a file, `index.js`, and add the following code:

```javascript title="index.js"
const express = require("express");
const app = express();

const getRandomFloat = (min, max) =>  Math.random() * (max - min) + min;

app.get("/measure", (req, res) => {

  // artifically delay the response with a random delay between 0 and 3 seconds
  setTimeout(() => {
    res.status(200).send("OK");
  }, getRandomFloat(0, 10) * 1000);
});

app.listen(8080, () => {
  console.log("Server listening on port 8080");
});

```

**Tools for measuring**

In a follow up post, I'll cover a handful of tools that I've used over the years but for now, we'll use a simple CLI tool written in Rust, [oha おはよう](https://github.com/hatoo/oha), because it requires little setup and gives us access to latency percentiles. More complex examples that require capturing a value and then using it in subsequent requests will require different tooling.

[Oha installation instructions](https://github.com/hatoo/oha#installation).

**Booting up our mock API**

```bash
$ node index.js
Server listening on port 8080
```

**Sending 100 requests to our mock API**

```bash
$ oha -n 100 http://localhost:8080/measure
```

**Output**

Oha's report is quite nice and provides a summary, a histogram, a latency distribution, and even some DNS lookup metrics. Pretty awesome. For our purposes, we'll only look at the latency distribution.

In our example, we artificially delayed our responses using a random integer between 0 and 10 to get a spread of latencies between 0 and 10 seconds. After running Oha against our `/measure` endpoint, we see that randomness is sorted into six latency distributions ranging from p10 to p99. 

```bash
Latency distribution:
  10% in 1.0933 secs
  25% in 2.4909 secs
  50% in 5.2222 secs
  75% in 8.0483 secs
  90% in 8.9538 secs
  95% in 9.3190 secs
  99% in 9.9771 secs
```

# Methodology

Maybe the most important aspect of measuring is **consistency**. This includes isolating time, origin, and environment (_not actual vars but `dev`, `staging`, etc._) variables. We also need volume to get a zoomed-out view of our performance.

**Time**

Because web traffic isn't constant and many different scenarios can play out through a 24-hour and week span, it's important to be consistent. For example, because of the minimal traffic between 2 - 5 a.m., you hit frequent cold starts (*when a [serverless](https://aws.amazon.com/serverless/) function doesn't have an instance ready and must start up to serve the request*). When measuring hour over hour, you see no problems, yet they do still exist over a 24-hour time span. If you make a change and see a significant drop in average response times and p95s, those can be indicators that the change is meaningful but collecting the same data over 24-hours and one week would significantly raise confidence in the change.

**Origin**

In most cases, collecting data from a cloud provider's metrics or a monitoring service like [Datadog](https://www.datadoghq.com/) will be the method most folks use to establish and compare their metrics. But, it must be said, that you shouldn't compare local latencies — like we've obtained before with Oha — to latencies collected in the cloud.

**Environment**

Lastly, similar to _where_ we measure from, we also want to be consistent in what we're measuring. Our local environment will perform differently than a production environment. Production traffic can also make our application behave differently as well. Though it's always a good idea to push your change to a pre-production environment, measure it in pre-production, and then release and remeasure it in production.

**Volume**

Let's ask ChatGPT about this to see if it can be of help

<blockquote className="gpt-blockquote">
  <p>
  <b>Nick</b>: Talk about why volume in collecting API latency data is important for get a zoomed out view succinctly
  </p>

  <p>
  <b>ChatGPT</b>: Collecting a large volume of API latency data is important because it allows for a more complete and accurate view of API performance, enables identification of trends and patterns, and helps identify outliers and anomalies. This helps make informed decisions about optimizing performance and addressing potential problems.</p>

</blockquote>

Have you ever been on an airplane and had an epiphany about Earth's topography or a city's skyline? I know that I've marveled more than once at mountain ranges that I've taken for granted on foot or even New York City's skyscrapers that I set my sights on daily for years. Collecting data is much like the topography of Earth in that as certain clusters or anomalies begin to amass, they'll become more and more evident but when viewed in isolation — they’re easy to write off.

How much volume is enough? Well, it depends. If you're a startup, and you only have a handful of users but those users are complaining of performance, you might have to synthetically generate more load with a tool like [k6](https://github.com/grafana/k6) to get a better view into performance issues. This is not unlike [finding a puncture in a bicycle's innertube](https://youtu.be/pWZGMMZwaNs?t=68). 

# Wrapping up

This post focused on what it is to measure API latency, some of the nomenclature, and ideologies around measuring. Now that we have the backbone for measurement in place, we can explore making changes in measurable ways in upcoming posts.

Thanks for reading!

[^1]: If a tree falls in a forest. Retrieved from https://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest

[^2]: NPS. National Parks Service: Understanding Sound. Retrieved from https://www.nps.gov/subjects/sound/understandingsound.htm.

[^3]: DNS Lookup. Retrieved from https://www.techopedia.com/definition/29029/dns-lookup

[^10]: My reference.


A somewhat generic guide to optimizing backend services

Performance Toolbox: Measuring API latency


I believe there are two types of people in the world: _those who can tolerate Christmas music, and those who can't._ As a person who considers themself a part of the latter, I keep an eye on the Thanksgiving holiday because I saw it as the levee that prevented the barrage of Christmas music. The only saving grace that I have is that 1920s-1940s jazz music is near and dear to my heart and, throughout December, I get a sprinkling of music that swings.

> throughout December

But, therein, lies the problem — **December**. I'm sitting in a coffee shop on November 23rd and my ears are dealing with an onslaught of _Have a holly jolly Christmas_, each of Mariah Carey's Christmas albums, and every version of _O Holy Night_ possible.

Perhaps, it was living in Japan for a couple of years and seeing how uneventful the holidays are there (_just another day with the exception of a bucket of Kentucky Fried Chicken_) that resensitized me to the overwhelming energy America puts into Christmas.

I've come to the conclusion that all of the people who love Christmas have colluded to collectively buy up the major radio stations and grease the palms of all grocery store owners to push their agenda: _Christmas music starting before Thanksgiving_.

Yes, you heard that correctly. These conspirators are out to repurpose the start of the Thanksgiving holiday with all things Christmas. For now, we all make omissions, "_It's so close, so we'll allow it._" But, you see, that's not the end game. Next, it's Halloween and eventually, Christmas lights will be ubiquitous. We'll stop chopping down pine trees and begin growing them indoors, giving way for an entirely new industry of year-round indoor pine trees to sprout up.

~~Merry Christmas.~~

Happy Thanksgiving.


Christmas Conspiracies


<img src="/images/angry-browser.jpg">

You're working on a site, _foobarbaz.app_, and you've deployed your API to a subdomain at _api.foobarbaz.app_. The `api.` prefix _feels_ like a nice touch because it's separated from the rest of your application.

## Preflight Requests

Have you ever wondered what that `OPTIONS` request is executing before your actual `GET`/`POST`/`PUT`/`DELETE` when making requests to `api.foobarbaz.app`?

[MDN Web Docs](https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request) defines this as:

> A CORS preflight request is a CORS request that checks to see if the CORS protocol is understood and a server is aware using specific methods and headers.

That definition makes sense once you understand what CORS is, seeing as it's self-referencing, but not so much before. Distilled down, it's a conversation between the browser and the API. It goes something like this:

> **Browser**: "Hey API, can I make this request?"

> **API**: "Hey Browser, sure."

> **Browser**: "Thanks, API. Sending my request now"

The Web Hypertext Application Technology Working Group (WHATWG) CORS spec has [an excellent walk-through](https://fetch.spec.whatwg.org/#example-simple-cors) of a basic scenario.

## Cut your network requests in half

This conversation between the browser and the API is only necessary because our API at `api.foobarbaz.app` is not of the same origin as `foobarbaz.app`, specifically our _hostname_ is now different. _Port_ (`:443`, `:80`, etc) and _protocol_ (`HTTP`, `HTTPS`) also follow the same logic as _hostname_, so any differences in the page's hostname, port, and protocol and a request executed on the page will require a CORS request. web.dev's [Understanding "same-site" and "same-origin"](https://web.dev/same-site-same-origin/) does a great job of breaking down the parts of a URL.

You'll notice that a header, `sec-fetch-site`, is attached to any XHR request in Firefox and Chrome which will indicate whether this was a `same-origin` request or not.

Below is an example of cross origin request headers in Firefox. Note the `Sec-Fetch-Site: cross-site`. You can read more about `Sec-Fetch-Site` [here on MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site).

<img class="shadow m-auto" src="/images/screenshots/request-headers.jpg" />

If you're using a service, like Fastly or Cloudflare, to proxy to your application or if you have a proxy setup — this shouldn't be an invasive change since the aim is simply to create an alias on the hostname where the original application loaded. Routing `https://api.foobarbaz.app` to `https://foobarbaz.app/api` and moving over the JavaScript clients using the `api.` subdomain will cut your network traffic in half.

### Context

While working at [meetup.com](https://meetup.com), I worked on a team focused on improving p95 latencies, which is actually interesting, engaging work. One afternoon another engineer and myself were having a hard time identifying low-effort, high impact changes when we stumbled across the 40-90ms each network request was making from the browser for preflight requests. In one afternoon, we removed our CORs requests — a change that drastically improved the desktop and mobile web's experience.


You don't need that CORS request


# Only what you need

It's been just around six months since I've started working with GraphQL. If you're not familiar with the protocol, then [graphql.org](https://graphql.org/) is a good start. In a nutshell, it tries to improve on the REST protocol by not asking for all the data for a given entity, but "_only what you need_." Let's say you need to display a blog's title, author, summary, and date, but not the last edit, author, or the full content of a post. In GraphQL, you would issue a query like this

```
query getPostData()  {
  title
  author
  summary
  date
}
```

and that query would be issued to your GraphQL server at _mydomain.com/graphql_ or wherever you've chosen to mount your GraphQL server. This is one of the stark differences between REST and GraphQL – how your API services requests.

In a REST, you would issue a request to a GET request to an endpoint like _mydomain.com/api/posts_. If you want to create a new post via an API endpoint, you might have another endpoint _mydomain.com/api/posts_. This pattern grows into what we know as "CRUD" for "**C**reate **R**ead **U**pdate **D**elete" because you need to use the correct HTTP verb to map to the action you would like to execute. Requests that change or create data are known as [muatations](https://graphql.org/learn/queries/#mutations) in GraphQL.

# The ups and downs

CRUD and GraphQL applications have to provide the same functionality via code paths in the end, _i.e. I still have to write CRUD queries in GraphQL_. One difference in the workflow with GraphQL is the lack of route maintenance. For one resource like a blog's posts, you might see something like:

```go
// Post REST routes
router.GET("/posts", ctrl.GetAllPosts)
router.GET("/posts/:id", ctrl.GetPostById)
router.POST("/posts", ctrl.CreatePost)
router.PATCH("/posts/:id", ctrl.PartialPostUpdateById)
router.DELETE("/posts/:id", ctrl.DeletePostById)

```

This quickly becomes burdensome when you add new resources to the application; however, this same burden is also a feature. The application is self-documenting and it's easy to understand the entrypoints into an application that's being exposed via HTTP/HTTPS.

In a large, complex GraphQL applicaton tracking down how clients query the API requires more energy than you would like. There's a lot of engineering discipline required to keep your GraphQL API from turning itself into a REST-like API as a product changes. In the first GraphQL query above, `getPostData`, if we remove `summary` from our front-end code – it's also easy to forget we should do that for our query so that we don't over-request data.

# Performance Implications

You might think GraphQL query reusage to be a great idea but I'll try to demonstrate why you should not reuse queries. Let's say we're over-engineering a blog. Your product manager asks you to add image thumbails to your blog. Easy enough. Your co-worker wants to get "_back to his roots_" and decides that this is the job of a Haskell microservice. A few months later, he has this shiny new service behind AWS's API Gateway and Lambda. You don't know why because your company uses Google Cloud Platform, but you shrug it off and update the query to call the `imagePreviewUrl` resolver (_a lot like a controller in REST-land._) he setup:

```
query getPostData()  {
  title
  author
  summary
  date
  imagePreviewUrl
}
```

Your co-worker didn't understand that DNS lookups, network hops, and cold-starts are all problems for applications who expect their responses in less than 200 milliseconds. Because your company is the _"#1 Overengineered Blog"_ in the blog space, you have a widget that thousands of other blogs include on theirs. `getPostData` was used in this widget and now a lot of people are mad that their pageloads are being affected by your widget.

You might think this is hyperbole, and you would be right, but I've experienced this exact scenario in different shapes and forms. Lessons learned: _don't over-request data and understand the performance implications of each field you add to your query_.

A REST API would run may run into this same problem, depending on how you implement it. In both REST and GraphQL, separating `imagePreviewUrl` from the performant query into another endpoint or query is one option:

REST:

```
router.GET("/posts/:id/image-preview-url", ctrl.GetPostImagePreviewUrl)
```

GraphQL

```
query getPostData($postId: Int)  {
  post(postId: $postId) {
    imagePreviewUrl
  }
}
```

# Mental Gynamstics Required

Reasoning about the graph is easily the hardest part of working with GraphQL. It's not a linear mode of thinking and requires you to hold more of the application surface in your head to effectively work on the graph.

Let's keep running with our blog example – _very meta of me_ – and talk about field resolution. First, let's start with a minimal JavaScript GraphQL server. Our entry point into the graph will be through retrieving posts by id's. Simple enough, right?

```javascript
const { ApolloServer, gql } = require("apollo-server");
const db = require("./db");

const typeDefs = gql`
  type Author {
    name: String!
  }

  type Post {
    title: String!
    author: Author!
  }

  type Query {
    post(id: String!): Post!
  }
`;

const resolvers = {
  Query: {
    post: (root, args, context) => {
      const postId = args && args.id;
      try {
        const result = context.db.getPostById(postId);
        return {
          ...result,
          author: {
            id: "1",
            name: "baz",
          },
        };
      } catch (err) {
        console.error(err);
        return null;
      }
    },
  },
  Author: {
    name: (root, args, context) => {
      return "foobar";
    },
  },
};

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: { db },
});

server.listen().then(({ url }) => {
  console.log(`Server ready at ${url}`);
});
```

**The gotcha's**

Reading through the example, you probably can see the confusing bits. There are two ways for GrahpQL to resolve an author's name, and that's completely valid in GraphQL land.

If you're like me and thought, "_The post query returns everything that the query needs, why would GraphQL need to do anything else?_", then you might also be like me and be surprised to know that if you were to execute this query:

```graphql
query {
  post(id: "1") {
    title
    author {
      name
    }
  }
}
```

The response for name would be: `foobar` and not `baz` as returned above. GraphQL calls the `Author.name` resolver because one of the neat features of GraphQL is that we could have omitted `Author.name` inside of the `post` resolver and GraphQL would have done all of that work for us. If we pre-populate this piece of data, we need to handle that in our resolver:

```javascript
  name: (root, args, context) => {
    if (root.name) {
      return root.name;
    }
      return "foobar";
  },
```

There are many cases where you might already have a piece of data available from a database query and you would like to "return early," as we've done here but GraphQL makes your pay a tax of sorts for the flexibility it offers. This tax, in large code bases, can grow and become cumbersome. The non-linear nature of dealing with graphs has left me wanting some sort of GUI representation of the graph that lights up as a request moves through each resolver.

Was REST so bad that we need to make understanding how our requests are routed more difficult?

# Caching

Caching has been covered in-depth throughout the net, but I think it bears mentioning here. The story for GraphQL caching, even in 2021, still feels [incomplete](https://www.apollographql.com/blog/graphql-caching-the-elephant-in-the-room-11a3df0c23ad/). If you're using Apollo Server, you can define cache-control settings in your schema for individual fields, but I've found this not to be very ergonomic.

# Final thoughts

Reading through this post you might think, "_This guy absolutely hates GraphQL._" That would be incorrect. When you're at the scale of Facebook or even where I work, [Meetup](https://www.meetup.com), the amount of data that might be saved over a year's time is meaningful.

Would I ever use it on a side project or recommend it to a startup? Probably not. Would I make the same choice if I was the CTO of a large, high-traffic tech company? Probably.

GraphQL still feels like a young technology and it is maturing. For front-end developers, I think it provides a great experience, but I feel that the problem of "stitching together data" was never solved – it was just moved from the front-end to the backend. When you think about that, it sounds like a really great idea: _less network traffic, less data transferred, easier development workflow for front-end developers._ In practice, the "edges"[1] are quite rough.

---

1 - A bad [GraphQL](https://graphql.org/learn/pagination/#pagination-and-edges) joke.


My experience of working with GraphQL for the past six months

The joys and pains of working with GraphQL


Hello! It looks like that last post was too ambitious. I broke my weekly writing habit because life changed a lot (_I moved back to Brooklyn, NY_), the site was a pain to update, and the pandemic has its own set of challenges.

## Work

I moved back to Brooklyn and work at [Meetup.com](https://meetup.com). It's been fun to work with the amount of traffic that Meetup regularly sees and also some of the technology, like GraphQL, that I only had minimal exposure to before joining. I also have some great, really talented co-workers. I have a rough draft, _The Joys and Pains of GraphQL_, that has come from my experience with GraphQL that I'm currently editing.

## Site

This site was originally a [Gatsby](https://github.com/gatsbyjs/gatsby) site and, at first, I was _sort of_ happy with it. I remember thinking, _This feels like a lot of work for a simple blog_, but thought I would adjust over time. Unfortunately, I was wrong. When you lose familiarity with a codebase and return to it weeks or months later, the warts really glare at you.

I thought about going back to [Hugo](https://gohugo.io/) or [Jekyll](https://jekyllrb.com/), but I would really like to take advantage of [mdx](https://github.com/mdx-js/mdx) in the future. So, I went with [Next.js](https://nextjs.org/). Initially, this was a lot of work and I can appreciate Gatsby a bit more for what it gives you out of the box; however, I feel a lot better about the static page generation and any future updates.

I think when I wrote [Reflecting on One Year of Writing](/blog/reflecting-on-one-year-of-writing/) I was in a particularly good, ambitious mood – not unlike going to the grocey store hungry. I'm going to hold off on some of the additions in that post — but I have thought that a "Books" section would be a nice, simple addition. I like to look over other people's reading lists. Sometimes, you get hints for new books, sometimes you get hints for who that person is. I think both are neat.

## Pandemic

I can't say the pandemic has been good to me, but both me and my family have been fortunate not to have been very ill. I have a deeper appreciation for life in the "before times" and all the people who have had to work to keep society functioning.

I'm strangely excited to ditch the pandemic small stalk and go back to whatever weather or [MTA issue](https://www.vox.com/policy-and-politics/2017/7/11/15949284/new-york-subway-crisis) that used to occupy our day-to-day.


Still alive


My initial goal in creating this blog was to produce content, useful content,
and to hone my writing skills along the way. Over the past year, I've come to
better understand what it is to write and how much effort goes into _good_
content. The internet is such a large place and there is so much content
available, it's easy to take well-written, thought-provoking articles for
granted. I think it's similar to watching exceptional people excel at their
craft over and over until that level of skill becomes something you expect. It's
not until I started writing again and rereading my posts could I fully
appreciate the work that goes into a piece of writing.

# Thinking about what to write and how

Reading and writing on the internet feel very different than holding and
reading a physical book. In my mind, the position of a web page's scrollbar weighs heavier than the weight of the remaining pages of a physical book. I think I've conditioned myself to a
superficial style of reading on the internet, which is driven by news outlets who value
page views and clicks over the time a person might spend reading an article. Why
write one long article and serve an ad once when you can write two poorly
written articles with the same content and serve an ad twice?

So, I've been giving pause to the kind of content I'd like to produce on this
blog. I enjoy writing explorations more than I do tutorials, which is what
<a href="https://nickolinger.com/blog/electron-interprocess-communication">Electron
Interprocess Communication</a> turned into, but I do think there's a lot of
value in sharing purely technical how-to's. I've benefitted a lot over the years
from people sharing information on the internet and I'm coming to understand
that this sort of writing is a skill in itself. One topic I have in mind for the
tutorial space is _"Go for Node.js developers,"_ but to approach it a little
differently than traditional tutorials.

Though I wouldn't call myself a Rubyist, I admire Sandy Metz's
[Practical Object-Oriented Design in Ruby](https://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley/dp/0321721330).
There's not only timeless information for programmers in this book — it's also
well-written. It's not purely technical but it's also not an opinion only piece.
The prose doesn't try to be too smart and Metz lets her ideas do the talking for
her. In my experience, Computer Scientists are sometimes guilty of
over-complicating concepts, and Metz's style of taking abstract concepts and
conveying them with code alongside clear English is an underappreciated skill. That
book and Sandy's style of writing will serve as a guiding compass for
future posts on this blog.

# Improving content

Rereading some of my previous posts, I'm pretty happy with them. It's good to get
content on the internet and make progress. Though, if I'm being
completely honest, some of the narratives lack focus. The ideas and intent are
there but hazy in execution. I will almost absolutely revisit
[Why I lived in Japan for two years](https://nickolinger.com/blog/why-i-lived-in-japan-for-two-years).
Somewhere in explaining the "how," the "why" was neglected and doesn't come
through in the way my mind's eye had imagined it. I believe that writing well
comes with writing more, so every typed word is progress; however, there are
some things I aim to change about my process going forward.

### Outlining

Most of my posts up until this point have been free-form written which means I
have been letting each sentence's end lead me to the next logical sentence. For
creative writing, I think this works quite well but for writing that needs to
clearly convey concepts or opinions; it produces less-than-clear conclusions,
in my experience. Outlining is a writing tool that I used frequently during high-school and college that served me well. I would compare it to building a fence around an idea so that my brain can explore it. The
next idea is already decided so that the writing doesn't wander off.

### Varied post length

While I gravitate toward writing more thorough posts, I'd like the blog to have
the room for both short, concise posts and more in-depth explorations of a
subject. I've been aiming for 1000+ words per post but brevity presents a
different challenge of having to make choices about what is important and what
is not.

### Writing More

While I'm not ready to commit to a release schedule, I am ready to commit to 2-4
posts per month. The range provides the space to research or to spend more time on
one post and the frequency requires writing to be a habit.

# Improving and adding to the site

I've begun to think of this less as my site and more as my personal
application where I can invest back in myself. It's a place where I can play
with pieces of tech that interest me. I can create new parts of this site that
benefit both me and its readers.

### Emphasis on writing

I wanted to make the site's focus to be writing and one thing I noticed was how
legible journalistic sites are. After a bit of digging around, I found [lora](https://fonts.google.com/specimen/Lora)
and [merriweather](https://fonts.google.com/specimen/Merriweather) to be much more legible than my previous font, [karla](https://fonts.google.com/specimen/Karla?selection.family=Karla&sidebar.open).
Alongside typography updates, I've also:

- Removed colors. I believe this makes the site more accessible to colorblind
  readers. Since I have family that is partially colorblind, this is something
  that I value in a website that I create.

- Added summaries to the <a href="https://nickolinger.com/blog/">blog</a> page.

### A Positive Feedback System

I mostly enjoy Medium's like system. I don't believe that you should be able to endlessly like
something, but I also have no interest in creating a user account system for my
blog. So, I created a stateless "like system" written in Go that works by giving
each user a random UUID and writing that to a cookie. I think this is a nice middle ground between
Medium's approach of endless likes and

As far as I can tell, since I do
not collect any user information and associate it with this identifier, this is
GDPR compliant. It's opt-out at any time by clearing cookies or just not liking a
post. Reach out on [Twitter](https://twitter.com/olingern) if my understanding
of GDPR law is incorrect. There's a future blog post, "Overengineering my blog
with Go, Gatsby, and Google Cloud" in progress.

You can try this new feature out on this post!

# Future Site Features

### Learn in public section

I've added a **docs** section locally to my site, but I'm still polishing this up. The
idea behind this is to create a personal, public knowledge bank that other people can
benefit from and see what I'm currently up to.

### Photo of the week

This is still in the ideation phase, but I'd like a way to post a new picture to
my homepage every week along with some text and have that automated by looking
at a dropbox folder.

### Automated last revision

I'd really like a way for a pre-commit git hook to write a `lastRevision` entry into the
[frontmatter](https://www.gatsbyjs.org/docs/adding-markdown-pages/#frontmatter-for-metadata-in-markdown-files)
of my markdown files.

### Newsletter

I'm currently on the fence about this. I imagine this would be a summary of what I'm currently writing,


Thoughts on the past year of writing, how to improve, and new site features.

Reflecting on one year of writing


When I first started out using C++ in college around 2004, I constantly felt like I was in over my head. In my first semester of C++, I can still remember how hard writing a simple algorithm like _"Finding the largest integer in a list"_ was. After a number of years of programming, those impossible tasks became easier and my focus shifted from solving to solving elegantly. I've found this "elegance" to change from language to language. It's often referred to as being _idiomatic_.

Years ago, I started learning Ruby and one of the things I loved about it is _how_ opinionated it is and how Rubyists have a "feel" for what is idiomatic and what is not. I think [The Ruby Style Guide](https://rubystyle.guide/) and Rubocop are amazing projects for people who need training wheels for writing idiomatic Ruby, but a static code analyzer can only go so far. I think it takes time before you can begin to "think" and reason in a language in a way that _feels_ natural to others.

This reminds me of how I tried to translate from English to Japanese when I was first learning. I would say "kikunai" which is the verb "to hear" negated, but that is not what natives say. Natives say, "did not enter the ear" (mimi ni hairanai) — very literal. I believe the same holds true of programming languages and you have to learn the nuances and patterns that develop around a community.

Linters and style guides can help guide some, but I've found general, high-level guidelines to be the quickest way to understand the ethos a community has agreed upon within a language. The best example would be Python's [The Zen of Python](https://www.python.org/dev/peps/pep-0020/). Dave Cheney followed suit and wrote the [Zen of Go](https://the-zen-of-go.netlify.app/), which I think is great, but as a budding Gopher — it still leaves me with questions such as:

- When do I abstract to packages?
- How do I think about package naming to avoid stutter?
- I see a lot ofsingle letter variable names in Go code. What makes that idiomatic?

I've thought about what it means to be idiomatic for years with the languages I've spent the most time in, JavaScript and Typescript. In 2020, I still don't have an answer. Sure, you can install eslint and format your code with prettier, but that doesn't dictate _how_ things are written. Unlike Ruby and Go where codebases typically share similar structure and style, I've found JavaScript / Typescript to be a free-for-all.

I don't think this is really anyone's fault. The amount of change that the landscape has undergone over the past five years and continues to go through is enormous, which I think leads to a lot of variance in how things are written. The progression in JavaScript and Typescript comes at a tremendous expense: **mastery**. You can't master something that is ever-changing.

## Progress in JavaScript

Did you know that JavaScript (ECMAScript) has been on a yearly release schedule since June of 2015? This is why ES6 is now ES2015.

> On June 17, 2015, ECMA International published the sixth major version of ECMAScript, which is officially called ECMAScript 2015, and was initially referred to as ECMAScript 6 or ES6. Since then, ECMAScript standards are on yearly release cycles.

So, in ES2020 JavaScript will now support these features (via [v8.dev](https://v8.dev/features/tags/es2020)):

> Nullish coalescing  
> Optional chaining  
> globalThis  
> Promise combinators  
> String.prototype.matchAll  
> Module namespace exports  
> BigInt: arbitrary-precision integers in JavaScript  
> Dynamic import()

If you were a user of JavaScript prior to ES2015 (ES3 / ES5. [What happend to ES4?](https://auth0.com/blog/the-real-story-behind-es4/)), then you've experienced a tremendous amount of progress in the language. One of the most important parts of the language, handling asynchronous execution, has undergone multiple iterations to finally arrive at something syntaically similar to other languages such as [C#](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/await), [Python](https://docs.python.org/3/library/asyncio-task.html), and so on.

JavaScript, over the past six years, has progressed from this:

```javascript
function doSomething(someParams) {
  myAsynchronousFunc(someParams, function callback(data) {
    // Operate on data
    // Execution finishes inside callback
  });
}
```

To this:

```javascript
async function doSomething(someParams) {
  const data = await myAsynchronousFunc(someParams);
  // Operate on data inside of original context
  // Execution finishes inside of original context
}
```

A lot had to change under the hood of the language to get to this point ([Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise), [Generators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators)) which has meant:

- Codebases now have a visual age.
  - _"Callbacks, eww"_
  - _"Hey, what's that star thing and yield do?"_
- Open source maintainers have had to keep up with modernizing their projects.
- JavaScript developers have had to learn and relearn the language as new features enter the language.
- No clear conventions exist on when to use new language features.

I'm not arguing against Promises, `async/await`, or any of the other new features that will change the way code is written (like optional chaining) but I think developing conventions around an ever-moving target is setup for failure. For example, I see arrow functions in Node.js code when they're not necessary for capturing the context of `this`. I almost never see asynchronous errors correctly handled one by one like you would be forced to do in Go. Oh, and a lot workplace bike-shedding.

Rubyists have been waiting for Ruby 3.0 for at least [five years](https://bugs.ruby-lang.org/issues/11473) and Gophers for Go 2.0 since as early as [2017](https://blog.golang.org/toward-go2). This has given those communities time to internalize language changes, voice their opinions, and actually look forward to the next iteration. But, _most importantly_, developers in both communities know what good code looks and feels like. In 2020, I cannot say the same for JavaScript but I would really like to.


What does it mean to write idiomatic JavaScript in 2020?

On being an idiomatic JavaScript programmer


For the amount of time I've spent thinking about this, it could certainly permit a book but that wouldn't embody the [silent](https://pdfs.semanticscholar.org/0630/d3fa5dc1bfc197051e9eec1c74867ab8b3bb.pdf), minimalist qualities that make up Japanese culture. For one moment, I'm going to break stride with the conventional Japanese wisdom of "speech is silver, silence is golden" in an attempt to poorly articulate why I moved to Japan.

The shortest answer is:

_yumei deshita_

which loosely translates to _It was a dream_.

It's hard to say how that dream started, but it was clear after three college semesters of Japanese that Japan was somewhere I wanted to be for an extended period of time. I think part of the allure was the challenge of both the language and the culture. It's also common for Americans to only speak one language whereas many other parts of the world can converse in two or more, which I think is unfortunate because language has such a profound ability to [shape how we view the world](https://digest.bps.org.uk/2018/11/02/your-native-language-affects-what-you-can-and-cant-see/). Becoming good at a second language is in the bin of _stuff_ that is good for your brain, and I really enjoy _stuff_ that is good for my brain.

I think [Sakuragi Hanamichi](https://slamdunk.fandom.com/wiki/Hanamichi_Sakuragi) had a role in it, too. If you haven't ever watched Slam Dunk — drop what you're doing right now and go watch all 101 episodes.

<img style="margin: 0 auto 35px auto;max-width: 290px;display: block;" src="https://i.pinimg.com/originals/34/0b/1b/340b1b3a096f23e2b1b0cfbdbfcb6446.gif">

Between 2015 - 2018 I visited Japan a few times and eventually decided that I would enjoy calling it home. While visiting, I wanted to make sure that I hadn't fallen into the trap of creating an idealized version of Japan through the media I consumed, so I kept an anti-tourist agenda on my last trip. This included working remotely, riding on crowded trains, and surveying the general day-to-day of life in Japan. On that last visit, I interviewed with a few different companies and received a couple of offers — _yokatta ne_!

_Small aside:_ The Japanese language and culture have an earnestness to it that translates _very_ poorly but is something that I wish English and Western culture had. _yokatta_ has many different usages, but one of them is to convey relief and _ne_ can be loosely asking for confirmation which, all together, translates to: _what a relief, right?!_ I also frequently find myself saying, _I'll do my best_ ( _ganbarimasu_ ) in English without any sense of irony or shame.

![inaka-field](/images/why-i-lived-in-japan/inaka-field.jpg)

I biked a lot in Japan. I had two extended bike trips where I traveled from Sendai to Fukuoka and from Tokyo to Kyoto. The first trip, from Sendai to Fukuoka, I picked a few places I wanted to visit and then packed my bike and put it on the shinkansen. The second trip was from Tokyo to Kyoto and only paused and stoppped due to the pandemic. The first trip was focused on seeing as much of Japan in as little time possible; however, the second trip I didn't use the shinkansen or train. The mountains of Japan can be very punishing, but they almost always have some reward for you at the top.

Like cycling, not everything in life was easy and I underestimated the weight that interpreting and functioning in a different language would have over time on me. When I first moved to Japan, I couldn't understand the foreigners who were not putting everything into learning Japanese but two years later I came to realize their disposition all too well. If you don't have a support system, i.e. classes, friends, and a routine, it's going to be hard to make progress in the language. Even though I'm what you would call an "intermediate Japanese learner," which people frequently identify by the JLPT test numbers N2/N3, daily aspects of life like bills, work contracts, and health related things made ever becoming fluent feel insurmountable. In the beginning it's fun, "_Hey, look! My first Japanese bill_," and then, "_Hey, I can read 30 pacento <sup><a href="#notes">[2]</a></sup> of this!_," and finally, "_Ugh, new bill. Does someone want money or have I already given them money?_"

If it weren't for finding [Lindy Hop](https://en.wikipedia.org/wiki/Lindy_Hop) during college and sticking with it over the years, I think the move to Tokyo would have felt a lot scarier. These days, cities all over the world have dance scenes and it's incredibly comforting to know that there are people across the planet that you can connect with just by showing up to dance.

I _loved_ to meet people who couldn't converse in English well or at all. There's sort of an unspoken rule of using the language that a group is most comfortable in, so if you have Japanese friends who are great at English and your Japanese is bad — they'll switch to English. I don't know of any superpower that allows you to force people to deal with bad Japanese, but I will keep searching. While in Japan, I felt a certain comradery with other foreigners when speaking Japanese with them. There's something nice about knowing others share some of the same struggles that you do, like differentiating the word [candy and rain](https://blogs.transparent.com/japanese/japanese-pitch-accent/).

Speaking of non-natives, there was a Nepalese restaurant in my neighborhood where I loved to occasionally eat. The lady who seated you and took your orders was probably one of the warmest, most cheerful human beings I've ever interacted with and you could hear that in her Japanese. If you had a favorite that you ordered more than twice, she had your number. In a culture where people can be sometimes be aloof, she stuck out in the best of ways.

I knew before I wrote this that this post that it would be inconclusive. Friends (new and old) and strangers would often ask, "_Why did you move to Japan?"_ Truthfully, each day I woke up while living there, I felt that there was a different reason for being there, and my original ambitions for moving have been muddied by reality. I think as time moves on and the memories fade and congeal into an image of Japan, I will continue to not have a definitive answer but I will always have great stories.

---

<h3 id="notes">Notes</h3>

<b>\*</b> - Possibly coming soon is an image gallery of all of my favorite images of Japan. Message or tweet at [me on Twitter](https://twitter.com/olingern) if you'd like to see that come to life.

1 - Japanese characters are not used in this post because most readers will not have the fonts installed.

2 - "pacento" is a loan word written as パーセント ( pa—sento ) which means percent.

3 - This wants to be a bad [joke](https://en.wikipedia.org/wiki/Japanese_pitch_accent), but the argument could be made that Japanese people are pitch-perfect within the context of their language.


A personal essay documenting my journey to Japan.

Why I lived in Japan for two years


This post originally began as something quick to help people who were beginning to work with Electorn, but as I kept writing — I kept learning neat histories and tidbits that I also thought were worth sharing. This post is still focused on Electron, but I think it takes some fun twists and turns. Exploring the <a href="#references">references</a> and <a href="#materials">recommended</a> materials is well worth your time, in my opinion.

---

When I began working with Electron, it wasn't clear to me the roles that the renderer or the main process played and how or why I would communicate between them. As it turns out, understanding these two processes are the basis for building any Electron application. This post will look at interprocess communication, models of interprocess communication, and its application in Electron. Finally, we'll end with a basic game of interprocess communication ping pong.

### What is interprocess communication

Interprocess communication (IPC) isn't something specific to Electron but rather a concept that finds its origin in prior to even Unix's birth. It's not clear when the term _Interprocess Communication_ was coined, but the idea of passing data between one program or process dates back to 1964 <sup id="cite_ref-1" class="reference"><a href="#references">[1]</a></sup> on a typewritten piece of paper where [Douglas McIlroy](https://www.cs.dartmouth.edu/~doug/) describes what would become Unix pipes in the third edition of Unix in 1973.<sup id="cite_ref-1" class="reference"><a href="#references">[2]</a></sup>

> We should have some ways of coupling programs like
> garden hose--screw in another segment when it becomes when
> it becomes necessary to massage data in another way.

<div class="byline-italic"><a href="http://doc.cat-v.org/unix/pipes/">The Origin of Unix Pipes</a></div>

He also uses the expression, _"for buggering around with_" which I've never heard but fully appreciate.

We can get a glimpse of McIlroy's vision and IPC using employing [Ken Thompson](http://www.linfo.org/thompson.html) brought together in _"one feverish night"_ <sup id="cite_ref-1" class="reference"><a href="#references">[3]</a></sup> by using the pipeline operator (`|`) to take the output of one program and direct it to another. A command that you're probably familiar with is `ls` which is short for list. We can combine the output of `ls` with another program like `grep`, a search by regex tool, using pipes.

```shell
ls | grep .js
```

<div class="byline-italic">Listing all .js files in the current directory</div>

Pipes are just one form of IPC in unix systems and there are many more such as signals, message queues, semaphores, and shared memory<sup id="cite_ref-1" class="reference"><a href="#references">[4]</a></sup>. Windows also has pipes and many of its own IPC implementations, so it should be no surprise that the browser has its own as well.

If you've used the browser's [postMessage API](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage), then you've facilitated communication between different browser windows windows using [Cross-document Messaging](https://html.spec.whatwg.org/multipage/web-messaging.html#web-messaging) which isn't in seperate processes (_as of now_), but does share similar characteristics with IPC.

Communication in Electron follows a different pattern that can be found in both peripheral and software architectures — a bus<sup id="cite_ref-1" class="reference"><a href="#references">[5]</a></sup> and a pipe-like API, the browser's [Channel Messaging API](https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API). The channel messaging API _"...allows two separate scripts running in different browsing contexts attached to the same document ... to communicate directly, passing messages between one another through two-way channels (**or pipes**) with a port at each end._" <sup id="cite_ref-1" class="reference"><a href="#references">[6]</a></sup>

Like most good ideas in Computer Science, the good ones are recycled and pipes are no exception as we see the Channel Messaging API modeling a near 60-year old idea.

### IPC in Electron

In Electron, there are two processes that we are concerned with: **main** and **renderer**. IPC for these processes are facilitated through `ipcMain` (main process) and `ipcRenderer` (renderer process).

You can't go far with Electron's IPC without talking about Node's [EventEmitter class](https://nodejs.org/api/events.html#events_class_eventemitter) and since this has been covered [elsewhere](https://www.freecodecamp.org/news/how-to-code-your-own-event-emitter-in-node-js-a-step-by-step-guide-e13b7e7908e1/), I'm going to continue focusing on the Electron's IPC implementation.

In my opinion, there are two architectures at play:

1. **The event system**: The message-bus/pub-sub like nature of Electron's ipcMain and ipcRenderer inherit from Node's EventEmitter class.
2. **The mechanism for sending data**: A unix-like message passing system managed by the Channel API's [MessageChannel](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel) that facilitates sending

The event system allows us to publish messages to a channel by listening for data emitted to a channel. A channel is a string that ipcMain and ipcRenderer use to emit and receive events/data on.

This, generally, follows this form:

```javascript
// Receiving a message
//
// EventEmitter: ipcMain / ipcRenderer
EventEmitter.on("string", function callback(event, messsage) {});

// Sending a message
//
// EventEmitter: win.webContents / ipcRenderer
EventEmitter.send("string", "mydata");
```

Pay careful attention that `send` is not bound on `ipcMain` and instead is bound to `win.webContents`. See [the docs](https://www.electronjs.org/docs/api/ipc-renderer#ipcrenderersendchannel-args) for more info.

Also, it goes without saying that you can only send a message from a process's respective handler. So, if you're in the renderer process, you should be using `ipcRenderer.send` to send messages to the main process and using `win.webContents.send` to send messages from the main process to renderer process(es).

### Basics of an electron program

In an Electron project, the `package.json` specifies a JavaScript file that Electron treats as your **main process**. The below `package.json` will expect an `index.js` file to exist in the current directory since the `start` script's context is the current directory.

```javascript
{
  "name": "basic",
  "version": "0.0.0",
  "main": "index.js",
  "scripts": {
    "start": "electron ."
  },
  "dependencies": {
    "electron": "^8.2.5"
  }
}
```

<div class="byline-italic">A basic Electron package.json</div>

### Creating the renderer process

Inside of the main process, you can create an instance of `BrowserWindow` which will run its own render process. Creating a basic render process follows these steps:

- Create a hidden browser window
- Load an HTML file
- Show the window once `ready-to-show` is emitted from the `BrowserWindow` instance.

Here is a minimal **main process** that creates a browser window

```javascript
const { app, BrowserWindow, ipcMain } = require("electron");
const path = require("path");
const url = require("url");

function onAppReady() {
  // Create the window
  const mainWindow = new BrowserWindow({
    height: 800,
    width: 800,
    show: false,
  });

  // Load main.html in current directory
  mainWindow.loadURL(
    url.format({
      pathname: path.join(__dirname, "main.html"),
      protocol: "file",
      slashes: true,
    })
  );

  // Once electron 'ready-to-show' is emitted, show mainWindow
  mainWindow.once("ready-to-show", function showMainWindow() {
    mainWindow.show();
  });
}

app.on("ready", onAppReady);
```

<div class="byline-italic">Minimal electron main process</div>

### Communicating between the main process and renderer process

Communication between the main and renderer process is surprisingly easy. I think most use-cases will be from renderer to the main process, so I'll be focusing on that.

To send from the renderer to the main process you can use the `send` method from the `ipcRenderer` module. It takes two arguments a channel as a `string` and an array of arguments as the second parameter.

Though it should be noted that the docs indicate an array, I've found this to also work with just strings or integers.

> ###### ipcRenderer.send(channel, ...args)
>
> - channel: String
> - ...args: any[]
>
> Send an asynchronous message to the main process via `channel`, along with arguments. Arguments will be serialized with the [structured clone algorithm](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm), just like [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage), so prototype chains will not be included. Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will throw an exception.

<div class="byline-italic"><a href="">IPC Renderer API docs</a></div>

Inside the renderer process:

```javascript
const { ipcRenderer } = require("electron");
document.addEventListener("DOMContentLoaded", function () {
  ipcRenderer.send("my_channel", "my data");
});
```

And, in your main process you can receive this:

```javascript
app.on("ready", function onReady() {
  // Code to load renderer process omitted here. Refer to above

  // Receive message
  ipcMain.on("my_channel", function (event, arg) {
    // prints "my data"
    console.log(arg);
  });
});
```

**Some notes:**

- I like to use enums or objects that are shared across the renderer and the main process to prevent any errors.

```javascript
const IPC_EVENTS = {
  READY: "ready",
  READY_TO_SHOW: "ready-to-show",
};
```

- The `"my data"` string could be an object, array, or integer, but there are limitations. Do take heed to the documentation excerpt from above for `send`:
  - _Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will throw an exception._

### IPC ping pong

Taking everything we've learned here, we can build a basic game of ping/pong message passing. You can find the code for this demo [here](https://github.com/olingern/electron-ipc-ping-pong)

![output3](https://user-images.githubusercontent.com/1470297/81518491-3bc6db00-930c-11ea-9e63-e634ddc28fdd.gif)

### Addendum

I'd like to thank all of the Electron contributors for all of their work over the years. [Visual Studio Code](https://code.visualstudio.com/) has been one of my favorite developments over the past five years and it's only possible with Electron. As a result of Electron, using Linux as a daily driver is now effortless.

I'd especially like to thank [Cheng Zhao](https://github.com/zcbenz) for his work on Electron and for also taking time to look over this. One thing he did note was the addition of the MessagePort API's coming in Electron v10. For a description of the upcoming additions, take a look at [Jeremy Apthorp's](https://github.com/nornagon) pull request ([#22404](https://github.com/electron/electron/pull/22404)) where he goes over the changes. You can also view the proposal [here](https://hackmd.io/bwzFRWZzRIyewIBc1Vf7DQ?both).

<h2 id="materials">Recommended Materials</h2>

- [Unix Pipeline (Brian Kernighan) - Computerphile](https://www.youtube.com/watch?v=bKzonnwoR2I)
- [How to code your own event emitter in node js](https://www.freecodecamp.org/news/how-to-code-your-own-event-emitter-in-node-js-a-step-by-step-guide-e13b7e7908e1/)

- [Electron Process Architecture](https://www.electronjs.org/docs/tutorial/application-architecture#main-and-renderer-processes)

---

<h2 id="references">References</h2>

1 - McIlroy, Douglas (October 11, 1964). [The Origin of Unix Pipes](http://doc.cat-v.org/unix/pipes/)

2 - [Research Unix](https://en.wikipedia.org/wiki/Research_Unix). (n.d.).

3 - McIlroy, Douglas (n.d.). [A Research UNIX Reader:
Annotated Excerpts from the Programmer’s Manual, 1971-1986](https://www.cs.dartmouth.edu/~doug/reader.pdf), pg. 9

4 - Rusling, David (1996). [Interprocess Communication Mechanisms](https://www.tldp.org/LDP/tlk/ipc/ipc.html)

5 - [PCMag Encyclopedia: Bus](https://www.pcmag.com/encyclopedia/term/bus)

6 - `message-channel-main.md` contributors as of commit [1d15839](https://github.com/electron/electron/commit/1d158399a6bb7fc45d42983f499915b59c9035f8) (April 2, 2020) - [Message Channel Main](https://github.com/electron/electron/blob/master/docs/api/message-channel-main.md#messagechannelmain)


Exploring what interprocess communication is and how Electron facilitates communication between processes.

Electron interprocess communication


<div style="color: #555; font-size: 1rem; padding: 20px; background: #fff; margin-top: 40px; box-shadow: 0 1px 1px 0 rgba(0, 0, 0, 0.14), 0 2px 1px -1px rgba(0, 0, 0, 0.12), 0 1px 3px 0 rgba(0, 0, 0, 0.2);">
    <div style="color: #303336; display: inline; font-family: serif; font-size: 22px; font-stretch: normal; font-style: normal; font-weight: 700; letter-spacing: 1.2px; line-height: 50px; padding-right: 15px;"><b>perfectionism</b></div>
    <div>\ pər-ˈfek-shə-ˌni-zəm\</div>
    <b>1)</b>
    <div style="margin-left: 20px; margin-bottom: 20px;"><b>a:</b> the doctrine that the perfection of moral character constitutes a person's highest good</div>

</div>
<div class="text-xs"><a href="https://www.merriam-webster.com/dictionary/perfectionism">Definition of perfectionism from Merriam-Webster</a></div>

Beginning with a definition feels cliche like something from academia, but I think it's easy to take language for granted or have an opaque idea of a concept in your mind that is misconstrued over time by experience and reconditioning.

Working in a profession where you put your mind's best (_well, most days — right?)_ into something to be interpreted by a machine and grokked by others can lead to a healthy paranoia of _is this good enough?_. But, what happens when this spirals out of control?

As a self-identified perfectionist who often feels the paralysis of perfectionism's grips, I can tell you what happens: _nothing_.

**Fear of producing**

For me, and maybe many others out there struggling with producing works they're proud of, the paralysis stems from a disconnect between my ambition, what I'm capable of, and time. There will be some idea that crosses my mind and festers into a full-blown start-up or a highly successful open source project. And because of this grandiose style of thinking, getting started becomes increasingly more difficult.

**Subscribe to meaning rather than "Just do it"**

Since you're reading this, it means I've overcome _some_ part of my perfectionist nature. One subtle, but very meaningful change I've made is identifying my motivation for something I want to accomplish.

I think about previously failed or goals that I either didn't meet or had no interest in meeting. One of those goals that I _thought_ I had interest in, but never completed was a goal set at my first job out of college as a Junior .NET programmer by my manager.

_"We want you to become the .NET guy,"_ he said in one of my quarterly reviews. He went on to explain what that meant and how getting an ASP.NET certification would be a great goal for me.

I was not excited.

_"Grinding out a bunch of API's that are going to inevitably change every three to four years isn't programming,"_ is what I told myself. I wasn't wrong, but ten years later I know it's more nuanced than that. Understanding the internals and design decisions of a well-architected ecosystem would have benefitted me enormously, but that's not how I framed the task because I didn't have the experience to know _how_ it would benefit me. Though, in the grand scheme of time and the enormous list of 'things that can make you a better programmer', getting a certification is still pretty far down on that list.

I think you can see that I was destined to fail and arguably failed before I did not start. Why? Because my motivation was extrinsic rather than intrinsic.

You've probably seen the internet meme of [Shia LaBeouf of screaming, _"Just do it_](https://www.youtube.com/watch?v=ZXsQAXx_ao0) (_volume beware_). I appreciate the sentiment of pursuing your dreams, but what if you've been groomed to want something you actually don't want to do? This was exactly my predicament and in my case was an **extrinsic motivator**.

> _Extrinsic motivation refers to behavior that is driven by external rewards such as money, fame, grades, and praise. This type of motivation arises from outside the individual, as opposed to intrinsic motivation, which originates inside of the individual_

<div class="byline"><a href="https://www.verywellmind.com/what-is-extrinsic-motivation-2795164">verywellmind.com</a></div>

This is not to say extrinsic motivation is bad or inherently wrong, but I think how potent a motivator is will vary person to person depending on its source.

Some people in this world have the will and motivation to grudgingly push through about anything. If that's you, congratulations — but if it's not, why not ask yoursel, "_Is this for me?_"

**Embracing it**

Though perfectionism can lead to anxiety and paralysis, I think there are some positives that can be distilled from it.

- **Belief in oneself**

  You've seen how well crafted or well-done something can be and you believe that you can do it. Even if it's out of your reach, the belief in yourself can act as a [self-fulfilling prophecy](https://www.britannica.com/topic/self-fulfilling-prophecy) where eventually you realize what you're after.

- **Fighting complacency**

  Often, I've achieved a goal to only move the goal post further to continue progress down a certain path. If you acknowledge the accomplishment, I think this can be a healthy way to live alongside perfectionism.

- **Thoroughness**

  In Japan, certain trades or professions demand a high attention to detail. Doing a little digging may lead you to explore [monodzukiri](https://uttana.com/blog/lean-art-monozukuri-much-making-things/) (ものづくり) or the rail system's [shisa kanko(指差喚呼)](https://www.japantimes.co.jp/news/2008/10/21/reference/jr-gestures/#.Xk9LlmaRVhE).

  In western cultures, _"Move fast and break things,"_ is often the philosophy many businesses embrace because of the correlation between time and money, but I've found the opposite in Japan. In Japan stability — whether business or interpersonal — is highly valued which I think it could be interpreted as perfectionism in western culture.


A personal essay on the struggle of having a mind that always aims too high

Fighting Perfectionism


_**Note**: this blog has Japanese characters in it. I've included English where it might not be displayed._

If there's one thing for certain in Japan — it's that _"You're welcome."_ And by that I mean, Japanese store employees go out of there way to make you feel welcome.

いらっしゃいませ ( i-ra-shai-ma-se )

As I walk into one of the grocer's there's even a motion sensored greeter there to let me know I'm welcome to spend my hard-earned yen.

After a while it becomes a part of the symphony of "sorries", "thank you's", and mini-bows that is life in Tokyo. When I'm not greeted when approaching the checkout or entering an establishment, it's almost jarring.

_"Well, these people just aren't very welcoming at all!"_ I might think.

It's interesting how we adjust and acclimate to new environments. How we redefine "normal" or interpret actions given the context.

I visited Australia after having lived in Japan for nine months in 2018. I walked by Uniqlo (ユニクロ) and heard an employee saying, _"Welcome to Uniqlo ... Welcome!"_

I shuddered a little. The word いらっしゃいま translates just fine, but the spirit of it doesn't. One of the things that I love about the Japanese language is the individuality that I hear in people's words, and I can't count the variations irasshaimase I've heard. I don't hear that in "Welcome to xyz".

My favorite way of saying irasshaimase has to be せー ( _seeeee_ ) usually said with an upward ending intonation. Around my second week in Tokyo, I walked into my local grocery store, Life, and proceeded escalator that led to the bottom floor. While going down this escalator, I heard the most guttural, emphatic せー that I've heard to date. This man from some unidentifiable location began "ssssseeeeee" as If he were brewing some welcome stew and topped it off with an upward, shrieking intonation.

_"My god,"_ I thought.

_"You can scream at work in Japan if it's to make the customer feel welcomed."_


An observation on how culture doesn't always translate.

irasshaimase


I don't think pull request etiquette is something widely talked about and reviewing is a skill that eluded me for years of my career. This post is as much
the internet wanderer who stumbles upon it as much as it is for my future self. These are guidelines I aim to follow

# Before opening

**How big is the change?**

If you have a feature or architectural change that is going to require _"heavy lifting"_, these are the sort of things that should be worked out _pre-pr_. It's not a pleasant process for either party (reviewer or reviewee) when a pull request needs to be closed.

**Does it meet the feature request / spec?**

Sometimes, I can find myself so eager to push something out so I can have that feeling of being "done." Reaching the finish line is rewarding, but it's worth nothing if you
forgot the baton mid-race. And by this I mean, have you thoroughly went through each requirement and request and considered their edge cases? It seems so obvious now, but I
can remember how as a CS student or junior engineer that I wrote off the details. _But, this 'mostly' works!_ I might have thought. There are some areas of development where being pedantic pays dividends, and accuracy of an implementation will save both you and the people around you time. It has the added effect of showing people around you that you care about your work.

**Know where to merge**

If you're working on an open source project or joining a new team, you'll want to figure out how the project is using branches. For example, many web applications may use a **development**, **staging**, **master** branching scheme where each branch corresponds to a different application environment. A CLI application may use a totally different scheme.

# Opening a pull request

**Verbose pull request info**

Have you ever looked at a pull request and it was blank? No info, no related issues. Typically, in every pull request I'll include both a _Summary_ and _How to Test_. Below is a basic example of adding [rate limiting](https://en.wikipedia.org/wiki/Rate_limiting) to an application's login page.

![pr](/images/example-pr.png)

**Getting a reviewer**

Sometimes, whether working on open source or just within your team at work, getting someone to look at your code can take time. If I'm working with a piece of code that the original author is the only person with extensive knowledge, I might request a review from them or at least ask them to look over it.

Since code review can a real time investment, I've found using a bot that selects reviewers in a round-robin fashion to be the most dipolomatic for teams larger than three people.

# Reviewing a pull request

1. Does it pass the basics? (linting, code formatting, style guide)

Having a linter (`golint`, `eslint`, `rubocop`, etc.) run when a pull request is submitted can save a team time and make sure code is, generally, following all the same rules. Not having to focus on syntax or general code smells caught by linters can allow reviewers to actually focus on review.

2. Does it actually work?

I've seen many PR's merge and then reach a staging or production enviornment to only find the feature _actually_ doesn't work. **Actually checking a pull request out** and testing that if satisfies what it intends to do is an important.

```sh
git fetch origin pull/ID/head:BRANCHNAME

git checkout BRANCHNAME
```

[source](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)

3. Does it meet all cases in the spec?

This feels like a gray area, because the actual details of the implementation should be between the requester and the person opening the pull request — but understanding changes helps to build context and no programmer is perfect.

# Other antecedtoes

### Be constructive and assume people are trying their best

<div class="image-with-byline">
<img src="/images/gomi.png" />
<span className="italic text-xs">Translates to "this is garbage"</span></div>

I don't think anyone wakes up and says, _"I'm going to write the worst code possible today. I can't wait for someone to try to review it!"_ The code you're reviewing is a culmination of this person's time, so, in some ways, you're looking at how someone has chosen to spend their time.

### Provide timely reviews and replies

If review drags on for days or weeks, PR's can lose momentum and the author can move on to something else and forget the specifics of their implementation. Each time the author has to come back and refresh their memory, that has a cost.

### Consider doing a PR demo for the reviewer

I've done this for the past couple of years when something is complex enough that it warrants a walk-through. Details like design decisions and architeture are sometimes best suited for a real-time conversation.

---


A mental framework for how I manage and handle pull requests.

How I Open and Review Pull Requests


The movie [Hackers](https://www.imdb.com/title/tt0113243/) burned this idea of _eliteness_ into my brain at an early age. They toss around this phrase

> _she's elite_

or

> _he's elite_

as if there exists is a gated community of hacker gods. To the movie's credit, it does portray that gated community quite well, and planted the seeds of imposter syndrome at a young age for me.

So, in high school, I had my first go at using a Linux distro, [Fedora](<https://en.wikipedia.org/wiki/Fedora_(operating_system)>), for a while. Mostly, for bragging rights amongst my keyboard inclined friends. I felt a great deal of pride opening my black CD binder and flipping through my collection of burnt distros that I had only lightly or even never used. Fedora, SUSE, Mandrake scribbled on top to identify each burnt disc in _elite_ red.

Typical priorities of a early 2000's teenager led me back to Windows (_MSN Messenger, Starcraft, etc._). I would go on to college and try again, but many classes required me to use Windows software on a regular basis so my Linux partation became something tucked away in the attic of my hard drive.

_Oh! the oppression._

**Hello Apple**

Finally, in 2009, I bought my first Macbook. This was near the height of 'Apple hype,' and I think the hype was well deserved, but not the price tag. So, that first Macbook -- was a used Macbook. I often found myself fumbling around the desktop, clicking into the file browser, Finder, trying to navigate my way through the OS. You can imagine the relief I found when a friend introduced me to Spotlight.

Still till this day, I love OSX's aesthetic. I loved how well it worked and how I didn't have to reinstall drivers because mine had magically stopped working. At that time, I was a VB.NET / C# developer, but came home to this used Macbook often wondering where my **Start Menu** was.

OSX was a great segue from Windows to a more Unix-like system. Though, using Unix-like here is actually incorrect. It seems some part of OSX's previous marketing was specifically targeted at people interested in using UNIX. So, in fact, it's more correct to say OSX is a great segue to a UNIX based system.

From their [2011 Technology Brief](http://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Users_TB_July2011.pdf):

> There are already tens of millions of OS X users—consumers, scientists, animators, **developers**, system administrators, and more—making OS X the most widely used **UNIX** desktop operating system. In addition, OS X is the only **UNIX** environment that natively runs Microsoft Office, Adobe Photoshop, and thousands of other consumer applications—all side by side with traditional command-line, X11, and Java applications. Tight integration with hardware—from the sleek MacBook to the eight-core Mac Pro computer—is making OS X the platform of choice for an emerging generation of **UNIX** users.

_Just an aside, but isn't fascinating the number of times Apple mentions UNIX in this marketing piece? The focus of those machines was clear and they appeased a great deal of users within their target market._

I would continue being an OSX user up until 2018. I was looking to purchase a machine that was portable and powerful and, since Apple has shifted the Macbook Pro's focus, I decided to look elsewhere. Eventually, I settled on an ASUS Zenbook. I chose one of the "ultrabook" models with USB-C charging thinking I would be traveling with it all the time. It was a nice thought.

After my first week of using it, I began to think I had bought a small airliner. I would hear the fan kick in to overdrive often when running Windows. Upon inspection it was always something I had no need for: Windows Indexing Service, Cortana, or Windows Defender. I understand that those pieces of software are useful (_Well, maybe not Cortana._), but I'd like to be consulted if my operating system is going to utilize 100% of my CPU in the background.

> "Hi, your system may be inoperable for the next five minutes so that we can do unnecessary things. Is that okay?"

No, no it's not okay.

### Back to Linux

I wanted something minimal for this i3 processor sporting ultrabook, but something familiar, too. Lubuntu was a nice compromise -- the core and stability of Ubuntu without all of the shiny things. Lubuntu was and is great. It was a great daily driver for a number of months.

I had been eyeing one of my co-worker's enviornment for a while, but never asked about it. One day while we were sitting by his computer I asked, "What distro do you use?"

"Oh, this is Arch!," he emphatically replied. He lit up a bit, so I was intrigued.

Some office programmer chatter of, "Arch is too hard to use" and "I can't even get through the install" motivated my inner masochist to schedule a date with Arch in the coming weekend.

### Installing Arch

I think getting through the Arch install is a small badget of honor. At first, I tried only using the Arch wiki (_which is amazing, by the way_), but I needed some hand holding. This video, [Install Arch Linux in 10 minutes](https://www.youtube.com/watch?v=GKdPSGb9f5s&vl=en), was a godsend to simplifying the install process.

After finishing the install process, you're left with a blank terminal with a blinking cursor. I knew this is what would happen, but in practice it was very humbling and I began to realize all the things I take for granted in an operating system. Things like how you manage your network, system time, and USB devices are all left to you. It can be a bit daunting but can be equally empowering to know you have control over how your operating system _operates_.

My analogy for people curious about Arch is that it is akin to legos -- and you're building the operating system that suits you. I feel that you grow into the collection of tools that you've chosen, and that will look slighlty different for each person.

Using Arch has also taken this abstract concept of an Operating Systemm that is often opaque and difficult to understand, and made me think of OS's more as collection of tools. There's nothing in the background collecting your data and you're in charge of how and when you update your machine.

### Not a silver bullet

Now, this probably reads like a car salesman was tasked with selling you on Arch -- all of the pro's and none of the cons! So, what are some of the things I find difficult?

- **Mounting USB devices**

  I'm sure I can figure out how for Arch to remember where I mounted a USB and to auto mount it each time I insert a storage device, but I just haven't invested the time to do it. This is, generally, my experience with Arch -- anything is possible if you put the time into it.

- **Memorizing hot keys**

  I don't use a desktop environment and insteads use a window manager. This means that I have to memorize a number of hot-keys that I configure and then without fail, forget. It's only after constant usage do these things start to ingrain themselves into my workflow.

- **Continually improving configuration**

  A segue from the previous point. Like any sort of "tech fatigue," (i.e. Javascript fatigue), it can get tiresome to keep coming back to your configuration over and over. It often feels like something you might fix in your house or on your bicycle — you finally get to the point where you say, "_I've had enough_" and you take that motivation to improve your enviornment.

- **Gaming**

  Linux gaming has gotten better, but the Arch steam client isn't there yet.

Nothing is perfect, but I like the idea of working toward an enviorment that fits me best. Arch, to me, is a democratic Operating System where you have the burden of exercising your freedom by investing time into improving it.

### Final Words

I'm incredibly in dept to all of the developers whose time and software makes it possible for me to run Arch the way I see fit. Here's a short list of software I use:

[dmenu](https://wiki.archlinux.org/index.php/dmenu), [firefox](https://wiki.archlinux.org/index.php/firefox), [i3](https://wiki.archlinux.org/index.php/i3), [i3-gaps](https://github.com/Airblader/i3), [i3blocks](https://github.com/vivien/i3blocks), [pcmanfm](https://wiki.archlinux.org/index.php/PCManFM), [scrot](https://wiki.archlinux.org/index.php/Screen_capture#scrot), [xorg](https://wiki.archlinux.org/index.php/xorg), [yay](https://github.com/Jguer/yay), [zsh](https://wiki.archlinux.org/index.php/zsh)


My journey to becoming an Arch Linux user

Blog posts