In today’s post, we’ll learn what gRPC is, when you should reach for such a tool, and some of the pros and cons of using it. After going over an introduction of gRPC, we’ll dive right into a sample application where we’ll build an Elixir backend API powered by gRPC. Let’s jump right in!
In today’s post, we will be looking into a software design pattern called Facade. When I first adopted it, it felt a little bit awkward, but the more I used it in my Rails apps, the more I started to appreciate its usefulness. More importantly, it allowed me to test my code more thoroughly, to clean out my controllers, to reduce the logic within my views and to make me think more clearly about an application’s code’s overall structure.
Elixir 1.10 was recently released, and with that release came a little-known, but very interesting feature—compiler tracing. This feature means that as the Elixir compiler is compiling your code, it can emit messages whenever certain kinds of things are compiled. This ability to know what’s going on when Elixir is compiling our code might seem simple, but it actually opens up a lot of doors for opportunities to build customized compile-time tooling for Elixir applications.
In today’s post, we’ll learn how to build a Rails app that can support multiple subdomains. Let’s assume that we have a gaming website funkygames.co and we want to support multiple subdomains such as app.funkygames.co, api.funkygames.co, and dev.funkygames.co with a single Rails application. We want to ensure that proper authentication is performed for all subdomains and that there are no duplicate routes.
Great news for all the Elixir alchemists, we’ve just released AppSignal for Elixir package version 1.12.0 which adds support for the upcoming 1.5 version of the Phoenix framework, and improves in-channel error handling. If you’re not an AppSignal user yet, make sure to check out the product tour and see how errors, performance, host metrics and triggers all come together in one tool. Phoenix 1.5 isn’t here yet, but AppSignal 1.12 is ready for it.
Today, we’re introducing a small but useful change to the Anomaly detection that configures which hosts the host triggers should listen to. Do you have a stroopwafel in your hand? Yes? Then let’s dig in.
Today, we’re bringing you an update of the performance/exceptions sample page. This update includes a number of improvements that will help you navigate and filter the available samples faster and more smoothly. We’re bringing these changes as an iteration of sample navigation improvements that we launched a while ago. We received valuable feedback from our users: the overlay made the navigation choppy instead of fluent.
When requirements change for your product, there arises a need to change not only the codebase but also the existing data that already lives in production. If you’re performing the changes locally, the whole process seems fairly simple. You test your new feature against a sparkling clean database, the test suite is green, and the feature looks great. Then you deploy, and everything goes to hell because you forgot that production was in a slightly different state.
This blog post will explain how to effectively profile your website so that you can deal with performance pain points. We’ll go through the two most used tools in Google Chrome for profiling: Imagine that you optimized your backend and everything is running smoothly. However, for some reason, the load time of your pages is still unreasonably high. Your users might be experiencing sluggish UI and long load times. This post will help you sort these issues out.
Today, we’ll dive deep into monitoring hosts. The good news is that we’ll point you to some shortcuts on how to set up host monitoring in an easy way. The bad news is that we won’t be doing any percussive maintenance on any host. To monitor hosts, you have to set a few layers in place. Doing all this by yourself would be the hard way. You may ask: “How hard could it be?”.
