We're happy to announce that one of the popular Node.js frameworks, Sails.js, gets the love it deserves from us. And it comes in the form of a hook that will automatically trace your application.

It means tracing your application with Recap.Dev requires no code changes at all. Just install the hook and point it to your Recap.Dev server. Why would you do that? Here's an article giving you five good reasons. Basically, it helps you understand your application and how much time various operations took while serving a particular request.

Click here to learn how to get started with Recap.Dev

We're happy to announce that Recap.Dev server 0.6.2 was released today.

Notable changes include:

• Performance and stability improvements. We fixed a couple of bugs that will make your Recap.Dev server faster and more reliable.

• Bugfixes. Fixed a notable bug where AWS Lambda timeout errors won't be reported to your Slack and a couple of smaller ones.

• Fully anonymized usage statistics tracking. To understand our users better, we added fully anonymized and GDPR-compliant usage tracking. It doesn't collect any personal, private or sensitive information. You can still opt-out and completely disable it for your Recap.Dev server by setting the DISABLE_USAGE_ANALYTICS environment variable to 'true' on your Recap.Dev server installation.

Click here to learn how to upgrade your Recap.Dev server

Whatever your application stack is, you will benefit from better observability of your system. Setting up tracing is probably one of the easiest ways of doing just that. At Recap.Dev, we strive to provide an easy way to improve application stability while providing a nice experience to our actual users - engineers of all sorts.

Let me walk you through a couple of main benefits I found while using Recap.Dev. Yes, we're using it ourselves.

Imagine you have a big backend system. It performs a lot of operations each day. Let's face the inevitable — some of them will result in an error. Some of them you can ignore, some you'll learn about too late, and some might result in a loss of important data or system downtime.

Let's talk about different kinds of operations and errors and how a tracing system helps developers with all of them.

Vercel and Netlify functions are some of the most popular solutions when it comes to the Jamstack backend.

In a survey conducted by O'Reilly in June 2019, 30% of the respondents named harder debugging, and 25% named observability to be the biggest challenges in adopting serverless technologies. In the same report, about 17% mentioned a lack of tools. It's not always easy to debug serverless applications.

If you're using Vercel or Netlify functions, it's even more challenging because there are even fewer tools available. No tracing tool supports these serverless platforms out of the box.

That's why we just released a new 1.12.0 version of the Recap.Dev JavaScript client, which exports two new wrapper functions: wrapNetlifyHandler and wrapVercelHandler. This allows tracing the Netlify Functions and the Vercel Functions serverless providers, respectively.

We just released a new recap.dev TypeScript transformer which will automatically wrap your functions and classes with the function-level tracing.

This provides a better alternative for the projects that are compiled with the TypeScript compiler or the ts-loader for Webpack, eliminating the need for Babel.

Check usage instructions here

Adding recap.dev to your application won't take more than 5 minutes.

Click here to learn how to get started with recap.dev

We just released a new 1.9.0 version of the recap.dev JavaScript client which exports a new wrapNestJsModule function. Which when used like this:

will record calls and their timings of the controllers and injectables in the NestJS module.

We're happy to announce that starting from version 1.8.2 recap.dev JavaScript client will record any MongoDB operations.

This year Apple changed the game of the desktop CPUs with their announcement of the Apple Silicon. A similar thing happened a year ago in the world of cloud computing. AWS released a new type of instance backed by their custom-built ARM processors called AWS Graviton2. They're supposed to have up to 40% better price-performance than their x86 counterparts. Another huge recent update is the introduction of Graviton2-based Amazon RDS instances. Let's run a couple of benchmarks and load-test a real-world backend application to see how good ARM servers are and how easy they are to use.

Performance#

I compared a t4g.small (ARM) instance to a t3.small (x86) EC2 instance. Currently, the on-demand hourly cost in the us-east-1 region for t3.small (x86) is $0.0208 and t4g.small (ARM) is $0.0168. The ARM-backed instance is already around 20% cheaper.

First, I ran a load-test on a fresh recap.dev setup with wrk.

It's a docker-compose template running 4 processes. A handler process puts every request into a RabbitMQ. A separate background process inserts traces in batches of 1000 into a PostgreSQL database.

I ran wrk on a t3.2xlarge instance in the same region using the following command:

It bombarded the target instance with trace requests for 5 minutes using 24 threads and 1000 HTTP connections.

This is the result I got for t4g.small (ARM) instance:

For the t3.small (x86) instance:

ARM-backed instance served 27% more requests per second 26% faster (on average).

Then I ran a couple of benchmarks from the Phoronix Test Suite.

pts/compress-7zip-1.7.1 gave 6833 MIPS on t4g.small (ARM) versus 5029 MIPS on t3.small (x86). A 35% higher result on an ARM processor.

ARM-backed server finished the pts/c-ray benchmark more than 2 times faster on average. 958 seconds for x86 versus just 458 for ARM.

I also ran a bunch of RAM speed tests from pts/ramspeed that measure memory throughput on different operations.

In short, the memory on the t4g.small equipped with a Graviton2 processor was 3 to 5 times faster.

Just looking at the performance and the instance price the conclusion is that the switch to the ARM-based instances is a no-brainer. You get more power for less money.

Compatibility#

The big question when switching processor architectures is compatibility.

I found that a lot of things were already recompiled for the ARM processors. Mainly, Docker was available as .rpm and .deb and so were most of the images (yes, they need to be built for different architectures). Docker-compose, however, wasn't. Which was a huge bummer for me. I had to jump through some hoops building several dependencies from source code to make it work. The situation will hopefully improve in the future as the ARM adoption on the servers grows, but right now you might pay more in working hours than you save by migrating.

The RDS (AWS managed RDBMS service) on Graviton2 is where I think the real win-win is. You don't have to do any setup and get all the benefits of an ARM processor on your server.

We also made sure recap.dev is easy to run on ARM processors and introduced multi-arch docker images and made pre-built ARM AMIs available on AWS.

We created the recap.dev out of our need for better tracing tools. I personally use it in both personal and professional projects. Here's an example of how I used recap.dev to fix a bug in an experimental feature in one of my personal projects.

It all started when I was routinely going through error notifications recap.dev sent to my Slack.