00:00:05.520
It has been a lot of fun! What it does is automatically scaffold out, in RAM only—not in files—models, views, controllers, and routes. This is beneficial for extending an existing application. For instance, you can create some tables, and it'll actually work. You can also take an existing database, which is what I will show today. I'll start with something you already have on hand. Let's say you're considering rewiring an existing application, maybe from a PHP project or something else, into Rails to give it some fresh blood.
00:00:30.240
We will create a new Rails 7 application called 'friendly RB.' Use PostgreSQL as the driver, and then we will not bundle yet. When building out the file set, we'll head to the friendly RB folder. Let's make it friendly by editing the gem file a little.
00:00:44.160
We will throw in that gem. This is a live coding demonstration. Everything you see today will be fresh live coding. It's all about getting this set up in size using PostgreSQL, which you can put anywhere you want.
00:01:12.600
Now that we have a starting point, we’ll bundle everything up. I have a database that I have started off with just a few tables. Does anyone remember the old Northwind database that Microsoft put together back in 1995 for Excel? We will use that as our database instead of 'friendly RB development'—it's now Northwind.
00:01:40.440
After bundling, everything is in place without doing anything else; no files have been created related to any models or anything else. However, it knows what's going on. It has inspected the database and actually works with it. When I want to see what orders look like, I can just go to Localhost slash orders.
00:02:04.360
As I was typing, it tried to find the corresponding files, intercepting site work stuff and letting it do what it does. However, if it's not there, it suggests that it has an option to solve the issue. So, it created an orders model without any foreign keys. It also made an orders controller.
00:02:42.040
As there is an absence of those files out there, that's cool, but I want the foreign keys! You can create an initializer file for Brick, and within that file, you can specify the foreign keys you would like. Given that I already have the Northwind database, it interrogated the database to find probable foreign keys I might want to use.
00:03:05.440
Scrolling down through the initializer file, it automatically built out a set of commented possible additional references—these are the foreign keys. I definitely want these, so I’ll save that change out and then rerun our Rails server.
00:03:29.200
At this point, it doesn't look a lot different yet until we open the application and refresh. Previously, it just had numerical foreign keys, which weren’t hooked up correctly. However, after the refresh, it now knows about the belongs to and has many relationships.
00:04:02.840
You can now perform full CRUD operations on various records in the database. Essentially, this creates an admin panel for free, without any files being associated. The next step is to interrogate an existing database that you care about, so by putting this against a fresh new Rails project, you can determine how everything associates.
00:04:38.960
Since Adrien invited me, I would like to give him some love. His Avo project is great! I will go ahead and include the Avo gem as well, which I think will be version 2.4 of his projects. Since Brick likes to integrate with other admin panels, it can automatically build the resource files for you.
00:05:00.040
Let’s execute 'bin rails g Avo install' to create the initializer from his project. Now, let’s run another 'bin rails s' command. Before, the orders screen looked a certain way. After refreshing, it now displays a little Avo icon, indicating that the Avo gem built out the resource files that you would normally have to scaffold manually.
00:05:43.960
Now with Avo up and running, you can quickly prototype things. I’ll show one last thing, as there is a lot more going on than what we’ve covered, and this is only scratching the surface. The great documentation we just witnessed is very helpful. I am also a proponent of good documentation, so in that spirit, we will add the R Swag UI gem.
00:06:26.800
Just adding that gem is enough for the system to understand that you likely want API endpoints documented. Once we bundle with the R Swag UI gem, it will provide hints as it starts up. We will need to put the necessary stuff in an initializer and include it in our routes.
00:06:41.640
Now that it’s started up, it provides hints to indicate that your endpoints are available. If you want to quickly establish RESTful APIs, this is the way to do it. Now, we can navigate to the API docs index, and just like that, Swagger documentation is available.
00:07:06.320
There are a lot more features, including the ability to create versioned API services based on views. If the naming convention for the views follows a specific pattern, you can easily make adjustments in one version without affecting the others. This process is simple and intuitive, so I encourage everyone to read the documentation. Thank you all very much! This has been about Brick. I hope you enjoyed the presentation.