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!
Chances are high that you've previously worked with Express, as it's been the go-to web framework for Node.js developers since its release in 2010. However, in recent years, newer web frameworks have emerged, and Express's development has slowed down significantly. Fastify is a relatively new player on the scene, but it's quickly gaining popularity due to its speed and unique features. If you're still using Express, you might wonder if it's worth switching to Fastify.
In part one of this series, we introduced Elixir test factories and fixtures. Then in part two, we explored using data generation functions. Now we'll look at some of the best Elixir libraries to use for your test data. But before we do, let's quickly discuss why test data libraries can be helpful.
Despite its many advantages, Node.js comes with a set of potential pitfalls if you don't maintain your application properly, such as: In this post, we'll explore these pitfalls and how to avoid them. Let's dive straight in!
There are many ways to load code and access file-related constants in Ruby. We can create a clear architecture by separating and handling concerns into classes and pulling in only the classes we depend on. Many full-stack frameworks like Rails and Hanami offer a built-in method to access the classes we want, as long as we stick with a certain convention. How does this work? In this post, we will explore three different options for loading code: using load, require, and autoload.
An audit log is a documented record of events and activity within an information technology system. Audit logging is critical for application owners and administrators to track activity within their systems. In this post, we'll first dive into what auditing entails and what to consider when audit logging. We'll then explore some options for implementing audit logs, including PaperTrail, Audited, AuditLog, AppSignal, and a custom implementation. Let's get started!
A well-written test suite is a big part of any successful application. But let's say you rely on an external dependency for some parts of your app (for example, an external API for fetching user information). It then becomes important to mock that dependency in the test suite to prevent external API calls during testing or to test specific behavior. Several frameworks help reduce the boilerplate and make mocking safe for Elixir tests.
Setting up authentication for your Ruby app is important to ensure it is secure. In this post, we'll explore the rodauth-omniauth gem for Ruby to implement authentication in your app via third-party providers. First, let's quickly define authentication before exploring the benefits of OmniAuth and setting up the rodauth-omniauth gem for a Rails app. Let's dive straight in!
