I am working on an Application with Rails 3 and MongoDb which will be deployed on Heroku. The application will fetch data from several APIs on the web and then perform analytics to generate meaningful insights.
However I want to have several sub-projects in this application. For example :
Project 'P1' which performs analytics for a Company C1 and with a look and feel customized (for now different text will do with same styling) for the company. This project should be accessible on p1.domain.com
Project 'P2' which performs analytics for a Company C2 and with a look and feel (for now just different text with same styling) customized for the company. This project should be accessible on p2.domain.com
Is this possible with Heroku? How should I go about it?
Andrzej is probably right. Make it one application with routes to subdomains. Check out Ryan Bates Railscast on this topic http://railscasts.com/episodes/221-subdomains-in-rails-3.
Heroku allows subdomains as well, check out https://devcenter.heroku.com/articles/custom-domains. This is also answered by #jpwynn # https://stackoverflow.com/a/4872039/1792207.
T.
Related
TL;DR:
Assets, partials, layouts, gem configurations, other code shared among apps
Different database for every app
Ability to update codebase across all apps at once, not affecting custom code on client's site
Apartment? Rails Engine? CDN?
I'd like to have certain elements (admin navbar and sidebar, devise configuration (aside from :host), as well as other bits) available on all of my client's sites. That's great and all, but I'd also like to be able to update my codebase in once, and push it out (preferably with git), to ALL of my customer's sites, to insure they have the latest code I've written.
I've been looking into creating an Engine for base functionality and creating a CDN for assets, but I'd still manually have to do any interface changes (such as adding a link in the admin navbar) by hand with every customer's project.
Can apartment solve this problem, and still allow each customer to have their own unique codebase/git repo that I use for their own website?
I know I'm not doing the best job of accurately describing my issue, so if you'd like me to clarify anything, please ask.
Any reading material would be appreciated.
EDIT: I should add I'm currently using Deis on an AWS cluster for production.
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 have an application in rails and hosted on Heroku. Now , what I want is that the application can be accessed from 2 different domains, when the application is accessed from suppose a.com it should have a specific frontend, and when accessed from b.com it should display some other frontend. The backend should be same for both.
To achieve this I suppose there is only one way I guess, which is to have two different application with same backed code, and same database(I am using PostgreSQL). I need some help on how Do I achieve this, if not, then some other alternative.
You could have only one app for both if it's easier for you. I would then suggest you configure config/routes.rb to respond differently according to the domain name.
See another answer about it here: Rails routing to handle multiple domains on single application
And the Advanced Contraints in Rails here: http://guides.rubyonrails.org/routing.html#advanced-constraints
So I am starting out on company project that will have several components:
At first...
Job list
Client profile creation and management
User administration and access (login, signup, roles, etc)
later...
Messaging
Schedule
Basic reporting
way later...
Deeper analysis and bi
I'm wondering if it makes sense for each bullet item to be its own rails project, self contained and modular (if that is indeed the case); or if it's just best for it to be in the same app. I could envision a situation where each module could operate so independently of each other that it wouldn't need the rest (except for the user funcionality) and another situation where all modules would be used together.
It seems like to me that many tasks can be handled with a lighter framework like Sinatra (and then situated physically under the rails app). It also seems like it would be a lot of overhead to have several rails apps running on a server. But I am not totally aware of all the pluses and minuses to operating each scenario.
I know this is kind of a general question that is bound to get a lot of "it depends" kind of responses (and rightfully so) I was looking for opinions/examples of how you setup this kind/your kind of project in rails. I am a quasi noob so be gentle.
Thanks in advance!
Generally speaking I would consider a website to be a suitable target for a Rails app. Each part of the app can have its own namespaces within the app, so the app has some structure internally, but they should all be one application. Consider things like sessions, where you want a user to login and use whatever features of the site you want. You want those sessions in one application without a user having to login to different sections.
Saying that, if there is complex or extended functionality that isn't part of the MVC architecture (say talking to an external API, data-mining etc), then you could offset that to a separate project and a include it as a Gem in your application. You would still have one main Rails application that includes those Gems.
You might also want to bundle together a section of your project into a reusable Rails engine that can be loaded into multiple projects. For example, Devise handles user login and management. It is a Rails engine, bundled as a Gem, that you include in your project.
Another example from Meducation (one of my sites). I'm in the process of extracting our email tracking system out into its own Rails engine as I feel its functionality sits alongside Meducation and is not a core part of it. I can then use it in other projects as well.
In your specific example, I think your requirements fit fine in one Rails application.
I have thi intranet I developped back then with PHP.
I handles multiple apps and tools (blog, link sharing, file sharing, events, clendar...), and a big user autenthication system for logging in and authorisation management.
I'd like to start re-building it with Rails.
I don't want to build one big app.
I'd like to build the site as multiple smaller apps, sharing a few common ressources like the user administration system, templates, layouts and navigation...
Rails Engine provide a way to embed an app into another.
I guess I could have a "main" app, embedding all other apps.
But I don't feel it's the right way (I may be wrong) if I have 10-15 different apps.
How would you do it ?
Thanks.
We've created applications that are split into 2 - the user facing site and an admin site. We just made 2 separate sites that have the same db and models and their own views and controllers.
This works pretty well and gives us the freedom to treat each site differently in terms of security and deployment.
I don't have any experience in going farther than that.
Check out ActiveResource - it is designed to allow you to use RESTful webservices as if they were ActiveRecord objects.
I'm working on a project now with a bunch of separate sub-apps that are pure web services (no UI). There's one "main" application that has all the UI and handles login/authentication, and then accesses the others via ActiveResource.
You can share the models between projects adding
config.autoload_paths << Dir["SHARED_MODEL_PATH/app/models/*"]
to your application.rb config file.
Or you can check the tutorials about ActiveResource such as:
http://andywaite.com/2010/12/22/activeresource-layered-rails-app
http://wholemeal.co.nz/blog/2010/03/08/active-resource-associations-and-nested-resources/
http://ofps.oreilly.com/titles/9780596521424/activeresource_id59243.html