2 ms·
This is the ideal architectural choice for web application architecture. It allows for multithreading and multiprocessing in your web application without the ne
by crimsonalucard 9y ago
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.
- pavlov 9y agoWhat’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.
- crimsonalucard 9y ago>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.