Matt Welke

Sorry about that, never realized you posted.

Rails is usually about relying on opinionated libraries that act as ActiveRecord adapters. We have that for SQL and MongoDB and actually a few others too (I know of Dynamoid for AWS DynamoDB). You could try finding one for Firebase. I know you say you found one that seemed to lack good documentation, so perhaps you've already exhausted this option.

If you can't find one, another good option which is a bit lower level but still convenient is to have your model class inherit from ActiveModel and then add the needed methods to satisfy the ActiveModel interface. You'd provide methods for getting it by id, saving, etc. This would mean using the official Ruby gem for Firebase, or if one isn't available, use a gem like HTTParty to interact with its REST API. Then you can use it in your controllers and views as you would any ActiveRecord model. Because Firebase is a document database, using it will be very similar to using Mongo.

However, if you go this route, you won't have associations handled for you so you'll have to make navigation methods between your Firebase ActiveModels like I made between ActiveRecord and Mongoid in my example repo.

Because this method is so flexible, and it would work with any persistence layer, you should be able to find example tutorials online for making your own ActiveModels.

Just thought I'd share these two blog posts I found pretty useful when I looked for more detail on web tokens vs. cookies:

https://auth0.com/blog/angu...
https://auth0.com/blog/ten-...

Node.js is pretty nice. I use it a lot at work. It's designed for non-blocking operations from the ground up, so where in Rails you'd have to use threads or concurrency libraries to speed things up, in Node.js that's just how it is.

I think it's worth knowing more than one technology stack, and I'd recommend learning Node.js when you can. If you're interested in web frameworks for it, there's Express but there's also its successor, Koa, which is designed very modular (opposite of Rails, throwing in everything).

Gotcha.

Thanks for clearing it up. :)

Any idea why I wasn't able to run in production doing this? Do you think there are any quirks we need to be aware of when using gems like this?

I'm just getting into this basic Rails stuff now that I have time to, and a problem I encountered while following this episode was how to get the Bootstrap dropdowns working.

As of the latest version of the Rails gem as of today (5.1.0rc1), jQuery is no longer included by default in new Rails apps. Because Bootstrap's dropdown functionality relies on having jQuery loaded first, I couldn't get the dropdowns working without pulling in jQuery myself. In the episode, you convey the benefits of using gems to manage this, so here's my solution:

- I looked for a jQuery gem. I found "jquery-rails" which seems to be well-supported and up to date.
- I added jquery-rails to my Gemfile.
- As per their GitHub readme instructions, I added "//= require jquery" and "//= require jquery_ujs" to my application.js file, right above "//= require bootstrap".

It works! My dropdowns started working at that point.

I'm wondering what you think of the steps I took to solve this and if you had any other recommendations on how to add Bootstrap now that jQuery isn't included.

EDIT:

Unfortunately, an issue I'm encountering now is not being able to use the app in production mode. And this happens whether I do Bootstrap and jQuery or just Bootstrap like in the episode. I try to hit any route and I get "We're sorry, but something went wrong. If you are the application owner check the logs for more information.". And this is with providing a value for SECRET_KEY_BASE. Because it's in production mode, I can't see anything logged to hint at what the issue might be.

Nice intro to webpacker. I'm looking forward to how to get it all working smoothly with turbolinks. It helps big time if you want your web app to be speedy on actual mobile devices.

It's probably too new to see many examples of this implemented. But Chris's latest episode as of right now is about using Webpacker, so that might be a nice place to start. :)

I'd love to see a video describing the differences between Unicorn and Puma, and how to tweak the settings with them (process count, thread count, etc) to get the highest performance possible.

Lauro,

That's a good question. Truth is there are lots of resources out there. I've used books, Coursera courses, this site, random documentation... lots of sources as I've learned web development.

Any resources that preach an "API first" approach and show you how to use Rails in --api mode will demonstrate that loose coupling well.

If you're into books, one I can recommend is Rails, Angular, Postgres, and Bootstrap from Pragmatic Programmers:
https://pragprog.com/book/dcbang2/rails-angular-postgres-and-bootstrap-second-edition

It's about combining Rails with Angular. The first edition of the book uses AngularJS, and the second edition of the book (which is not yet published) uses Angular. They both use Postgres as the database and include styling with Bootstrap. It's very comprehensive.

One note is that it doesn't do the 100% separated back end and front end approach. It's not completely loosely-coupled. The author argues that the book fills a niche of helping Rails devs add Angular to their apps. I still found it nice to read to help me get going with Angular. By having it a little bit coupled together, you save some effort since Rails can do a lot for you.

