Chris Oliver

Oh the good old Joomla days! I tried to experiment with that and Drupal a bit and never could quite wrap my head around them.

You guys should both check out ActiveResource sometime btw. It's like the best API implementation you can get between Rails apps because of how seamless it ends up being. That's one that I always wished had turned into more of a thing, but at the very least it can make for a fanastic influence for the way you design your API clients.

This API thing actually came up recently with GoRails because as I was building Hatch I was like man, it'd sure be nice if you were automatically signed in because you were logged into your GoRails account...I never did end up doing anything with it, but it's certainly something I would like to address in the future. It would be similar to what Alan needs to do.

That's where I got the snippet from actually. Forgot to paste the link. :)

Your nginx config is probably not pointing to the right directory or something for the Rails app or you just needed to restart nginx after you changed the config.

It says "Killed" on the last line which means your server ran out of memory while installing gems. You can just try redeploying and that should help, but you'll keep having this problem until you upgrade to have a bit more RAM.

There are a bunch of ways you could tackle this. One of the neater ones is actually with ActiveResource where you can treat a remote Rails app as if it were in the database (for the most part). It got extracted to its own gem that still seems maintained. It's pretty slick if you use it, but you gotta follow the Rails conventions which not everyone wants to do.

Another option could be building 3 separate Rails apps that all use the same database server and database. Each one could then point to that and consume it as if they were inside the same Rails app. You would share your model files across the apps migrations would be accessible to each one of them. Basically for this you'd just simply share the model files and the database.yml between apps. That's about it. This is probably the easiest option, but you'll have to be aware of some of the annoyances of copying over validations for a model into every app. You could of course extract the models to a gem you share and require that gem in each app as well. Or as a git submodule so you wouldn't have to mess with gem updates.

And of course, the custom API for this is the last option. You'd hit that API from your apps instead of the database. It could be the sole place connected to the db to control any changes and the other apps could consume content from it. They might have their own ancillary databases to store extra stuff in that the others would never need. This one is probably the most work of them all, but could give you the most flexibility between them all.

The good thing is you can definitely start easy here with 3 separate apps that connect to the same db and as you grow migrate your way into an additional API service if you want. I would definitely start simple with this at first and start expanding it as you need.

Yeah, good ol' CORS. You can add rack-cors to your gemfile and create this initializer to take care of it:

# config/initializers/cors.rb
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'

    resource '/assets/*',
      headers: :any,
      methods: [:get]
  end
end

Basically what's happening is you're including now your stylesheets from a different domain (cloudfront's domain, not yours anymore) and the browser won't allow it unless you tell it that it's okay.

Yeah, you could do that, but also coffeescript does much more than adding classes to Javascript. It added a lot of other things that ES6 has now come to include (like finally a decent way for string interpolation) so ES6 what people will generally be using these days over coffeescript anytime. Mind you this video is 2 years old.

I've been meaning to do a screencast on this at some point.

This tutorial is pretty good for walking through all the steps needed to setup Cloudfront: https://www.happybearsoftware.com/use-cloudfront-and-the-rails-asset-pipeline-to-speed-up-your-app.html

For the most part it's super easy with Rails since all you need to really change is the asset_host config option. Rails will still serve up assets so that Cloudfront will always get the latest copy. It works really well.

Well, the reason is because that is not supported in any browsers right now. See: https://developer.mozilla.o...

You can only use modules if you're using a transpiler like babel / webpack to convert it to code the browser can understand today.

I'm not up to speed with much of the json(b) column indexing. This talks a bit about it briefly: https://blog.codeship.com/unleash-the-power-of-storing-json-in-postgres/

Ah ha! So EAV is what that's called. I had always known about this but never know what to call it. :)

It looks like the eav_hashes gem might be worth a shot since it's been updated relatively recently. There might be a fork that's been created more recently that has some other fixes or new features with someone maintaining it.

One alternative that I'd suggest looking into is actually the json or jsonb columns in Postgres. They are similar to the serialized text columns, but they're fully queryable. It's a little different but may be worth checking out as a solution as well.

I need to read up on EAV a little bit more myself.

Do you know if there were any recent changes with times and dates in Rails 5? I think for the most part this stuff should be the same as it has been.

You'll have to check your Rails logs in production to see what the error is. There error isn't necessarily related to this code, but it could certainly be. Whatever error is in the logs will give you insight as to what's going wrong.

There's nothing special to these gems especially considering jquery-rails shipped with Rails every single release between like 3.1 and 5.0. GoRails itself uses that and the bootstrap-sass gem.

Yep, you're spot on. Basically what you did was replicate the setup from Rails 5.0 or earlier to a T. With jQuery being a dependency of the Bootstrap JS, you just include jQuery ahead of the bootstrap JS.

You don't need the jquery_ujs file because that's for handling the remote: true things which is done with the new Rails ujs that doesn't need jQuery. It doesn't really make much difference in this case, but using the new rails_ujs will be better going forward.

Until Bootstrap removes jQuery as a dependency, this is pretty much the way to go.

Hey Ernesto, yeah it sounds like the JS is running on document ready, but not turbolinks load (which is run every single time you visit another page since turbolinks fakes those second page requests).

This is the case from the example because of this code:

jQuery ->
  new Notifications

The jQuery -> is a function for saying when the document is ready, then run this code.

If you change it to this it will work on every turbolinks page:

$(document).on 'turbolinks:load', ->
  new Notifications

Hmm, hard to say. I would start by inspecting the HTML and then stepping through the JS code line by line and making sure those are working as expected. You'll figure it out pretty quickly if you break it down and find the spot that's not working like you want it.

Doh. I still got notified. It ain't done yet! :)

Awesome. I just muted this thread so next post in here I shouldn't receive an email...feel free to post a reply to test it. :)

Alrighty, it's live (and hopefully all working!).

You can find it on the left side underneath the categories. I should probably put it in a better spot, but hey, I'm no designer yet. 😜

Agreed, this is something I've been meaning to build for a long time. At this point I question whether or not I should have just used Thredded instead, but it's fairly late now. :P.

I think I'll be adding the ability for you to both subscribe and unsubscribe from threads. Since you're kind of automatically subscribed by posting in a thread, it'd be nice to unsubscribe as well.