3 ms·

I don't find it to be all that surprising. I remember when Ruby on Rails was just starting to gain in popularity around the same timeframe. One of the big argum

I don't find it to be all that surprising. I remember when Ruby on Rails was just starting to gain in popularity around the same timeframe. One of the big arguments against it was that it pushed you to put all of your business logic in the application. "How will you write another application to use the same database?" they would cry. The answer turned out to be write one application tier that provides a web API to the database for all other applications to use. Interestingly, that turned out to be a pretty popular solution and is now probably the most prevailing method to get data to your user-facing applications. Looking back, it seems pretty obvious especially with the rise of mobile apps using that technology. It wasn't clear to most people in 2005, however.

raganwald 15y ago
This seems like an ongoing debate, I remember similar discussions between Java developers and DBAs before the rise of RoR. The answer back then was to migrate business logic into business logic servers, with application servers talking to the business logic serves over a queue. Architectures like that allow organizations to have heterogenous application architectures: One company had .NET for internal apps and Java for customer-facing web systems. Everything talked happily to a business logic server written in Java, and that server talked to a couple of different databases and some legacy systems, one of which was written in MUMPs.