5 ms·

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

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.

pavlov 9y ago
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.
- spacemanmatt 9y ago
  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?
  - pavlov 9y ago
    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.
    - spacemanmatt 9y ago
      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.
- crimsonalucard 9y ago
  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.

pavlov 9y ago

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.

spacemanmatt 9y ago
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?
- pavlov 9y ago
  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.
  - spacemanmatt 9y ago
    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.
crimsonalucard 9y ago
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.