It’s not a great architectural choice for most web apps though. I think the reason we’re stuck with it being the default is simply historical: the CGI script execution model, rise of PHP, etc.
The upside of an external service (even an embedded library if you want to go small, like sqlite) is that it handles the hairy persistence problem for you.
If you keep your data in memory, you may eventually want to store it somewhere so you can restart the service, reboot the machine, restore from older state, etc.
If you start managing the disk writing yourself and care about the edge cases (like ungraceful termination of your process or the os) you have quite a bit of work ahead of you. A service or library takes care of all of the right fsync calls on the right entities in the right orders for you.
Databases are fine. I don’t like the rigid idea of a stateless web application server that needs to hit the database for everything.
In my view, the web application server’s primary function is to be a smart cache that responds to HTTP requests. The developer’s goal should be to prevent most requests from having to wait on a socket to return data.
I would encourage you to consider the odds that a web app developer will write an application that caches better than a database, and why we don't see that pattern happen in practice more?
What do you mean by "the odds"? It's quite hard to write an application that doesn't cache better than the overhead involved in hitting a database on every request (building SQL queries, waiting on the socket, marshalling the result data...)
The app developer has a tremendous advantage over the database simply because she knows what the data is. Personally I find that it makes a lot of sense to think of in-memory objects and their layout first, then treat the database as a persistence solution. This was not doable in the '90s because of memory constraints, but today the cheapest cloud VM instances have more memory than what you'd get on a high-end box back then.
You asked why this doesn't happen more often in practice -- I guess there is simply a lot of inertia involved. Many popular frameworks like Rails are designed around the broken stateless model and can't be reset easily. There are also large platform vendors who benefit from the low-performance solution: companies like Heroku are very happy to pretend that scaling means buying more crappy stateless server instances from them.
The odds are low. The premise that you will write a write-through cache that is faster and less buggy than say, PostgreSQL, is one I would bet my enterprise against. It is foolhardy to dismiss the labor-years invested in databases.
Dude what is the point of state if it isn't persistent? You get non-persistent memory in your web application as a GIVEN. It's part of the language, just declare a variable.
This is the ideal architectural choice for web application architecture. It allows for multithreading and multiprocessing in your web application without the need to reason about state across threads and processes in the web application. This is why developing CRUD apps are so easy, the database abstracts all the race condition problems that could potentially occur away from you so you don't have to think about it.
What’s the point of multithreading if your app is going to spend 99% of its time waiting for data to arrive over a socket?
For most web applications it’s a terrible architecture if you need any kind of performance. The real advantage is that there is a huge amount of investment made in supporting this type of app servers, so you can build on something like Rails.
>What’s the point of multithreading if your app is going to spend 99% of its time waiting for data to arrive over a socket?
What's the point of building an app if this is what it's doing. Obviously this is not the case for the majority of web services. The minimum viable requirement for a robust website is that it can serve requests without blocking itself. You don't get this with a single threaded process.
The reactor model popularized by nodejs and nginx is the alternative exception to the concurrency model of traditional servers. At best the only type of memory you can use the app itself for is caching.
I think databases are a great architectural choice for just about anything. It makes persistence and querying of complex data essentially a solved problem, especially considering "most" web apps have their foundations in some CRUD-flavored thing.
Please note when I say stateless, I mean the state does not persist across requests to the server. Within the time delta of serving the request the server is, of course, stateful.
