Ask A Question

Notifications

You’re not receiving notifications from this thread.

Multitenancy with the Apartment gem Discussion

Okay, so I have Apartment working wonderfully in an app. The issue that I'm having is that Google Apps / Mail isn't able to send or receive. I'm guessing the app is intercepting traffic meant for "mail.appblah.com". I've been unable to find a recommendation as to how this should be handled, ideas?

Reply
Jeremy Christopher Bray Jeremy Christopher Bray

Hi joe, how did you go? Are you using devise for authentication? if so this might help

config.action_mailer.delivery_method = :smtp
config.action_mailer.default_url_options = { :host => "localhost:3000" }
config.action_mailer.smtp_settings = { :address => "localhost", :port => 1025 }
config.action_mailer.perform_deliveries = true
config.action_mailer.raise_delivery_errors = false

ActionMailer::Base.smtp_settings = {
:address => 'smtp.gmail.com',
:domain => 'mail.google.com',
:port => 587,
:user_name => 'your_email@gmail.com',
:password => 'your_password',
:authentication => :plain,
:enable_starttls_auto => true
}

Reply
Hello Chris Oliver,
Its a great video. I need some help regarding the same so I have the scenario with user and company. User has one company and that company has many orientations. And there are only 6 orientations possible. So i need to generate 6 sub domains with specific company. So can you please give me some brief in this scenario. 
Reply
Hi @Chris Oliver,
it's a great video as usual, but i have one question which is how to handle one-to-many or many-to-many relations between the general aka public schema and the other schemes ? 



Reply

Hi Chris,
Thanks for the wonderful video. It is really great to have this kind of detailed explanations. I have a requirement for different user set for different databases. Can you please guide me, how can I achieve that. I am using MySQL.

I apreciate your valuable time.

Thanks.

Reply

Hi @chris Oliver, just wondering if you think the Apartment Gem is still a good solution for multi tenancy?

Also if you don't necessarily require the subdomain functionality but just looking for a way to setup Account with users funcitonality is there another gem or just do it manually?

Cheers
Josh

Reply

Hey Josh,

We use Apartment for AthleteProgress. It is a great tool IF you want to have your accounts separated by subdomain with certain models scoped to the subdomain. If as you note, Accounts do not need to be on subdomains, I would just scope the user to the account and skip the complexity that Apartment can add.

Reply

Hey @joe, thanks for the response much appreciated.

Yeah I was thinking that as well so thanks for reaffirming. I think i'll head down the simpler method. :)

Cheers
Josh

Reply

checkout the acts_as_tenant gem.. Ive used it in apps where i dont need the full power of apartment or subdomains..

Extremly easy to implement aswell!

Reply

Great video, thanks Chris!

Reply

What do you think about the performance issues highlighted in the gem author's blog?

https://influitive.io/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f

I think there is a note that relates to the way rails was analysing the schemea for each tennant causing bloat in the readme, so maybe that is fixed now. But what about the postgres issues that they / heroku had issues with. Is apartment gem ok to use for > 50 users?

Reply

Looks like the gem currently has no active maintainers

https://github.com/influitive/apartment/issues/591#issuecomment-478746238

Reply

Nice find! Thanks for pointing it out. It's probably enough to sway me against using apartment.

Reply

Hi all

WARNING RE: Multiple schemas

For those implementing a multiple schema approach - where each customer / client / project etc. has their own schema, it is not without its problems. Consider this warning here - if you plan on using Heroku: https://devcenter.heroku.com/articles/heroku-postgresql#multiple-schemas . Granted, this is a problem that you will likely WANT to have (i.e. this means that your SAAS will have taken off into the stratosphere, if you have 50+ or more customer accounts), but it is a warning that is worth giving some pause for consideration.

Memory Bloat, Migration Problems
Tenancy by schema might be very good and quick for a small number of clients, but it seems like once you start scaling, you may run into troubles. Brad Robertson suggests are saying you may run into client memory bloat (because active record caches all tables in all schemas), so you'd get 500 mb memory bloat right off the bat. Robertson also cites anecdotal opinions that it's costing a lot more to house a database using the schema approach.

Source: https://influitive.io/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f

This is something that I have not looked at, at details - i don't have concrete numbers, or reasons: wondering if anyone has any thoughts on this?

(btw Chris -- thank you for your generous tutorials / time.)

Reply

Citus which is a Postgres company designed around supporting multi-tenancy always recommends using row based segregation. They've built this gem which I would highly recommend. https://github.com/citusdata/activerecord-multi-tenant

Reply

that looks great. will you be using that with jumpstarts multitennancy features?

Reply

I am seriously considering switching now. When the developers of Apartmment say don't use Apartment that is a sign lol

Reply

I just made the switch to the Citus gem.. super simple and easy to use!

Reply

Question - how are you setting the tenant? Just saving a simple session variable with the tenant name?

Reply

You can do something like this. In application_controller.rb

set_current_tenant_through_filter
before_action :set_tenant

def set_tenant
   account_id = user_signed_in? ? current_user.account_id : false
   set_current_tenant(account_id)
end
Reply

I guess I should have been clearer - I have a SSO type system with an 'enrollment' between the tenant and the user (the same user can access multiple tenants with a single login). The enrollment holds the tenant information.

My thought is to just store the tenant name in a session variable. Then I can switch the enrollment and then the app controller can switch the tenant based on the stored session.

Reply

heyheyheyheychrisheyheyheyheychristryusingthecommentsystemfromamobile

Reply

Hahaha, I noticed that the other day. It won't capitalize, I couldn't paste. SimpleMDE is not very good on mobile it seems. Might have to replace it with Trix, but we lose Markdown support. :(

Reply

Haha this is what I was talking about a while back. Can't respond on mobile.

Reply

How in the world do I create the tenant and after creation it redirects the user/account to said subdomain

Reply

Great video! I'm working on my little MVP and wondering if multitenancy is the way to go.

Is it possible to query ALL records of all tenants? Like if I had a post model, and wanted the home page to have the 'Most Liked Post'. If I don't need subdomains, is multitenancy even the best option? Could I get by on only using Devise?

Reply

Not with Apartment since they're in separate schemas. If you do row-based multitenancy you can. Check out acts_as_tenant. That's what we use for JumpstartRails.com and it's a lot more flexible and scales better.

Reply

George,

I would recommend roe based with something like acts as tenant! Apartment has its purposes but if your going to scale at any point apartment will for sure bite ya! I used to want to use apartment until I found go rails and heard horror stories lol

Reply

Hello, do you intend to do a very detailed tutorial of actes_as_tenant ?
Tank's :)

Reply

+1 to this

Reply

+1 to this too <3

Reply

its possible to use this gem without subdomain. So every tenant will have same domain but inside the logic there is scheme segregation ?

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 87,400+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.