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.
Related
I have two Rails apps in Heroku with Postgresql Databases.
Noiw i want to access those two databases with one app ony.
Is it Possible?
You can share one app database with other (with your own risk) like this. If you want multiple database connection in single rails app, you can try (with your own risk) this this
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 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.
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.
Is there a recommended practice for managing multiple testing and production database users under one Rails app? I've a Rails app with four different database users associated with it:
owner, the DB user who owns the app schemaPermissions: Just about everything. (This is the maintenance/migration account.)
app, the DB account that powers the web applicationPermissions: Read on most tables and views, write on some temporary caching tables.
writer, the DB account that feedsPermissions: Write on a few tables.
auditor, the DB account that logs DB write activityPermissions: Owns a few triggers and functions.
Right now my migration files contain GRANT/REVOKE logic for these specific, named users. However, in the "development" environment all it is often convenient for these users to all be the very same account. Additionally, the hardcoded names of these users may conflict with already-existing DB user names in the final production environment.
It sounds like you're going to need to manage 2 different database connections for each of the classes of users you've got (app/writer). This is often managed by mixing in helpers to set these up to different classes of Models that need to use them.
There's no reason you can't configure this in your development environments, but you'll get the most bang for the buck by using a Staging environment that exactly resembles your Production environment for issues like this, where you can do a final shakedown of behavior before something is pushed live.