I am currently developing an Rails 3.2 web app and on this app I will allow multiple tenants. In other words, this is a SaaS service where companies can create accounts.
Each company can have multiple projects which in their turn can have multiple tasks. My simple question is. Should I add account_id to both projects AND tasks tables or will it due with only on projects table? The reason I am thinking of going with both is security.
I know I can do simple associations and it works fine but is it more "secure" to add account_id to all child tables?
I ended up using this fine gem https://github.com/ErwinM/acts_as_tenant.
Related
I want to run 2 ruby on rails apps which share users, creating one app to do it all is not an option unfortunately. So I want to have single sign on, and user data shared across them. I'm unsure as to what the best solution to this would be.
Should I run them both off the same database?
Have 2 databases with both apps using the users table in one database only?
Some other solution?
You would have to have a dedicated development rails environment to manage migrations. And have the two "apps" pointing at this database. The downside is just generating models and relationships twice for those two apps is a manual task.
A cleaner solution is to have one rails environment with migrations, models and relationships. But build an API endpoint into this environment that those two apps can call in order to use the shared database.
Our Rails suite is comprised of three independent Rails apps:
JSON API (Rails app)
Admin dashboard (Rails app)
Shared data models (Rails engine)
Both the API and Admin dashboard require the shared data models engine in their Gemfiles. All models and custom classes are stored in the engine, and both apps make heavy use of the shared components. The API lives on one Heroku server, and the Admin dashboard lives on another separate Heroku server (two separate Heroku apps). Each use their own respective Postgres databases. All three apps have their own GIT repos.
The API database stores information pertinent to our public users, and the Admin database stores mostly statistical information for admin eyes only.
A caveat of the setup is that the Admin dashboard app has direct access to the API database, and vice-versa. I understand that this is bad practice and may not seem to make sense, but there was a reason for this (mainly because the Admin dashboard needed to access all records of certain API tables, and the use of a custom API to communicate over the wire was not feasible). A similar reason exists for the API-to-Admin database communication.
This setup works for our purposes, nothing is broken, and resources are allocated efficiently. However, productivity is beginning to suffer due to the slow and uncomfortable development process. An example: a change to the API is required. Chances are that the shared models engine needs a change and therefore a feature branch is needed in both repos. After committing and pushing, the Admin dashboard now contains an old version of the models engine (is behind by one patch version). The problem lies in trying to coordinate all three Rails apps, when only one app needs a change. Another problem is migrations. Since the models engine contains two different database connections, I must create the migration once in the models engine then create it again in the appropriate app (API or Admin).
My ideal setup would involve one large Rails container app with separate engines contained within. The separate engines would be: API, Admin, Models. Also, I’m beginning to think that using only one database might make things easier. I would also like to keep the API on its own server instance, and the Admin on a separate server. The reason for this is that the API is public facing (communicates with a public iOS app) and the Admin is used mainly as a CMS and reporting engine.
I am looking for solutions and advice from experience managing similar Rails / Heroku architectures. Specific questions:
Should I attempt to combine the three Rails apps into one container
app and use the engine approach?
Should I attempt to combine the two
databases into one database?
Is it possible to have one Rails
container app, and allocate different servers to different engines?
If I should keep all apps separate, is their an easier and more
productive way to implement new features and fixes on a daily basis?
I am planning on using Devise and Apartment in my upcoming application to create subdomains for each organization that creates an account. I would like to host my application on Heroku, but ran across the following quote:
The most common use case for using multiple schemas in a database is
building a software-as-a-service application wherein each customer has
their own schema. While this technique seems compelling, we strongly
recommend against it as it has caused numerous cases of operational
problems. For instance, even a moderate number of schemas (> 50) can
severely impact the performance of Heroku’s database snapshots tool,
PG Backups.
What technique would work well with Heroku to host basecamp-style subdomains in rails 4 where many users can log in to the subdomain which they are part of?
If Heroku does not work, what other PaaS options are there that would do this well?
Domain
Firstly, you need to be sure that you're using your own custom domain for the subdomains.
Heroku's standard xxx.herokuapp.com won't be able to handle another subdomain on top of that - so you'll basically need to use your custom domain from the get-go
It will be good to reference this documentation for more information!
Multi Tenancy
Although I don't have experience with PGSQL's schemas, I do have some with multi tenancy as a whole.
There are a number of great resources here:
Basecamp-style Subdomains (by DHH)
Multitenancy Railscasts (Pro)
Apartment Gem Documenatation
Essentially, multi-tenancy is just a way to scope the data so that it's only the tenant's that you see / interact with. In the sense of the DB, the two ways to achieve this are either to use different DB's (as you would with MYSQL), or use a schema (like with PGSQL)
Whilst I can't give you a direct fix for your issue, I can help you with some ideas:
Models
One way to achieve multi-tenancy, especially with the likes of MYSQL, is to do it through the model:
How do i work with two different databases in rails with active records?
#lib/admin.rb
class Admin < ActiveRecord::Base
self.abstract_class = true
establish_connection "#{Rails.env}_admin"
end
#app/models/option.rb
Class Option < Admin
# do stuff
end
This works very well for us, although we have not got it working for scoped accounts yet. We've been thinking of setting a ##class_variable for the Account or something, but haven't been working on that right now.
This works very well for MYSQL - powered databases, but also means you'll have to create db's for every account, which will not work with PGSQL (as far as I'm aware)
PGSQL Schemas
I feel this is kind of a cheat way to do this, as all the data is still stored in 1 database - it's basically just scoped around different types of data.
The problem here is that real multi tenancy should be where you completely separate the user's data, so you could cut it out of the app completely if they wanted. From a security & access perspective, it's the most flexible & modular way.
The problem for Heroku is they can only use one database (they give everyone access to their AWS database instances), meaning they can't allow you to create 50+ free databases (it just won't work very well).
You can, of course, use your own stack to create the databases you require, but in terms of PGSQL, it's just about creating the schemas for your data & then using something like -Apartment to make it happen:
PostgreSQL works slightly differently than other databases when
creating a new tenant. If you are using PostgreSQL, Apartment by
default will set up a new schema and migrate into there. This provides
better performance, and allows Apartment to work on systems like
Heroku, which would not allow a full new database to be created.
I'm developing an enterprise web applications with rails.
I'm trying to figure out the best way of using the same models and database between 2-3 rails applications.
My project consists of different applications such as user app, customer app and admin app.
All of these 3 will use the same database and almost the same models.
I want to create 3 different rails app and deploy them to different servers.
What might be the best way of sharing the models?
Build one app that contains your models and database. Make all of the controllers return json (or xml). Make no views for this app. Then, create your other apps as so that they make http calls to the first app. This allows you to share the models/database/capabilities of the original app to as many other apps as necessary down the line. And future apps can even use their own or supplemental data stores if necessary, as they are only using the original app as a service.
One of the solutions is to write custom library or gem and put all common code in here.
In your database.yml file for your various projects, just have them point to the same database. Then use the same class names in your various projects.
You can build 4 rails apps. The datastoreapp contains the data model and controllers returns json (no views). The userapp, custapp, adminapp could do api calls to the datastoreapp for consolidated data.
We have an admin application used to manage member data and it was built in 2.1, has been running for about a year. Now that all inputs and data massage is done, our client wants to start building member site, members will have access to data the administrators have been inputting.
Here's the question, should we start a new Rails app hooked to the same admin database or should we create a new Rails app in different db with master-slave settings? The good thing about creating a new Rails app is obviously taking advantage of the new version, which we like. Or ..maybe just build the member site in the same admin app?
THanks,
Why don't you want to build the member site in the same admin app? Too much legacy?
You can use the same database but the problem is you will have to enforce any conditions you have in your models directly in your database (mandatory fields, model relationship and so on).
And I can see a lot of duplication code happening between the two apps. At least for the models. Which is really wrong :(
I don't recommend making two separate applications but It is hard to answer without looking at your app and without knowing more details.
Or build a new app using a copy of the existing database?
There's no reason the two applications cannot share the same database.
However, there's probably a number of reasons why they shouldn't. But, the only way you're going to figure those out are by going through the changelog of ActiveRecord's database adaptors.