We just released Ruby Gem 2.11. We are always making things easier to use for you, so more things work out of the box and more instrumentation and dashboarding is built without you doing any heavy lifting. This release has a big overhaul of Active Job support. The cherry on the stroopwafel cake is the automatically generated dashboard with status per queue, queue throughput and queue times. 2.11 also polishes a lot of other integrations. Let’s dive in.

We’re happy to announce a new version of AppSignal for Node.js, and support for instrumenting Apollo Server v2+. This means that we’ll save you more some time, and perform more automatic instrumentation for you.

Starting today with version 0.6.0 of the Node.js integration, instrumenting a Node.js app that uses Redis is much easier. In fact, we instrument it for you - meaning that if you use Redis in your own app, there’s no extra work for you, everything Just Works™ out of the box! 🎉

In today’s post, we’ll look at two Elixir HTTP client libraries: Mint and Finch. Finch is built on top of Mint. We’ll see the benefits offered by this abstraction layer. We’ll also talk about some of the existing HTTP client libraries in the ecosystem and discuss some of the things that make Mint and Finch different. Finally, we’ll put together a quick project that makes use of Finch to put all of our learning into action. Let’s jump right in!

In 2009 Node.js opened up a door for front-end developers to dip their toes into the world of servers without having to leave the comfort of their language. It’s almost effortless to get started with Node. You can basically copy-paste an entire HTTP server into existence and then install an ODM and you’ve got your CRUD app ready to roll! However, if we’ve learned anything from the amazing Spider-Man, it’s that with great power, comes great responsibility.

Most web apps can benefit from a background queue, often used to process error-prone or time-consuming side jobs. These background jobs can vary from sending emails, to updating caches, to performing core business logic. As any background queueing system scales the number of jobs it needs to process, the pool of workers processing those jobs needs to scale as well.

Today, we dip our toes into collecting custom metrics with a standalone agent. We’ll be taking our own Kafka brokers and using the StatsD protocol to get the metrics into AppSignal. This post is for those with some experience in using monitoring tools, and who want to take monitoring to every corner of their architecture, or want to add their own metrics to their monitoring setup.

A majority of front-end developers deal with this buzzword all the time: V8. A big part of its popularity is due to the fact that it led JavaScript to a new level of performance. Yes, V8 is very fast. But, how does it perform its magic and why is it so responsive? The official docs state that “V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Chrome and Node.js, among others”.

You can now monitor any metrics you’d like in your Node.js app with AppSignal. With custom metrics and minutely probes by your side, you’ll now have an excellent overview of your app. If you’ve ever thought “I wish we measured this specific thing so I could monitor better what is going on…”, then this feature is perfect for you.

Erlang & Elixir are ready for asynchronous work right off the bat. Generally speaking, background job systems aren’t needed as much as in other ecosystems but they still have their place for particular use cases. This post goes through a few best practices I often try to think of in advance when writing background jobs, so that I don’t hit some of the pain points that have hurt me multiple times in the past.