Bootstrap

When my SSL cert on MaxCDN was expiring on my personal site I decided it was a good time to revamp some things. Since GitHub Services is depreciated I can no longer have #CDN cache purges automated among other things. So I decided on the following: GitHub Pages, Netlify, Let's Encrypt and Jekyll. Staying the same was Bootstrap, jQuery, Grunt & #GoogleFonts.

What's awesome about GitHub Pages is that it has a #CDN (Fastly) built-in and anytime you push to master, it purges the cache instantaneously without you have to do anything special. Netlify is magic, I highly recommend it to anyone using #StaticSiteGenerators.

For the most part, everything went smoothly. The only things I had issues with were the following:

• If you want to point www to GitHub Pages you need to rename the repo to www
• If you edit something in the _config.yml you need to restart bundle exec jekyll s or changes won't show
• I had to disable the Grunt htmlmin module. I replaced it with Jekyll layout that compresses HTML for #webperf

Last but certainly not least, I made a donation to Let's Encrypt. If you use their service consider doing it too: https://letsencrypt.org/donate/

Python Django PostgreSQL Bootstrap jQuery

Healthchecks.io is a SaaS cron monitoring service. I needed a tool to monitor my cron jobs. I was not happy with the existing options, so I wrote one. The initial goal was to get to a MVP state, and use it myself. The followup goals were to add functionality and polish the user interface, while keeping the UI and the under the hood stuff as simple and clean as possible.

Python and DJango were obvious choices as I was already familiar with them, and knew that many of Django's built-in features would come handy in this project: ORM, testing infrastructure, user authentication, templates, form handling.

On the UI side, instead of doing the trendy "React JS app talking to API endpoints" thing, I went with the traditional HTML forms, and full page reloads. I was aiming for the max simplicity. Paraphrasing Kevin from The Office, why waste time write lot JS when form submit do trick. The frontend does however use some JS, for example, to support live-updating dashboards.

The backend is also aiming for max simplicity, and I've tried to keep the number of components to the minimum. For example, a message broker or a key-value store could be handy, but so far I'm getting away with storing everything in the Postgres database.

The deployment and hosting setup is also rather primitive by today's standards. uWSGI runs the Django app, with a nginx reverse proxy in front. uWSGI and nginx are run as systemd services on bare metal servers. Traffic is proxied through Cloudflare Load Balancer, which allows for relatively easy rolling code upgrades. I use Fabric for automating server maintenance. I did use Ansible for a while but moved back to Fabric: my Ansible playbooks were slower, and I could not get used to mixing YAML and Jinja templating.

Healthchecks.io tech decisions in one word: KISS. Use boring tools that get the job done.

Working on a project recently, wanted an easy modern frontend to work with, decoupled from our backend. To get things going quickly, decided to go with React, Redux.js, redux-saga, Bootstrap.

On the backend side, Go is a personal favourite, and wanted to minimize server overheads so went with a #serverless architecture leveraging AWS Lambda, AWS CloudFormation, Amazon DynamoDB, etc.

For IDE/tooling I tend to stick to the #JetBrains tools: WebStorm / Goland.

Obviously using Git, with GitLab private repo's for managing code/issues/etc.

ReactQL is a React + GraphQL front-end starter kit. #JSX is a natural way to think about building UI, and it renders to pure #HTML in the browser and on the server, making it trivial to build server-rendered Single Page Apps. GraphQL via Apollo was chosen for the data layer; #GraphQL makes it simple to request just the data your app needs, and #Apollo takes care of communicating with your API (written in any language; doesn't have to be JavaScript!), caching, and rendering to #React.

ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.

React Helmet was chosen to handle <head> content, because it works universally, making it easy to throw back the correct <title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.

styled-components, Sass, Less and PostCSS were added to give developers a choice of whether to build styles purely in React / JavaScript, or whether to defer to a #css #preprocessor. This is especially useful for interop with UI frameworks like Bootstrap, Semantic UI, Foundation, etc - ReactQL lets you mix and match #css and renders to both a static .css file during bundling as well as generates per-page <style> tags when using #StyledComponents.

React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.

Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.