5 ms·

Scaling Web Applications with HMVC

17 points by iisbum 17y ago

neovive 17y ago
As a long-time Kohana 2.x user, this article shows how promising Kohana 3 is as a framework. Once things stabalize a bit more with v3, it will be interesting to test out HMVC.
- dlib 17y ago
  I've been a follower of Kohana for a long time, it's good to see it gaining traction.
  - neovive 17y ago
    @dlib: Do you still use Kohana? We all miss the great articles you used to post on learn.kohanaphp.com.
    - dlib 17y ago
      I've been busy trying to get a college degree. Most of my projects also involve RoR and Python nowadays and I've gotten a bit out of touch with the Kohana codebase. Some real improvements have been made though. Perhaps I'll get back in to it over the summer.
- Ixiaus 17y ago
  As a long-time Kohana user and developer I think KO3's development model is flawed. Sure, there is a benefit to HMVC - but KO3's implementation of it and homogenization of classes is allowing for too much complexification rather than maintaining a simple and lucid structure. Sam's diagrams are slightly mis-leading, in KO3 there is only a conceptual delimitation between models, libraries, helpers, and controllers - they are all grouped under "classes" sharing the same namespace which is a gross way of "allowing for scalability". If anything I could agree with the homogenization of helpers and libraries - but not controllers and models!
dasil003 17y ago
To reduce the initial investment, usually it is decided that the application should designed to be one holistic piece of software containing all the required features. This represents a potential point of failure if the software becomes very popular in a short timeframe. I have painful memories of refactoring existing codebases that have not scaled well. Great, but I don't see how this pattern gives any kind of predictable scalability improvement over plain ol' MVC for arbitrary applications. In my Rails app, the bottleneck is the database—the application servers trivially scale out horizontally. In the diagram here there is a single DB creating a bottleneck as well, splitting it up is a traditional sharding problem with or without this pattern. In fact, this looks like a service oriented architecture with constraints (ie. MVC) on each service that are arbitrarily chosen rather than reflecting the true scalability profile of the application. I'm hard-pressed to understand how you could justify building a greenfield application this way.

17 points by iisbum 17y ago

As a long-time Kohana 2.x user, this article shows how promising Kohana 3 is as a framework. Once things stabalize a bit more with v3, it will be interesting to test out HMVC.

dlib 17y ago
I've been a follower of Kohana for a long time, it's good to see it gaining traction.
- neovive 17y ago
  @dlib: Do you still use Kohana? We all miss the great articles you used to post on learn.kohanaphp.com.
  - dlib 17y ago
    I've been busy trying to get a college degree. Most of my projects also involve RoR and Python nowadays and I've gotten a bit out of touch with the Kohana codebase. Some real improvements have been made though. Perhaps I'll get back in to it over the summer.
Ixiaus 17y ago
As a long-time Kohana user and developer I think KO3's development model is flawed. Sure, there is a benefit to HMVC - but KO3's implementation of it and homogenization of classes is allowing for too much complexification rather than maintaining a simple and lucid structure. Sam's diagrams are slightly mis-leading, in KO3 there is only a conceptual delimitation between models, libraries, helpers, and controllers - they are all grouped under "classes" sharing the same namespace which is a gross way of "allowing for scalability". If anything I could agree with the homogenization of helpers and libraries - but not controllers and models!

dasil003 17y ago

To reduce the initial investment, usually it is decided that the application should designed to be one holistic piece of software containing all the required features. This represents a potential point of failure if the software becomes very popular in a short timeframe. I have painful memories of refactoring existing codebases that have not scaled well. Great, but I don't see how this pattern gives any kind of predictable scalability improvement over plain ol' MVC for arbitrary applications. In my Rails app, the bottleneck is the database—the application servers trivially scale out horizontally. In the diagram here there is a single DB creating a bottleneck as well, splitting it up is a traditional sharding problem with or without this pattern. In fact, this looks like a service oriented architecture with constraints (ie. MVC) on each service that are arbitrarily chosen rather than reflecting the true scalability profile of the application. I'm hard-pressed to understand how you could justify building a greenfield application this way.