Systems | Development | Analytics | API | Testing

In our last post, we looked at the basics of RSpec and explored how well it works with Behavior Driven Development in Ruby. Now, we will look at specific types of RSpec tests for different parts of a Ruby on Rails application. Let's dive straight in!

Reusable UI components are user interface widgets or elements that can be used in various places in a web project. These components are typically small and created for a specific functionality. Typically, you write the code once and then import the UI components wherever needed. For example, you can create a card component that displays certain information or have a navigation bar that will appear at the top of all web pages. Such UI elements can be imported and added to your desired web page.

In this series, we have looked at the "musts" (databases) and "shoulds" (asynchronous jobs, websockets) of a web application. Now we turn to one of the "coulds" (that is nonetheless recommended for scaling businesses): caching. In particular, we mean caching HTML fragments and other snippets of data, as referred to in Rails Guides. We are not concerned with HTTP or SQL query caching. In this part, we'll see how to speed up our Rails app using LiteCache.

Primary keys are vital in the design of a relational database. They are crucial in uniquely identifying records. For example, if you have a table of users, you will need to identify each record uniquely. This is where primary keys are used. Primary keys are usually single columns that auto-increment. There might be cases where you'll need a combination of column to serve as the primary key - this is where composite primary keys become helpful.

Ruby on Rails has always been at the forefront of developer productivity, and building robust, highly interactive web applications has never been easier. Rails has been accurately described as the one-person framework. However, building your app is only half the battle. The other half is publishing it for others to use. Unfortunately, being able to deploy your application has always been an afterthought for most developers.

So far in this series, we have been exploring the capabilities of SQLite for classic HTTP request/response type usage. In this post, we will push the boundary further by also using SQLite as a Pub/Sub adapter for ActionCable, i.e., WebSockets. This is no small feat: WebSocket adapters need to handle thousands of concurrent connections performantly.

When working with money in an application, ensuring everything is accounted for is important. In this post, we will explore some common methods and best practices of handling money in your Ruby app, and see how you can use money-rails to write maintainable money-handling code. Let's get started!

When building an app, you'll probably need to handle user authentication in one form or another. In Rails applications, several pre-built libraries and gems make it a breeze to build user authentication including well-known libraries like Devise, Doorkeeper and OmniAuth. These libraries work well out of the box, but there's a caveat, as developers must follow certain configuration and design rules for each library.

In parts one and two of this series, we only dealt with the pure CRUD aspects of using SQLite as a production database. In this post, we will explore the world of queue mechanisms, using SQLite as the pub/sub adapter for ActiveJob. Let's make use of LiteJob to handle incoming webhooks in our Rails application.

There is a strong chance you’ve encountered Rails Concern if you’ve been using Rails for a while. It can be confusing to understand where it fits into your Rails application and how best to make use of it. This is what we’ll be covering in this tutorial: what Rails Concerns are, why they exist, and their use cases.