In this article, we'll introduce Ruby on Rails' lesser-known but powerful cousin Sinatra. We'll use the framework to build a cost-of-living calculator app. By the end of the article, you'll know what Sinatra is and how to use it. Let's go!
In the first article of this series, we introduced Fastify and compared it to Express, highlighting the benefits of switching to Fastify for high-performance web applications. We also explored Fastify's plugin system in detail, showing you how to extend and customize your web applications with reusable modules. In this part, we'll dive deeper into some of Fastify's more advanced concepts.
Ecto can be considered the standard database wrapper and query generator for Elixir, enabling developers to interact with databases efficiently. However, inefficient queries or misconfigurations still can (and will) happen. Addressing these issues is crucial for a smooth user experience.
Logs are essential to any application's development. Most Ruby logs are verbose and chunky, so digging for exactly what you need can be difficult. Even though they contain useful information, you might not get as much value as you should from logs if you don't know how to use them effectively. In this article, we'll explore: Let's get started.
Node.js 12.x onwards introduced async stack traces. Async stack traces allow developers to view the call stack of asynchronous code, making it easier to trace and debug code issues. In this post, we’ll see how async stack traces work, how you can use them to debug code, and how to track them using AppSignal. Ready? Let's get going!
Absinthe is a toolkit for building a GraphQL API with Elixir. It has a declarative syntax that fits really well with Elixir’s idiomatic style. In today’s post — the first of a series on Absinthe — we will explore how you can use Absinthe to create a GraphQL API. But before we jump into Absinthe, let’s take a brief look at GraphQL.
With its strong emphasis on convention over configuration, Ruby on Rails has counteracted many architectural considerations that caused bikeshedding when building web applications. Still, one area that has continuously piqued developers' interest is how to handle business logic, i.e., code that epitomizes "what an app does." Another way to phrase this question is: Where do we put all the transactional code?
If you’ve ever looked at the Request for Comments (RFCs) around sending and receiving emails, you’ll see the technical complications involved when hitting send in your email inbox. Thankfully, many existing tools provide the Simple Mail Transfer Protocol (SMTP) service for us developers — from a Postfix server you manage to a fully scalable sending service such as SendGrid, Amazon SES, or Postmark.
To err is human. It happens all the time. If we don't account for errors on our websites, then our users will get an awful browsing experience. That's why it is better to plan for errors. In today's post, we'll go through different ways of handling errors in Preact applications. Let's get going!
