Last summer we open sourced our platform.
But that was just the code. We're now opening up more of our operations by providing our Skylight dashboard to the community. This will help provide more context for everyone committing code to the project, and will also act as a learning opportunity for anyone who wants to peer into our operations as we grow. After all, there's always been something inherently meta about software designed for people to gather and talk about software.
Skylight provides insights into response times, slow queries, inefficient memory allocation—and overall helps us paint a picture of what's happening in the aggregate as folks use the platform.
We make heavy use of our CDN to actually serve most of our traffic without having to hit the origin server at all. You can read about that here:
But, as we add new functionality and grow, we have more and more types of requests hitting the origin one way or another. And these are the insights that we can glean from Skylight.
Here is an example of Skylight in action. On this page in particular, here is the performance impact of the sticky sidebar of this post (visible if you're on a desktop device)
This diagram shows the performance of this part of the page for fast requests. You’ll see that this area of the page is rendered 24% of the time, and when it does render, it's fairly performant. This situation is a result of fragment caching, so 76% of the time this is served as stored HTML from memory as opposed to fresh queries into the database.
On the other hand, we can learn a lot by examining what is happening when the page is slow. Part of the slowness here is because we are serving this area cold more often and performing other cold queries underneath, resulting in a pretty big performance hit.
Tuning Rails performance is a lot about efficient queries and sensible caching strategies.
Skylight is fairly intuitive, but this stuff is inherently pretty complex, so it may take some time to understand just what you're looking at. Skylight's getting started guide is a great place to start.
Some of the sloppiest code in the application is a result of looking for performance boosts here and there, so it is always going to be a matter of give and take. You can check out our open source CodeClimate for some insights into some of the parts of the codebase that need the most work in terms of technical debt and code readability.
Our project, community and codebase are all in a much better place than when we first released the code open source. We're about half a year into this particular part of the journey and we cannot wait to keep going with you. Successes and failures of the project have rarely been strictly technical in nature, but we have had some really great technical wins as well. Every time we take a step like this, it is another step towards being the open and transparent tech company that we wish more were like.
Does front-end development as a we know it still exist; or has the role evolved into something we no longer recognise? As with evolution in nature, the evolution of "front-end" has resulted in several distinct flavours --- and in my opinion --- an identity crisis.