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.
13. C scope fa lls short
...] the trad itional MV
“[ the contr ol of GUI
en it comes to ot handle
wh
widgets). M VC does n
elements ( of data ma nagement,
com plexities ion flows
the
gement, a nd applicat
e vent mana
[...]” “HM
VC provides a powe
rful yet easy-to-
understand layered
design methodology
for developing a com
plete presentation
layer. While MVC pro
vides an efficient
framework for devel
oping GUI
interaction, HMVC s
cales it to the entire
client tier.”
17. “SOA separates functions into
distinct units, or services, whic
h
developers make accessible
over a network in order to allo
w
users to combine and reuse
them in the production of
applications.”
http://en.wikipedia.org/wiki/Service-
oriented_architecture
18. Request
C
Request
V M
Request
C
C
Request
Request
V M
V M
C
Request
Request
V M
C C
V M V M
19. Request
C
Request
Request
V M Request
Request
C
C
Request
Request
V M
V M
Request C
Request
Request
Request
Request
V M
C C
V M V M
32. // Load an instance of sian user
$user = User::instance()
->load('sian');
// Load an instance of sian user using HMVC
$user = Request::factory('user/load/sian.json')
->execute();
33. // Load an instance of sian user
$user = User::instance() FTW
->load('sian');
// Load an instance of sian user using HMVC
$user = Request::factory('user/load/sian.json')
->execute();
34. HTTP server Handle client request
PHP initialisation PHP runs, index.php executed
Framework loads all required
Bootstrap dependencies
The server request is parsed
Request
Framework execution
producing a request object
The request is examined and
Routing matched to a registered route
The matched controller action is
invoked.
The business logic of the request
Application logic takes place here, including
loading of models and views,
gathering data and rendering the
result.
35. HTTP server Handle client request
PHP initialisation PHP runs, index.php executed
Framework loads all required
Bootstrap dependencies
The server request is parsed
Request
Framework execution
producing a request object
The request is examined and
Routing matched to a registered route
The matched controller action is
invoked.
The business logic of the request
Application logic takes place here, including
loading of models and views,
gathering data and rendering the
result.
36. HTTP server Handle client request
PHP initialisation PHP runs, index.php executed
Framework loads all required
Bootstrap dependencies
The server request is parsed
Request
Framework execution
producing a request object
The request is examined and
Routing matched to a registered route
The matched controller action is
invoked.
The business logic of the request
Application logic takes place here, including
loading of models and views,
gathering data and rendering the
result.
37. HTTP server Handle client request
PHP initialisation PHP runs, index.php executed
Framework loads all required
Bootstrap dependencies
The server request is parsed
Request
Framework execution
producing a request object
The request is examined and
Routing matched to a registered route
The matched controller action is
invoked.
The business logic of the request
Application logic takes place here, including
loading of models and views,
gathering data and rendering the
result.
38. HTTP server Handle client request
PHP initialisation PHP runs, index.php executed
Framework loads all required
Bootstrap dependencies
The server request is parsed
Request
Framework execution
producing a request object
The request is examined and
Routing matched to a registered route
The matched controller action is
invoked.
The business logic of the request
Application logic takes place here, including
loading of models and views,
gathering data and rendering the
result.
39. HTTP server Handle client request
PHP initialisation PHP runs, index.php executed
Framework loads all required
Bootstrap dependencies
The server request is parsed
Request
Framework execution
producing a request object
The request is examined and
Routing matched to a registered route
The matched controller action is
invoked.
The business logic of the request
Application logic takes place here, including
loading of models and views,
gathering data and rendering the
result.
40. // If there is no cached user
if ( ! $user = Cache::instance()
->load('sian12345'))
{
// Load an instance of sian
// user using HMVC
$user = Request::factory('user/sian')
->execute();
}
41. // If there is no cached user
if ( ! $user = Cache::instance()
->load('sian12345'))
{
// Load an instance of sian user
$user = User::instance()
->load('sian');
}
// If there is no cached user
if ( ! $user = Cache::instance()
->load('sian12345'))
{
// Load an instance of sian user using HMVC
$user = Request::factory('user/sian')
->execute();
}
48. // Create a URI for the user route
$uri = Route::get('users')
->uri(array('username' => 'sian'));
// Load the URI with a request
Request::factory($uri)
->execute();
49. // Create a URI for the user route
$uri = Route::get('users')
->uri(array('username' => 'sian'));
$uri => /user/load/
sian.json
// Load the URI with a request
Request::factory($uri)
->execute();
60. - + mysite.com +
Home Archive Blog Web board About us
Buy content
My Website
login username
Foobar
12 password *******
Register | Forget password
- “RDX Wall Art: The Making Of” iand new short documentary iand new short
isa new short
- isa new short documentary
- highlighting iand new sho documentary
- some of the pioneers highlighting iand new sho
more ...
Foobar
12
- “RDX Wall Art: The Making Of” iand new short documentary iand new short
isa new short
- isa new short documentary
- highlighting iand new sho documentary
- some of the pioneers highlighting iand new sho
more ...
64. - + mysite.com +
Home Archive Blog Web board About us
Buy content
My Website
login username
Foobar
12 password *******
Register | Forget password
- “RDX Wall Art: The Making Of” iand new short documentary iand new short
isa new short
- isa new short documentary
- highlighting iand new sho documentary
- some of the pioneers highlighting iand new sho
more ...
Foobar
12
- “RDX Wall Art: The Making Of” iand new short documentary iand new short
isa new short
- isa new short documentary
- highlighting iand new sho documentary
- some of the pioneers highlighting iand new sho
more ...
65. - + mysite.com +
Home Archive Blog Web board About us
Buy content
My Website
login username
Foobar
12 password *******
Register | Forget password
- “RDX Wall Art: The Making Of” iand new short documentary iand new short
isa new short
- isa new short documentary
- highlighting iand new sho documentary
- some of the pioneers highlighting iand new sho
more ...
Foobar
12
- “RDX Wall Art: The Making Of” iand new short documentary iand new short
isa new short
- isa new short documentary
- highlighting iand new sho documentary
- some of the pioneers highlighting iand new sho
more ...
69. // Test the request for reduced style
if ($this->request->header('X-Login-Style') === 'reduced')
{
// Return the reduced login form
$this->response->body = View::factory('login/reduced.phtml');
}
else
{
// Return the full login form
$this->response->body = View::factory('login/reduced.phtml');
}
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