4 ms·

The article makes the implication that MVC is inherently slow. It's not, in fact it can be quite fast if you use the right framework. I'm assuming they only k

by PLejeck 13y ago

The article makes the implication that MVC is inherently slow. It's not, in fact it can be quite fast if you use the right framework. I'm assuming they only know that Rails is slow (which it can be, especially for a case where caching can't help much like in an API) and assume that's because of MVC and not because Rails is monolithic and Ruby-based. Before I used Rails, I used an MVC consisting of Mongoose + Handlebars + Express in Node.js, and I regularly had pages render in under 10ms. The biggest bottleneck was consistently the communication with MongoDB, something I had very little control over. So to conclude, stop blaming the architecture, start blaming the frameworks.

meowface 13y ago
>The biggest bottleneck was consistently the communication with MongoDB, something I had very little control over. Interesting you say that, because one of Mongo's few redeeming features is that it's supposed to be pretty fast for both reading and writing. Exactly which part was the bottleneck? Was your app more read-heavy or write-heavy?
- PLejeck 13y ago
  The problem I ran into was that I needed to perform roughly 20 interdependent queries in a short period of time. At most, I could do 5 queries in parallel due to the interdependent nature, but I still ran into trouble with the database being slow. In the end, I added Redis as a caching layer, which cut time-per-query down a few ms per request, which was significant in this case. I can only imagine how bad it could've been if I had block for each request instead of using the asynchronicity of node.
  - meowface 13y ago
    Right, caching is usually the easiest way to solve problems in those situations. >I can only imagine how bad it could've been if I had block for each request instead of using the asynchronicity of node. All modern web servers/frameworks are going to be asynchronous in one way or another, whether they spawn a new thread or process for each request (and for each database query), or whether they use polling and an event loop like Node. Node and HTTP servers like it are only a boon when you expect to have so many concurrent requests that threads/processes will begin to hog too many resources. So unless your server was really being hammered with queries for hundreds or thousands of concurrent users every second, I imagine using Node was neither a significant advantage or disadvantage. And if it's the database or database driver that can't handle concurrency, then Node would do absolutely nothing to help there.
twic 13y ago
Yeah. I boggled a bit at: "Still when one took the MVC approach and is now lacking an API, the easiest thing to do is to add a few views that output JSON and call it a “restful API”. [...] it does not scale and is horribly slow" Why would rendering a view be any slower than serialising some objects to JSON or whatever? The only reason i can think of is that you've incompetently chosen to use some very slow rendering framework. So don't do that.

by PLejeck 13y ago

meowface 13y ago

>The biggest bottleneck was consistently the communication with MongoDB, something I had very little control over. Interesting you say that, because one of Mongo's few redeeming features is that it's supposed to be pretty fast for both reading and writing. Exactly which part was the bottleneck? Was your app more read-heavy or write-heavy?

PLejeck 13y ago
The problem I ran into was that I needed to perform roughly 20 interdependent queries in a short period of time. At most, I could do 5 queries in parallel due to the interdependent nature, but I still ran into trouble with the database being slow. In the end, I added Redis as a caching layer, which cut time-per-query down a few ms per request, which was significant in this case. I can only imagine how bad it could've been if I had block for each request instead of using the asynchronicity of node.
- meowface 13y ago
  Right, caching is usually the easiest way to solve problems in those situations. >I can only imagine how bad it could've been if I had block for each request instead of using the asynchronicity of node. All modern web servers/frameworks are going to be asynchronous in one way or another, whether they spawn a new thread or process for each request (and for each database query), or whether they use polling and an event loop like Node. Node and HTTP servers like it are only a boon when you expect to have so many concurrent requests that threads/processes will begin to hog too many resources. So unless your server was really being hammered with queries for hundreds or thousands of concurrent users every second, I imagine using Node was neither a significant advantage or disadvantage. And if it's the database or database driver that can't handle concurrency, then Node would do absolutely nothing to help there.

twic 13y ago

Yeah. I boggled a bit at: "Still when one took the MVC approach and is now lacking an API, the easiest thing to do is to add a few views that output JSON and call it a “restful API”. [...] it does not scale and is horribly slow" Why would rendering a view be any slower than serialising some objects to JSON or whatever? The only reason i can think of is that you've incompetently chosen to use some very slow rendering framework. So don't do that.