If you do decide to go the completely loosely coupled way (no views in your Rails app, no ERB, --api mode, non-devise auth), then the JWT and "let's make an API" series Chris did on this site will help you out big time. Your goal at that point is to design a Rails app that connects to the database and serves up JSON data from its endpoints, and a front end app that doesn't care where it gets its data from, and glue them together with your knowledge of how HTTP works.

At work, we created a webapp that used React for its front end. The back end was a separate app acting as a web service. We didn't use Rails though, we used Koa (a Node.js web framework).

If you need React routing, I feel like it would be difficult to mix Rails routing and server-generated views with React routing and how React does views. I would design your app so that React had complete dominion over the front end and use Rails as a separate back end app.

Given that you've completed Grider's course on React with Redux, you probably have a pretty good understanding of React by now and you may end up being really happy with what you can do with an SPA design pattern.

Having your front end and back end decoupled like that is also great in that you can upgrade to future versions of Rails or switch to different frameworks entirely for your back end app and it will still be compatible with your front end app as long as you stick to the API you created between them.

Impeccable timing. I'm building an Android app with a Rails API as its back end. And just when I'm thinking "hmm I wonder how to handle authentication with APIs" in your video you say "we'll dive in talk about things like authentication... etc". :)

No problem. I think the only work they have done getting ActiveModel and Mongoid to play nice together is make sure the generators don't interfere with each other. I wasn't able to find any officially documented method of creating associations between models in different databases. And that's fair in my opinion. They're separate things, so I don't expect them to officially support each other. The method I describe above is my attempt at hacking something together.

If anybody can think of any pitfalls I might encounter and has any advice, I'd be happy to hear it!

This is an area I've studied a lot lately, because I have an interest in using NoSQL instead of SQL databases for some of my models. Since we're on Rails 5 and Mongoid 6 now, I just thought I'd share these steps for setting it up now:

1) Create your Rails app with the '--skip-active-record' switch.

2) Remove sqlite3 from your Gemfile, add Mongoid to your Gemfile, and run 'bundle'.

3) Run 'rails g mongoid:config'.

4) Check your 'application.rb' file and make sure that inside the 'class Application' there is the line " Mongoid.load! './config/mongoid.yml' ". It's sometimes not included when the config is generated, but it's needed to use Mongoid.

5) Mongoid is ready to go. The Rails generators for 'model', 'scaffold' etc have been overridden by Mongoid. Any models, scaffolds etc that you create will create classes that include the Mongoid::Document module instead of inheriting from ApplicationRecord in the models folder.

-----

And something I've also found useful is using both ActiveRecord and Mongoid. MongoDB works great for some types of data, but sometimes I still feel more comfortable with SQL for some data, especially if I feel the need to wrap it in transactions.

1) Create your Rails app.

2) Add Mongoid to your Gemfile and run 'bundle'.

3) Run 'rails g mongoid:config'.

4) Check your 'application.rb' file and make sure that inside the 'class Application' there is the line " Mongoid.load! './config/mongoid.yml' ". It's sometimes not included when the config is generated, but it's needed to use Mongoid.

5) Mongoid is ready to go. The Rails generators for 'model', 'scaffold' etc have been overridden by Mongoid. Any models, scaffolds etc that you create will create
classes that include the Mongoid::Document module instead of inheriting
from ApplicationRecord in the models folder.

6) The ActiveRecord generators are still available, you just need to specify to use the 'active_record' versions as you use them. For example, at this point 'rails g model user email' generates a Mongoid model but 'rails g active_record:model user email' generates an ActiveRecord model and creates the needed migration. If you chose to make this a Mongoid model, there is no migration to worry about. If you chose to make this an ActiveRecord model, run the migration with 'rails db:migrate'. (Rails 5 moved rake functionality into the rails command)

7) You can create associations between ActiveRecord and Mongoid models by manually coding methods. You'll need to consider foreign keys. For example, if an ActiveRecord User has many Mongoid Posts, you'd add a foreign key field to the Post model. Its type would be Integer since ActiveRecord models use the Integer type for their id. Keep in mind that queries made from these associations can be slower because they traverse two data stores. Take things like lazy loading and the n+1 problem into consideration.

-----

An example application I created while tinkering with this is here. I created the ActiveRecord User and Mongoid Post example: https://github.com/welkie/e...

Just an FYI... the download for this episode has "138" prepended to it instead of "141".

Just an FYI... the download for this episode has "138" prepended to it instead of "140" and has "part-3" instead of "part-4".

Just an FYI... the download file for this episode has "138" prepended to it instead of "139".

Thanks

This guide is something that would have solved all my problems as I started getting into Rails development. I'll be recommending it to people getting started. Thanks for taking the time to prepare it.