[Nitro] Nitro/Rails interoperability
rob at robmela.com
Mon Jun 11 08:16:03 EDT 2007
It's occurred to me that Nitro could have a role as release valve for
overworked Nitro applications. I'm considering taking on an assignment
where that's one of the first options I'd try -- offloading a very
simple but time consuming piece from Rails onto a separate Nitro server.
Jonathan answered the first of my questions in that area by showing me
how Og can be used with legacy tables.
Other pieces I imagine would be some adapters that let Nitro read and
write to Rails' session and request objects, and generate URIs that work
well with Rails back-ends.
I think most people would see it as a low-risk experiment to offload
certain simple tasks from Rails to Nitro. In the context of a situation
where scalability issues are a significant time drain, there is strong
incentive for applying a Nitro solution. Rails folk are already talking
about Scala and Lift. Nitro offers the advantage of leveraging
existing Ruby skills and infrastructure.
Assume a Typo blog with growing traffic requiring multiple Typo
processes. Nitro could be used to read Typo's schema and display most
pages. This is considerably easier to do than reimplementing *all* of
the Typo functionality. Since blog administration is low traffic, a
single Typo process could handle all the admin, and all or most of the
remaining typo processes could be replaced by a single Nitro process.
There are other cases where the offloaded tasks are even simpler --
e.g., a page that gathers a number of resources from elsewhere (e.g.,
retrieving several dozen images from a database ). Rails could
continue to generate the overall page, but pass image retrieval URLs to
a Nitro server
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070611/59dcef33/attachment.vcf
More information about the Nitro-general