Skip to content

Instantly share code, notes, and snippets.


Dustin Masters dustinsoftware

Block or report user

Report or block dustinsoftware

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
dustinsoftware / Dockerfile
Created Jan 6, 2020
run untrusted react code samples in container
View Dockerfile
FROM node:12
COPY . /app
RUN yarn install
CMD exec /bin/bash -c "trap : TERM INT; sleep infinity & wait"
View ember 2019 cfp


As Ember apps mature over time, more components and assets are added, which can cause the boot up time to slow down as well - but you can change that! Tools like route-level code splitting with Embroider, precaching with ember-service-worker, automatic lighthouse audits during CI, and more can help ensure your app stays fast! We'll look at debugging tools with an example app, and measure the positive impact of each optimization we talk about.


This is not intended to be a bikeshedding discussion of what performance improvements are best. For instance, most apps won't meaningfully benefit from a 5 KB size reduction overall. The focus is specifically on how to keep your app booting up fast on mobile devices over the life of a project by deferring unnecessary work.

Intended audience will be people already familiar with building Ember apps. To be introduced over the talk:

  • Embroider - route level code splitting
  • Prember - faster first contentful paint / first meaningful paint timings

Scaffolding on a skyscraper

Photo by Karl Bewick on Unsplash

The case for embeddable Ember

In this post I'm proposing some improvements for Ember in an important, but often overlooked use case: embedding Ember components in non-Ember applications. Ember is great for brand new web applications. But what story do we tell for existing apps that are looking to transition to Ember?

Consider a single page application that started in 2016 that uses React and webpack. There's already support for pulling in ES modules and rolling them into the production bundle. However, the team has heard about the many tooling improvements to Ember and wants to experiment shipping a small component in this existing React app. However, because the app uses a client-side router, there needs to be a mechanism to load the Ember app and render into a div without resorting to an iframe.



Build hacks: Faster Ember builds with Docker on Windows

When I joined a team maintaining an Ember web app, I was surprised to learn that almost the whole team developed exclusively on MacBooks. The team experienced slow Ember builds on Windows, and dealing with native Node dependencies (such as node-gyp) was a frustrating experience. Microsoft has made some recent improvements to support Node-based development environments on Windows, so I set out to see what we could do to make this better.

Note: WSL2 has been announced, which resolves many of the performance pains we experienced. This post should still be relevant for those wanting to use Docker as a development container.

Just show me the code!

A working demo of the Docker setup is available on GitHub. We'll link to it throughout this article.

View iot-light.cs
using System;
using System.Linq;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading;
namespace udptest
class Program

Keybase proof

I hereby claim:

To claim this, I am signing this object:


Early draft, please don't publish until the performance improvements are merged and shipped.

React 16.5 recently shipped, which added support for some new Profiling tools. We recently used these tools to identify a major source of slow render performance. is a web application powered by React 16.3. The homepage consists of a reverse-chronological timeline of posts. We received some reports that interactions with posts (such as replying) caused the browser to lag, depending on how far down the post was on the page. The further down the page the post was, the more lag occurred.

After updating React to 16.5 on a local copy of Faithlife, our next step was to start profiling and capture what components were re-rendering. Below is a screenshot of what the tools showed us clicking the 'Like' button on any post:


At Faithlife, we've been using OAuth 1.0a to handle authentication between services. Instead of designing our apps as monoliths, we've been perferring to build lightweight frontend applications that call RESTful microservices, returning entities as JSON. These frontend applications don't touch our databases directly. Among other benefits, this allows us to better allocate hardware resources (CPU, RAM, disk) to applications that need them.

A typical request to Faithlife might look something like this:

![mermaid sequenceDiagram participant Frontend participant Accounts participant Community Newsfeed participant Amber API

dustinsoftware / client.cs
Last active Jul 18, 2018
HttpClient headers repro
View client.cs
using System;
using System.Linq;
using System.Net.Http;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Threading.Tasks;
namespace HttpClientTest
class Program

OAuth 2 Bearer Tokens

Current design:

  • Based on OAuth 1.0a with a central authority
  • Access token / secret generated by central authority, used in combination with consumer token / secret
  • Client creates OAuth header from consumer token/secret and access token/secret. HMAC-SHA1 or PLAINTEXT signatures used
  • Each web service makes a call to central authority to get current user information based on OAuth header

Problem A - Increased latency:

  • Service A needs to verify OAuth header
You can’t perform that action at this time.