Thank you for your response! You are right in that single database is the easiest and most natural form of application. I think people reach for services way too early so don't expect an impassioned defense of SOA from me. That said, I think that multiple database is a feature that will have buy in for much the same reason SOA has buy in. Some people can't handle all their requests with a single database. For reference, this is Eileen's keynote:
https://youtu.be/8evXWvM4oXM?t=1130 Basically, think of this as SOA, but the applications are engines, and instead of communicating via HTTP, the applications communicate via method calls. On Wednesday, June 20, 2018 at 11:03:19 AM UTC-4, James Adam wrote: > > It’s an interesting idea, but I’m not sure that a lot of people will need > or even want to isolate engines into their own databases — in most cases, > I’d expect people to want to link their application models to engine models > (e.g. users to posts), which means they’d naturally sit in the same > database. > > > I think you’ll need to make a very clear use-case for separating databases > on a per-engine basis to get traction. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
