close icon

What's TJ Holowaychuk's Stack These Days?

TJ Holowaychuk has been working on a new project called Apex. We caught up with him to get all the details!

June 07, 2016


TJ Holowaychuk's tech stack for his new startup includes AWS Lambda, Go, React, and Auth0. We interviewed him to get the full details on his first product, Apex Ping, and what his motivations were for choosing the stack he did.

You might be familiar with TJ Holowaychuk from one of his 550 modules on npm, including express. TJ is well known for his NodeJS work, but he's recently made the switch to Go and has been working on his own self-funded startup called Apex. We wanted to catch up with him about his new project and learn more about the tech stack he's chosen for his first product called Ping.

apex ping dashboard



Can you tell us a bit about yourself?


I'm a backend and frontend engineer from Canada. I was previously part of the backend team helping scale to billions of events per day. I recently started my own software company, Apex, as a solo self-funded venture, with Apex Ping being my first 'micro' product.


Can you tell us more about Apex Ping? What is it and what does it do?


Apex Ping is an uptime and performance monitoring tool with rich reporting and alerting capabilities. Anyone maintaining a website, app, or API can create “checks”, HTTP requests performed against an HTTP end-point every minute from a number of selectable locations all over the globe.

Alerts and weekly reporting keep the team informed so your customers are always provided with the best experience possible.

The Tech Stack


What stack are you using for Apex Ping?


With the exception of the app server and marketing site, the entire product is “serverless”, running on AWS Lambda. All backend infrastructure & API code is written in Go.

Checks and alerting are batched and parallelized, with SNS sitting between each segment of the pipeline for fan-out capabilities, which is useful for things like S3 archiving. I’m also using AWS Firehose quite a bit. The tool used to manage and deploy functions is apex.

My primary database of choice is Postgres (RDS) and “check” results are stored in Elasticsearch (hosted by AWS). I also use Elasticsearch & Kibana for internal logging, with some custom code for alerting which also runs in Lambda.

On the front-end the notable packages I’m using are React, D3, browserify, postcss and babel.


What are some of the reasons you decided on this stack?


The biggest motivators for me are scalability, performance, and low maintenance. The AWS Lambda pricing is currently a bit steep for I/O intensive use-cases like this, but the scalability, workflow, and maintenance aspects have been fantastic. I’ve stress tested the platform with the equivalent of 5,000 users with no issues and no additional work on my part.

I use Lambda internally for many small programs as well, which “garbage collect” Elasticsearch indexes, alert against my logging cluster, perform stats rollup to Postgres among other things.

I went with Elasticsearch for its flexibility and query performance. I believe there’s some improvements that could be made for the time-series use-case especially regarding compression, but it has been doing well so far. The JSON query language can be a bit daunting, but it’s very flexible, and Elasticsearch has some great options grading scaling, via routing keys and so on.

On the front-end I chose React, I was attracted to the functional aspect and modularity it provided. The learning curve was very low barring some old habits, otherwise it has been a great tool to work with!

Authentication and Authorization


What were some of the considerations you needed to make regarding authentication and authorization?


My primary concern is user experience. I wanted to utilize OAuth front and center to eliminate the signup process for the user. It was also important to me to have a custom look, to fit with the minimalistic design of Apex Ping.

I also really wanted to utilize JSON Web Tokens (JWT) for stateless authentication & authorization, cutting down on the amount of infrastructure required.


How did Auth0 help with this?


Auth0’s documentation is fantastic, it was easy to find an example for React & Go in order to get started right away. The provided open-source Go JWT middleware worked as-advertised.

Going with Auth0 meant I didn’t have to spend days fiddling with half-baked solutions, which is especially frustrating with new specifications such as OpenID Connect. With Auth0 I was able to just focus on building my application, instead of re-inventing auth.

"Going with Auth0 meant I didn’t have to spend days fiddling with half-baked solutions."


Tweet This


You recently published a package called auth0-lite to npm. Can you tell us about that?


The JavaScript client libraries provided by Auth0 through their CDN offer some powerful capabilities, however with my use-case being quite simple, and having a custom look, I decided to slim things down. My auth0-lite npm package is a fraction of the size with just the bare-minimum requirements for my use-case. I brought up the idea of light-weight bundle(s) with the Auth0 team and they were great and receptive to the idea!

Wrapping Up


Thanks for taking the time to chat with us about your new project, we wish you all the best with it! Is there anything else readers can check out?


Have a look at Ping's features and check out the free plan if you're interested. Keep an eye out for more Apex projects to come!

  • Twitter icon
  • LinkedIn icon
  • Faceboook icon