How do you architect complex Rails systems [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

We have the following systems (and more) that we push/pull data from one app to another:

• Hosted CRM (InsideSales.com)
• Asterisk phone system (internal)
• Banner ad system (openx, we host)
• A lead generation system (homegrown)
• Ecommerce store (spree, we host)
• A job board (homegrown)
• A number of job site scrapes + inbound job feeds
• An email delivery system (like Mailchimp, homegrown)
• An event management system (like eventbrite, homegrown)
• A 开发者_运维问答dashboard system (lots of charts and reports pulling info from all other systems)

With Rails 3 around the corner, I really want to pursue a micro-app strategy, but I'm trying to decide if I should have the apps talk via REST HTTP API or because I control them all, should I do something like shared models in the code which simplifies but also allows for stuff to leak across boundries much easier...

I've heard 37signals has lots of small apps, I'm curious how those apps communicate with each other... Or if you have any advice from your own multi-app experience.

Thanks! I tried asking this on my blog http://rywalker.com/chaos-2010 too a while back.

---

I actually got an email response from DHH...

We use a combination of both, but we default to REST integration. The only place where we use direct database integration is with 37signals ID user database. Because it needs to be so fast. REST is much more sane. Start there, then optimize later if need be.

---

Last time I had to crazy-glue a bunch of small applications together, I used a simple REST API.

Bonus points: it allows for integration with services / apps written in other languages.

Also helps if you've got a crazy buzz-word loving manager who likes to pivot technologies without warning.

---

i had the same with a plus: I had to talk as well with some daemons that were not exactly HTTP ready. So i followed the following pattern: REST API using XML/JSON to exchange data and using memcache to exchange short messages. (you define some keys that you will update in memcache and the other piece of software, just pull memcache looking for those keys)

as security measure i added API KEY or HTTP client authentication using digital certificate.

---

Another option is AMQP messaging (via rabbitmq or other means).