Ruby on Rails 7

Welcome! After taking a peek at the apps we're going to build in this course, we'll help you get your development environment set up so you can start building Rails apps.

To make sure everything is up and running smoothly, we start by generating a skeleton Rails app and then get a quick lay of the land.

Rails has some strong opinions about how web apps should be designed. You've probably heard about the MVC design in the abstract, but we break it down in practice so you understand where to put your code and the benefits of a decoupled design.

Well-designed models are the foundation of any good Rails app. Active Record is the object-relational mapping library that Rails uses to connect your models to your database tables. We don’t yet have a web interface for our app, so instead we see how to create, read, update, and delete records in the database via the console.

Now that we have some events stored in the database, the next step is to display them on the index page. To do that, the model, view, and controller must all work seamlessly together.

The details about our events are looking a little sparse. So we add more attributes, which requires knowing how to manage the database schema with migrations.

The new event attributes are now displayed on the index page, but their formatting leaves a lot to be desired. We use both built-in and custom view helpers to give our app a lift and make things more reusable. We also answer the question: "Where does business logic belong?"

To give our app a consistent look and feel, all the common layout elements need to live in one definitive place. Because when it comes to the layout of your app, consistency never goes out of style.

It's always more enjoyable to work on an application that has some style and images. Adding in these assets gives us an opportunity to learn about the Rails asset pipeline.

The Rails router receives incoming requests and, depending on a set of rules, dispatches these requests to an appropriate controller action. We start by defining a route that recognizes requests to show an event's details.

In addition to being able to map requests based on defined routes, the router can also generate URLs that match these routes. We learn how to use route helper methods to generate links to navigate between pages.

Rails has a bunch of conventions to help you create robust and friendly forms with minimal code. We unveil the "magic" as we design a form for editing records, store submitted form data in the database, and display updated records.

Reinforcing what we learned about forms for editing records, we tackle creating records as we continue to implement the full range of CRUD actions using resource routes.

Crafting good Rails apps isn't just about implementing features that work as advertised. Good Rails apps also have clean, well-organized code. To that end, we learn how to use partials to structure the view layer into reusable, manageable chunks.

We finish up implementing the resource routes by deleting records. Here's the cool part: All resources follow the same routes and conventions. So at this point in the course, you can confidently build a CRUD interface for any resource!

Next up, we need to fetch a subset of events from the database and order them in a meaningful way. Thankfully, Active Record has a rich query interface that insulates us from having to write raw SQL to query our data. Master these query methods and you can slice and dice your data with ease, regardless of which database you use.

To meet a new requirement, we need to add new fields to a database table. Time for a new migration! And anytime you migrate the database, you also need to think through the ripple effects. Come along as we work through all the steps to accommodate a new migration.

To prevent bad (invalid) data from making its way into the database, we add a variety of model validations and explore how they work in detail.

With our model validations in place, we're ready to handle and display any validation errors when submitting form data. You'll come away with a solid strategy for ensuring the integrity of your application's data while providing actionable feedback in the user interface.

While on the topic of user feedback, we have a few cases where we need to flash a stylish message up on the page. It's common for web apps to flash messages between requests, and so Rails makes it easy.

Up to this point, we've been focused on one resource: events. Now we want to let folks register for events. To do that, we first create a registration resource and then start designing a one-to-many relationship between events and registrations. One of the most powerful features of Rails is the ability to easily create these types of associations. But knowing the magic incantations isn't enough. To be empowered, you also need to how what goes on behind the scenes.

Now it's time to flip over to the other side of the one-to-many association. An event has many registrations, otherwise it wouldn't be a very exciting event. This video shows you how all the dots are connected!

Registrations only make sense in the context of their associated event. To mimic that one-to-many relationship in our routes, we nest registration resources within an event resource. This is a common design technique that you'll definitely want to have in your arsenal!

How do you design a form for a one-to-many relationship so you can create child records that are associated with their parent? Answering this gives us an opportunity to apply (and reinforce) everything we've learned so far.

