
<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


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.

Blog posts tagged withsite

Blog posts tagged with
site