Is Rails right for this project?

Hi,

I'm a bit new to Rails (although, not as new to Ruby), and I'm pretty excited
about it.

Slightly before this, however, I thought I'd implement an internal app that we
could use at my company. I'm sending this mail to ask if Rails would be best
suited for this.

We run a hosting business, with some 50 clients. Each client has can have one
or more sites, which each has:
- an Apache VHost
- various email config files
- MySQL databases
- htaccess usernames
- DNS entries
- backup entries

...and so on. There are a lot more.

I've tired of keeping these in sync, so I thought to myself, I'll write a Ruby
script to pull all the info from a database, change some of it, or calculate
some more info as require, and write all of it to a whole bunch of different
files in different places.

Then, I realized, it'd be nice if there were a web frontend to all this, and,
the information somewhat naturally fits an MVC architecture. I decided to
look into using Rails.

So, my actual questions (kudos, you've read this far!) are:

Question 1:
How can I use dynamic scaffolding for all these models? Do I need a separate
controller for each one? I'm fine with the interface generated by the
dynamic scaffold, and i want to focus on the functionality and beckend before
I focus on the interface.

Question 2:
What is the correct, Rails way of generating all those files? They are in
many different places. Perhaps, I can define a view type (I.E., in addition
to HTML, XML, and JS), and then write a helper script to pipe the contents of
a bunch of into files? Or, is there a better way?

Is Rails even the best tool for something like this?

Answers, or advice of any kind, is appreciated!

-Benjamin Kudria

Slightly before this, however, I thought I'd implement an internal app that we
could use at my company. I'm sending this mail to ask if Rails would be best
suited for this.

We run a hosting business, with some 50 clients. Each client has can have one
or more sites, which each has:
- an Apache VHost
- various email config files
- MySQL databases
- htaccess usernames
- DNS entries
- backup entries

...and so on. There are a lot more.

I've tired of keeping these in sync, so I thought to myself, I'll write a Ruby
script to pull all the info from a database, change some of it, or calculate
some more info as require, and write all of it to a whole bunch of different
files in different places.

Then, I realized, it'd be nice if there were a web frontend to all this, and,
the information somewhat naturally fits an MVC architecture. I decided to
look into using Rails.

So, my actual questions (kudos, you've read this far!) are:

Question 1:
How can I use dynamic scaffolding for all these models? Do I need a separate
controller for each one? I'm fine with the interface generated by the
dynamic scaffold, and i want to focus on the functionality and beckend before
I focus on the interface.

You probably could, but I suspect you'll find that you might not want to. A lot of that information can be bundled into one page (or not) but I suspect the UI will be complicated enough that you will want to manage it yourself.

Question 2:
What is the correct, Rails way of generating all those files? They are in
many different places. Perhaps, I can define a view type (I.E., in addition
to HTML, XML, and JS), and then write a helper script to pipe the contents of
a bunch of into files? Or, is there a better way?

Capistrano might come in extremely handy here depending on how many different servers you have available and what needs to go where.

I think my approach would be to have a variety of after_save hooks that would generate a local copy of the files that a third party script could then push out to the servers as needed (ie. capistrano). Or, if it's a tremendous amount of data, perhaps have a "rebuild files" link per client that generates the files for that particular client which you can then deploy. In either case you should be able to use standard rails view templates just save the results where you want them as opposed to a .html file (ie. use render_string or whatever it's called these days).

Alternatively, you could look at converting your services (web/mail/dns/etc) to look at the database directly for the information. I looked into this awhile ago and servers like apache, dovecot (pop/imap), postfix (smtp), proftpd, and powerdns can all be configured to use a database to find the information they need. Yes, it's a central point of failure, but it removes the need to deploy files :slight_smile:

Is Rails even the best tool for something like this?

Absolutely. Just start thinking in terms of:

an customer has many domains
a domain has many dns entries
a domain has many email accounts
etc....

and work that out first... that's the fun part :slight_smile:

Good luck!

-philip

I can only echo Philip's response - Rails looks like a good way to go
for this app.

I regularly create Rails apps without a database, and frequently
without using ActiveRecord. The DB integration in Rails is nice, but
it's by no means a requirement for your Rails app to use a DB.

As Philip said, your app seems to break down nicely into a "has
many/belongs to" structure, so maybe it would be useful to manage all
your data in a database - however, even if not, you could still use
Rails to create a Web front end to a collection of Ruby ssh/sftp-type
functionality, and I think you'll find it at least as easy to do this
in Ruby as any other framework.

Once you've got your app built, you then leverage all the
non-development Rails-y goodness - Capistrano in particular makes life
very easy.

Good luck

Dave M.