I am currently developing a site using Ruby on Rails. I am still a beginner who just started around a month ago. I use InstantRails on Windows 7. Here's my question.
Let's say app A is functional using MYSQL database A_development. The files such as views and controller are under folder 'A'. I now know how to, say for example, link www.app.com to this app by opening port 80 and changing some lines in the mySQL config.
In this app, you can register your username, login, and post some messages.
I now want to create some pretty identical apps say B and C. The only thing different will be the posts that shows, and the views. You can still log in with the same username, and everything is saved in the same database.
I now want the URLs to look something like A.app.com leading to app A, B.app.com leading to app B, etc. Can that be achieved? How?
I've been googling for a few days already and I'm still lost.
As I'm new to this forum, I'm not quite sure what info do you guys need. Please list and I'll provide them asap.
Any help will be appreciated! Thanks.
Seems like you have 2 (or more) issues...
On the URL front, it probably depends on what your webserver is - is it apache or something else?
In apache you could have multiple URLs point to the same web application or to different ones.
If you there are only going to be 3 or so and not much more, perhaps separate Rails apps for each one will do.
On the database front, if you point each web application at the same database, then that should achieve what you need. You probably want to a choose a transactional db to ensure updates from one app do not clash with updates from the other - eg if user has their profile window open in both apps and then saves a change to their name - which change is saved...
Given the DB is shared, you probably want to do something to ensure the related views are shared too. This goes beyond my ruby-fu - perhaps an inhouse plugin/gem would be the best route to go for that...
HTH, chris
Related
In IIS I want to deploy a sub application in a website. I really don't want to bother with having to update the root website's web.config with location tags all over the place.
Is it possible to direct the sub application to just totally ignore the root website's web.config?
Okay, so that's my question. The following is just additional information that could lead someone to offer an alternate solution I haven't thought of but if possible I hope you won't judge my post on the following since, as I mentioned, the above is my question... this is just extra information for the interested:
I am deploying several websites. Each website will have an admin application which will have the same codebase. I want the admin application to be available at site1.com/admin, site2.com/admin, etc.
In the past I did something similar on another project, but instead of having sub apps I did sub domains to another site... so it would have been like site1.admin.com, site2.admin.com, etc. Nice thing about this solution was the ease of just adding additional bindings for any new site (and the application would look at host name to apply proper theming, configuration, security, etc.). I would have preferred this solution again but it just won't work this time because we can't easily secure a proper domain name for that purpose and aside from that we would prefer the user stay on the same domain name anyway just from a marketing perspective.
So ultimately my goals are:
Have the web address be "sitename.com/admin"
Only deploy the admin application to one location
Avoid spending 2 days trying to figure out how to properly configure everything so that configs don't clash and then still end up with a
few errors I spontaneously find over the course of the next week and
eventually find one that requires me to reprogram a large section of
code in order to play nicely with the root website. (If you can't
tell, I may have minor PTSD from trying something like this a couple
years back).
I mean, what would be really super is if I could have admin be its own web application and have bindings like "site1.com/admin" and "site2.com/admin" but obviously that's not possible. But maybe there are some other straightforward solutions I haven't thought of yet?
I'm building a report app in Rails for a current desktop app. The app is kind of pos/accounting.
So at the moment there are different clients with the desktop app installed at shop or office. Each one has its own mysql database.
I am now planning how to setup the server, most probably heroku.
Given that I will keep the databases for each client separated, I'm trying to understand the best path to follow.
Another thing to consider is that there will be different version of the app, i.e. restaurant, bar, shop etc.. Different versions will use the same database. I'll just need to change some controller and view. Most probably I'll handle this using namespace.
For a client(company) multiple users will have access to the app.
The solution I thought is to create a database table company and add a column company to users table.
Things that could change from a client to another:
call different images from assets such as logo
there might be custom views or even controller if a client requests some customization
use different database
domain possibly, but that's not that important wouldn't a be a big deal to use the same
Then based on user.company show a different logo or any other required image, render a view instead of another, at login connect to the proper database.
I don't know yet how to implement it, right now I'm still evaluating the best approach to follow. But this way maintenance/updates would be easy to manage even if maybe performance will be a bit lower and code harder to understand with possible customizations all together but that's acceptable.
Is this a reasonable solution or should I consider something different? Am I missing something important to consider?
I got my app ready, which rely on Ruby on Rails as backend.
Now I am going to publish another app, which has similar functionality, but different topic. like StackExchange, it has multiple sites under this big umbrella, like Stackoverflow, Superuser, Game Development etc.
I have these few approaches in mind:
Same code base, deploy to multiple Rails apps.
Same code base, handle by same Rails app, but with flagging. to identify.
How do Stackoverflow handle this kind of variation?
It will be much easier for you, initially, to have a single app handling the different sites, and to use the url to set some settings for each site, such as which data to load up, which stylesheets etc. In this way you're designing a single rails app, and can test it easily with various localhost urls which trigger the different variants etc.
If your site becomes very successful you will want to split it across multiple servers anyway. At that point, you will need to consider a strategy for doing so: you may decide that you will have one server per site, or it might be the case that one of the sites is so massively successful that you need multiple servers for that and one to handle the others, or something else. That's a nice problem to have, and you might not have it, so keep it simple for now is my advice.
EDIT - for info on how stackexchange works, go to http://blog.serverfault.com/ . Searching for "architecture" could be a good start for you.
I would like create web app like shopify.com.
User can pickup subdomain(or domain), theme and have own store.
How can I do this?
Create main application, deploy it automatically like new standalone version and update it via git?
I'm using Rails 3.
Thanks for your advice.
Based on replies:
When I choose to use only one application (without multiple instances) and give user his subdomain, it will looks like their own website. But everything will be in one database (It's good idea?). And how can I have multiple themes in Rails app?
Take a look at LocomotiveCMS, specifically the routing system. Locomotive actually hosts multiple sites inside a single rails application. It does this by inspecting the request URL when it comes in and setting the current_site variable with the site which is set up to handle the domain. Then the current_site is actually just an object which contains all the pages, contents, settings, etc. for the specific site being served up.
So to answer your question, I think a good solution is to give your rails app the ability to serve up multiple sites based on the domain. It's not that hard, and it seems less fragile to me than trying to automatically deploy new instances of an app.
So far I have understood, you want to let your users have their own subdomain, different theme but the functionality would be same right. Users just need to have a feel of something of their own.
Well definitely, you need to have a single application that supports multiple subdomains.
A quick googling gave me [ http://37signals.com/svn/posts/1512-how-to-do-basecamp-style-subdomains-in-rails ]. May be you can get some insights from here.
For example if your service is http://www.myfi.com, a brief idea can be:
When a customer is registering, you should let him choose his subdomain. And the newly created account will be associated with this subdomain with a url. Say, http://customer1.myfi.com.
You should register for domain *.myfi.com so that anyone in the world hit with anysubdomain.myfi.com, it comes in your application.
Then from the url part, you should identify the subdomain (customer1) that is being used, and need to set that in session.
Now when someone will try to login, you must verify the account in the context of that subdomain's account.
In fact, all following actions need to be handled in the context of the subdomain's account.
Just tried the gather a glimpse of the implementation here. If you have confusion about something specific, share that also.
Edit:
Whenever you are thinking about multiple theme, you must have simple design which is completely driven by css and js. The app/view files should contain only content and HTML nodes with class names or ids.
Generally a UI designer can put more helpful ideas about how to make such theming mechanism. But all I can feel is, based on the chosen theme by customer, you have to load different css and js.
Actually the strategies can be indefinitely sophisticated and scalable, but its always wise to start with something easy. Then ideas will automatically evolve into better ones.
I am trying to build a CMS I can use to host multiple sites. I know I'm going to end up reinventing the wheel a million times with this project, so I'm thinking about extending an existing open source Ruby on Rails CMS to meet my needs.
One of those needs is to be able to run multiple sites, while using only one code-base. That way, when there's an update I want to make, I can update it in one place, and the change is reflected on all of the sites. I think that this will be able to scale by running multiple instances of the application.
I think that I can use the domain/subdomain to determine which data to display. For example, someone goes to subdomain1.mysite.com and the application looks in the database for the content for subdomain1.
The problem I see is with most pre-built CMS solutions, they are only designed to host one site, including the one I want to use. So the database is structured to work with one site. However, I had the idea that I could overcome this by "creating a new database" for each site, then specifying which database to connect to based on the domain/subdomain as I mentioned above.
I'm thinking of hosting this on Heroku, so I'm wondering what my options for this might be. I'm not very familiar with Amazon S3, or Amazon SimpleDB, but I feel like there's some sort of "cloud database" that would make this solution a lot more realistic, than creating a new MySQL database for each site.
What do you think? Am I thinking about this the wrong way? What advice do you have to offer in this area?
I've worked on a Rails app like this, and the way it was done there was named-based virtual hosts, with db entries for each site running. Each record was scoped to a site if necessary (blog posts, etc.) while users would have access to all sites running out of that db. Administrator permissions could be global or scoped to one or more sites.
You're absolutely correct when you say you'll reinvent the wheel a million times during the project. Plugins will likely require hacking on top of the CMS itself.
In my situation, it ended up being a waste of almost a million dollars of company money to build that codebase to run multiple sites while still being able to cater to the whims of each client site. It worked, but was not very maintainable due to the number of site-specific hacks that subsequently entered the codebase. You may be able to make it work if you don't have to worry about catering to specific client sites running on your platform.
In the end, you're going to need a layer of indirection to handle the different sites regardless of methodology. We ended up putting it in the database itself. If you go with the different-db-for-each-site method you mentioned, you'll put that layer in your code instead. I'm not sure which one is the better method.
I hope you're able to pull this off. I failed.
Also, as I learned today, Heroku offers postgres instead of mysql for rails apps.
There's James Stewart's Theme Support Plugin for Rails 2.3, and lucasefe's themes_for_rails gem for Rails 3+.
I just started using the 2.3 version and it's working well so far.