Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Design for scalability with hmvc
Upcoming SlideShare
Loading in …5
×

Design for scalability with hmvc

7,396 views
7,285 views

Published on

The ambition of web applications has only been impeded by the economies of scaling. The Hierarchical-MVC pattern enables ambitious applications to be designed without worrying about the dreaded 'S' word.

This talk will provide an overview of how to build applications that scale vertically and horizontally effortlessly when using the HMVC pattern. We will examine how the request object can provide a cost effective way to create an application of services. Then we will see how interrogation of the request object can reduce the size of the codebase across the entire application.

Published in: Technology
0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,396
On SlideShare
0
From Embeds
0
Number of Embeds
1,975
Actions
Shares
0
Downloads
197
Comments
0
Likes
14
Embeds 0
No embeds

No notes for slide
  • Introduce yourself and the talk...

  • One of the core developers since 2008
    Currently working on the 3.1 release
    (any Kohana users in the audience?)
  • Another pattern? No. Hierarchical MVC is an extension of MVC
    Solves the mixed domain usage of the MVC paradigm
    Based entirely on MVC, so easy to implement with existing knowledge
  • Traditional MVC usually does not fit the modern web app implementation
    Features add additional complexity
    Multiple features are packed into each MVC triad

  • Traditional MVC usually does not fit the modern web app implementation
    Features add additional complexity
    Multiple features are packed into each MVC triad

  • Traditional MVC usually does not fit the modern web app implementation
    Features add additional complexity
    Multiple features are packed into each MVC triad

  • Traditional MVC usually does not fit the modern web app implementation
    Features add additional complexity
    Multiple features are packed into each MVC triad

  • Controllers (and Models) become bloated - ‘fat’
    Application features become tightly coupled to controller code
    Increasingly harder to scale as features grow
  • Hierarchical MVC is an architecture of multiple MVC instances - or ‘triads’
    Each triad is accessed exclusively through the controller
    Ensures application logic is enclosed within domain specific triads
  • Hierarchical MVC is an architecture of multiple MVC instances - or ‘triads’
    Each triad is accessed exclusively through the controller
    Ensures application logic is enclosed within domain specific triads
  • Hierarchical MVC is an architecture of multiple MVC instances - or ‘triads’
    Each triad is accessed exclusively through the controller
    Ensures application logic is enclosed within domain specific triads
  • Hierarchical MVC is an architecture of multiple MVC instances - or ‘triads’
    Each triad is accessed exclusively through the controller
    Ensures application logic is enclosed within domain specific triads
  • Hierarchical MVC is an architecture of multiple MVC instances - or ‘triads’
    Each triad is accessed exclusively through the controller
    Ensures application logic is enclosed within domain specific triads
  • Hierarchical MVC is an architecture of multiple MVC instances - or ‘triads’
    Each triad is accessed exclusively through the controller
    Ensures application logic is enclosed within domain specific triads
  • So where did HMVC come from? You may be surprised..!
  • First reference to HMVC in Javaworld - July 2000
    Article described how to structure Java based GUI interfaces
    Creates a solid separation between presentation and application logic
  • Although the context is different, the themes apply to web application
    HMVC does encourage logical separation of domain specific code
    However...
  • A reader letter to the editor pointed out HMVC is actually an implementation of PAC,
    Presentation-Abstraction-Control
    PAC as a design pattern dates back to 1970’s
  • So Hierarchical-MVC is approximately equal to PAC! Done. I can go home.
    Not the whole story...
  • In February this year I published an article on HMVC
    A reader [correctly] pointed out that HMVC is remarkably similar to Service-Orientated-Architecture
  • When you look at the definition of SOA, it has many similarities with HMVC
    Applications built out of reusable components separated into distinct units
    HMVC triads are effectively services...
  • Diagram I included in the TechPortal article is actually incorrect
    Each HMVC triad should be able to operate independently
    Each triad is certainly a service
    Therefore HMVC is an implementation of SOA
  • Diagram I included in the TechPortal article is actually incorrect
    Each HMVC triad should be able to operate independently
    Each triad is certainly a service
    Therefore HMVC is an implementation of SOA
  • So HMVC is approximately equal to Presentation-Abstraction-Control and Service-Orientated-Architecture...
  • So HMVC is approximately equal to Presentation-Abstraction-Control and Service-Orientated-Architecture...
  • So HMVC is approximately equal to Presentation-Abstraction-Control and Service-Orientated-Architecture...
  • So HMVC is approximately equal to Presentation-Abstraction-Control and Service-Orientated-Architecture...
  • ... I like to think it is the glue between the two, bring SOA and PAC together coherently.
    The rest of this talk will look at using HMVC to aid designing scalable applications
    Focus on scalable architecture and scalable presentation implementation
  • (reference Lorenzo scalability talk) - My experience is scalability is a secondary consideration
    - Most apps grow in popularity exponentially. Hard to respond to until it’s too late
    - Response must be quick and decisive
  • Failure to implement a solid scalable architecture can lead to disaster
    Twitter has famously and publicly fallen victim to this
  • I will demonstrate how an SOA can be scaled relatively simply with Kohana 3
    Lets look at implementing a very common web application feature.
    Ask: Which is the most ubiquitous web app feature?
  • It is fair to say users are a pretty standard feature.
    They also present a good example as they contain many properties and methods.
  • Example of some traditional user properties and methods,
    adopting a CRUD like pattern for user models
  • An example of User instance using the traditional method - nothing revolutionary
  • User loaded using an HMVC request.
    This creates an HTTP-like request
    so what is $user?
  • Successful user request response will look like this
    [note] no password transmitted for what should be obvious reasons
    This can be wrapped into a model of course
  • If we ran these requests in parallel, which method would be faster? The top one!
    Lets investigate the reason why?
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • Traditional PHP Framework Request lifetime > Server > PHP >
    Framework Bootstrap > Request parse > Routing > Controller Execution
    Kohana does it’s best to mitigate, others don’t do so well
  • We can mitigate further by adding a cache
    This severely reduces the load time for subsequent requests.
  • If we look again at our previous comparison, with cache, which is faster? [neither]
    There is no advantage between MVC and HMVC methods.
    HTTP like interaction limits the functionality? No!
  • Tim Berners-Lee defined HTTP in 1991 from his work at Cern
    HTTP can provide a lot of functionality...
  • HTTP provides status, headers, content and verbs (methods)
    All of the functionality we need.
    How do we manage this in a scalable manner?
  • Routes are equivalent to a network patch panel, they define mapping of URI to controller actions
    Managing application requests in a single location.
  • This is the route for the applications users
    Creates a single place (bootstrap) where application functionality is defined
    Good Routing provides additional functionality
  • Reverse routing!
    Reverse routing is the generation of a route URI based on a route definition and specific parameters
  • We have parameters required for the action, username and return format
    The route provides defaults and filters
  • Creating a new URI based on the Route definition with the required parameters
    Parameters that have defaults do not need to be supplied with default definitions
  • Our application has failed
    Profiling has shown that the user operations are not scaling
    New server provisioned
  • Traditionally new servers and code require provisioning, full QA, testing - not agile!
    HMVC allows rapid deployment of new services, very little change to the code
    (show new host definition) - Creation of API’s for free
  • Traditionally new servers and code require provisioning, full QA, testing - not agile!
    HMVC allows rapid deployment of new services, very little change to the code
    (show new host definition) - Creation of API’s for free
  • Traditionally new servers and code require provisioning, full QA, testing - not agile!
    HMVC allows rapid deployment of new services, very little change to the code
    (show new host definition) - Creation of API’s for free
  • Exposing a lot of application logic, needs to be secured
    Most traditional methods are undesirable, either through complexity or performance
  • Exposing a lot of application logic, needs to be secured
    Most traditional methods are undesirable, either through complexity or performance
  • OAuth is designed to allow web services to access resources elsewhere. OAuth 1.0 is OK and could work.
    OAuth 2.0 is specifically designed for this paradigm, increasing performance
  • OAuth is designed to allow web services to access resources elsewhere. OAuth 1.0 is OK and could work.
    OAuth 2.0 is specifically designed for this paradigm, increasing performance
  • Turning attention to presentation and HMVC
    Similar to the Javaworld article, we want to handle the presentation of domain specific logic internally - scalable code management and reuse
  • A typical web site. Content, Menus and User Authentication
    Normally partials and snippets are used in construction (this is fine)
    Traditionally pulled together in a fat controller
  • HTTP request basic
  • Login authentication usually has its own endpoint within a triad
    All of the login logic is kept within this domain
    Final view is handled here as well
  • Full HTML5 version of a login page
  • On other pages, we want to use the same logic within other contexts
    many methods for pulling login box (GET parameters etc)
    We can use HTTP headers

  • Controller code to generate a request
  • HTTP request with login style header
  • Controller code to handle request and return correct view
    Keeps all login business logic within the authentication domain
    far easier to maintain



  • ×