Once you start making associations between models and collecting data, you'll likely discover some interesting things you can do with it. For example, what does it mean for an event to be sold out? What's the average star rating for a movie? What determines if it's a cult classic? The code that answers those type of questions is part of the business logic of your domain. And knowing where to put that code is vital to designing a maintainable application.

User accounts are a central part of any web application. By learning how to design a basic account management and authentication system from scratch, you'll know exactly how it works. With that understanding, you'll have the confidence to roll your own custom solution or integrate (and troubleshoot) a third-party solution. We start by designing a solid User model that securely stores passwords using best-practice Rails conventions.

Now we're ready to design a signup form so users can create accounts and a profile page that displays their account information. To make the sign-up process more friendly, we also add a custom route.

Obviously, users also want to be able to edit their account information, and (dare we say) perhaps even delete their account. Then, with a complete UI for user accounts in place, the stage is set for authentication and other account-related features.

Now that users can create an account, the next logical step is to let them sign in. We start by designing a sign-in form.

Next, we confirm you are who you say you are by authenticating a user given their sign-in credentials.

Once authenticated, we use a session to identify the current user as they navigate from page to page.

And of course no authentication system would be complete without a way to sign out!

Now that we know whether a user is signed in or not, it's time to start restricting access to parts of the application. This process is commonly referred to as authorization. And while authorization rules vary widely depending on the nature of the application, once you understand the basic technique you can apply it as you see fit.

Only super-special users we trust should be able to perform highly-sensitive actions in our app. So we need a way to distinguish admin users from regular users, and restrict access accordingly.

With user accounts and authorization in place, we can now streamline processes within the app for currently signed in users. To do that we create our first many-to-many association which connects a user to an event using a join model and a form.

Rails has powerful conventions to help you manage many-to-many associations, but the conventions alone only take you so far. It's up to you to model the associations with the full stack in mind: from the database tables all the way through to the user interface. We look more in-depth at these details in a second many-to-many association.

In the absence of a direct relationship between two models, which is the case with many-to-many relationships, how do you efficiently traverse between them? Thankfully, Rails offers a really convenient way: through associations. They can seem a bit magically at first, but we quickly dispel any confusion.

Many-to-many associations are really common, so to continue building your confidence we design a third many-to-many. This time we use a through association in the models and a collection of checkboxes in the user interface to assign multiple categories to events and multiple genres to movies.

One approach to defining a custom query is to write a class-level method. But a more idiomatic and concise way to write a custom query is in a declarative style using the scope method. Doing so lets us slice and dice our events and movies into all sorts of interesting categories. With our scopes in place for specific criteria, it's time to show them off. We set up custom routes so that users can easily filter what they're looking for.

URLs are the user interface of the web. We browse to them, bookmark them, post them to Twitter, email them to friends, and share them in other ways. And don't forget the search engines that crawl them! As part of your app's user interface, URLs require intentional design. One common technique is to include meaningful and friendly names (rather than numeric ids) in resource URLs. We show you exactly how to do that, exploring Active Record callbacks along the way.

Putting your Rails app into production shouldn't cause fear and trembling. Deploying Rails apps has gotten a lot easier over the years thanks in large part to cloud services such as Heroku. We'll show you how to deploy your Rails app for the first time, and incrementally roll out application updates with ease!

Rails has a built-in solution for letting users upload files. Active Storage facilitates uploading files to a variety of destinations, including cloud storage services such as Amazon S3, Google Cloud Storage, or Microsoft Azure. To get things started, we set up Active Storage to store uploaded images on the local disk in development. We also go behind the scenes to see how Active Storage manages uploads using two database tables and a polymorphic association.

All the cloud-based storage services require a set of super-secret credentials to verify who we are. Here's the rub: we need a way to encrypt those credentials so we can safely deploy them along with the application code. And when the application runs in production, we need a way to decrypt the encrypted credentials so Active Storage can use them to communicate with our storage service. Thankfully, Rails has a tried-and-true way to do that.

Finally we're ready to use Active Storage to store uploaded images on Amazon S3 in production! And from there, it's pretty straightforward to store uploaded files in any supported storage service. 🥳