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 writing tests in Rails, you should avoid repetition and have the right amount of tests to satisfy your use case. This article will introduce you to shoulda-matchers with RSpec for testing functionality in Rails. At the end of the post, you should feel confident about using shoulda-matchers in your Rails application. Let's get going!

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.

In the second post of our series covering LiteStack (an alternative way to build Rails applications entirely based on SQLite), we'll explore the database's concepts of flexible typing and type affinity. We'll not only discover how SQLite's data handling differs from other SQL databases, but also how we efficiently process and store binary data, like images, directly in a database column. Note: LiteDB is essentially SQLite, but fine-tuned for usage in Rails.

In part one of this series, we looked at some basic usages of Action Policy. Now we'll leverage Action Policy for more advanced authorization use cases. First up, let's explore applying pre-checks.