devGaido

While we tried our best to adhere to BEM, coming up with CSS class names for a new Component was still pretty time-consuming. Add to that the time spent constantly flipping back and forth between the Component's code and its CSS and it becomes a major problem.

Even though the idea of functional/atomic CSS frameworks like Tachyons and Tailwind was pretty novel back then, we opted to use this approach to compose the brunt of our CSS directly in our code.

To be able to tweak it to our needs in regards to naming and features I was tasked with creating our own version of such an atomic CSS framework (aptly named "Atomiku").

Using Atomiku made creating new Components and their style much easier and - more importantly - much faster. But it came with a huge drawback: As we had created utility CSS classes for all kinds of scenarios this meant that our production CSS file was pretty bloated, even though we only used a fraction of the classes in our code.

To get rid of the unnecessary CSS, we decided to use PurifyCSS as a final build step. This worked great at first glance but when we inspected the resulting CSS we noticed that classes with numbers in them like "width-50" did, in fact, NOT get removed at all.

Luckily, the fix was pretty easy to implement as all I had to do was fork PurifyCSS, edit some regex (and adjust the tests for good measure) and add that fork to devGaido. From then on, only the absolutely needed CSS classes remained in the production CSS.

Driven by the promise of (future) performance benefits and the elegance of arrow functions, we tried to use function components wherever possible. This however lead to a pretty big problem: We couldn't use local state and had no access to lifecycle functions. Although this was fine for the majority of the codebase, it hurt a lot in the places where it wasn't.

In absence of React Hooks, which had yet to be invented, I didn't want to admit defeat and resort to using a Class component. So, after a lot of trial and error I came up with the following approach:

• Create a wrapper HOC that exposes state, setState(), and the lifecycle hooks
• Invoke the function component as a function inside the wrapper to get the JSX but not create another component
• Overwrite the static name() getter function to return the original component's name

For more details, check out the Medium story I wrote about this.

Throughout the app, we wanted to show images relating to the paths and lessons to spice up the visuals, but with such a large number of lessons, it would have taken ages to find all the necessary assets. Furthermore, that meant we would have needed to find and upload appropriate images when adding more lessons in the future.

Seeing that devGaido exclusively linked to external resources for its learning materials, the idea of just using the URLs of the lesson resources and letting the node server take screenshots was born. The resulting images weren't as awesome as handpicked ones obviously, but it was a great time saver and worked fine for our use case.

To keep the costs low for our MVP version, our production server was running on a "best-bang-for-your-buck" VPS, which was, realistically speaking, still pretty low-performance. This fact was backed up by our load tests which suggested that our Node.js server could only handle a moderate number of concurrent requests before breaking down. We assumed this could potentially lead to severe problems in the future if left unaddressed.

As a large portion of our server requests was retrieving the lesson and path images, the first step was to incorporate Cloudflare as a CDN to serve our static assets cached. Not only did this lessen the load immensely but it also let us drop Let's Encrypt SSL and leverage Cloudflare for this as well.

The next step was putting NGINX in front of the Node.js server as a reverse proxy. On the one hand, this worked as a "buffer" for our server, on the other hand, it enabled load balancing capabilities across multiple Node instances.

As the final step, I proposed sending over the complete curriculum data (lessons and paths) with the initial page request via server-side Redux store hydration. We already hydrated the initial Redux store with user data and authentication details anyway, so the idea wasn't too far-fetched.

While further reducing server load, this method also increased the perceived speed of the app, since there was no loading except for the initial page load.

Generating static HTML would have probably been the cleaner solution but it would have necessitated rewriting large parts of our custom server-side rendering code, so we decided to take the more time-efficient route here.

In the end, we were able to cut the number of requests our server receives by 90%, made our server sturdier, and also enabled scaling capabilities via load balancing.