HTTP cache 101: scaling the web

I recently gave another read at my original post “REST better: HTTP cache” and I felt compelled to write a more in-depth dive into the subject, especially since it’s one of the most popular topics in this blog; at the same time, with the advent of new technologies such as sevice workers, people jumped into the bandwagon of offline applications without, in my opinion, understanding that the HTTP cache provides some basic but extremely interesting features for offline experiences — thus, I want to shed some light on one of the most ingenious sections of the HTTP protocol.

Read on →

Local development with rkt containers

A few weeks ago I stumbled upon an interesting hackernews discussion about setting up development environments: from what I could tell it seemed like most people have been ditching Vagrant and VMs in order to move towards docker containers, through docker-compose or minikube.

Compose, to be fair, provides a painless user experience and allows you to extend your Dockerfiles to be able to run containers with specific “dev” settings, like local volumes and different commands (think node index.js vs nodemon index.js).

What if we could have a similar experience with rkt?

Read on →

SPA, isomorphic and back to the server: our journey with JS

This morning I gave a talk at the JsDay in Verona, describing how we went “back to the basics” with our latest revamp of our mobile website.

Read on →

Book review: Site Reliability Engineering

One of the longest reads I took up over the past months was the Google SRE book, after an interesting comment by Giorgio on one of my previous posts on the advantages of timeouts.

Even though the book is free available online, I decided to buy the kindle edition as I enjoy reading on the device, as it keeps me distraction-free and lets me focus on reading (more on falling in love with the kindle later on, I promise!).

Read on →

Book Review: Nine Algorithms That Changed the Future

This was highly unexpected: Nine Algorithms That Changed the Future is a hell of a book!

The premise of the book is that it might be too boring for those familiar with the industry, but it’s one of the most fascinating books I’ve read over the past few months instead: sure, some topics were really basic and you could skip some chapters as they were explaining computing fundamentals to people with no prior knowledge, but the book got me hooked regardless, as it’s able to walk you through some very interesting topics such as Quantum Computing or software that fixes itself.

Read on →

Web APIs of the Future

I generally like to think of myself as a server-side guy but, since a few years, I’ve been more and more involved with the frontend — especially since logic, and not just UI, started to become a hot-topic for the client as well (this is all thanks to Angular, y’all remember that thingy?).

So, more often than I admit, I keep an eye on the upcoming features of various browsers through their platform status pages, and I’ve decided to start sharing a bunch of the stuff you should probably be excited as well. I plan of writing a couple articles like this one on a yearly basis, as browsers evolve quickly and there’s always lots of stuff to be looking forward to.

Read on →

Benchmarking JavaScript snippets

A few days back I was playing around with lodash to figure out if some of its functions would add significant overhead as opposed to their vanilla counterparts: in doing so I discovered matcha, an amazing tool for benchmarking JS code.

Read on →

Debugging NodeJS applications from your browser

If you’ve worked with Node long enough, chances are you probably grew fed up with the lack of plug-and-play benchmarking and profiling tools in its ecosystem: well, at least for debugging, say no more!

One of the most overlooked features that landed in Node over the past year is enhanced debuggability which, coupled with Chrome’s DevTools, makes it extremely easy to debug and profile server-side JavaScript: it comes with full support of the usual suspects such as breakpoints and CPU profiles, and it’s extremely easy to setup — no external dependency, no overhead, just Chrome.

Read on →

When debugging doesn’t suck: beautiful errors

Exceptions happen everyday: the bigger (and the more distributed) the system, the higher the chances for things to go south.

Most of us already learned the lesson when we idealized architectures and they bit us back in the form of a catastrophic downtime that could have been avoided, maybe by just adding a required timeout or keeping a few best practices for distributed systems in mind: we are now better architects, who understand that failures are an option and we have to build resilient systems that embrace them and work towards mitigating their impact.

There is one thing, though, that most of us (including me) still suck at: throwing beautiful errors.

We have great infrastructures in place to log information and monitor our systems where, in theory, everything is taken care of; then the day comes when disaster, in the form of a nasty bug, strikes and we’re left trying to understand what’s going on with our software.

How many times, after fixing a bug, you find yourself saying “let’s add some more logs though”? If you’ve been as frustrated as I’ve been, I’d recommend you to read on.

Read on →

Beware of Lodash (and the cost of abstractions)

Yesterday, while profiling one of our NodeJS apps, I bumped into an interesting piece of code that seemed to take too long to run: interestingly enough, everything seemed to point to lodash’s pick function.

Read on →