Application Architectures in Grails

Application architectures
in Grails
Peter Ledbrook
e: p.ledbrook@cacoethes.co.uk
t: @pledbrook
Wednesday, 11 September 13

Book Author
We start with our domain classes using the usual hasMany, belongsTo etc.

Book AuthorDomain
Scaffolded
BookController
Scaffolded
AuthorController
Create instant web UI with scaffolded controllers
Can be retained for administrative UI if secured by Spring Security, Shiro, etc.

Book AuthorDomain
Scaffolded
BookController
Scaffolded
AuthorController
LibraryService
LibraryController Views
Build out proper UI using controller actions and views, utilising business logic in the services
Controllers stick to HTTP management

Thank you
Some time left for questions...

Only joking

Is it always the best
architecture?
How many people are using it?

Book Author
Why do we start here?

“The database is just a
detail that you don’t need
to ﬁgure out right away”
NO DB - May 2012
Robert “Uncle Bob” Martin

Domain-driven Design
Not the same as domain classes ﬁrst
Model your domain ﬁrst without integration concerns
It’s in operation at all stages of development, not just up-front
Reminded of a problem domain related to managing meetings and attendees - focused so
hard on the DB tables that the program logic was a dog’s breakfast.

Think Physics
Friction
Gravity

from Wikmedia Commons
We can use the model to calculate useful information, such as how long it takes for a ball to
roll down a hill
The model only includes signiﬁcant complexity - ignores the rest
Formula 1 makes use of CFD because they need it at the bleeding edge

Remember: you’re
trying to solve a
business problem
You need to understand the problem domain
The model needs to reﬂect that understanding
Gradle is a great example of a rich, evolving, and useful domain model

The Life Preserver
Domain
REST
Persistence
Messaging
Events
Courtesy of Simplicity Itself
Note how persistence is treated as an integration point
Opens up novel approaches
Could use mybatis + Flyway instead of GORM for example

An example - reporting
ReportController ReportService
Jasper
High volume transactional web site, optimised for write
Everything was OK at this point

ReportController ReportService
Jasper + HTML reports with paging
Breakage!
The logic for building reports was complex
Who is responsible for the paging? The HTML generation?
Where is the state kept? The service? A domain class?

PublisherReport
HTTP
Request
Summary
Table 1
Table 2
...
Table N
It’s a command object!
Let’s try again
The logic for building the report and pagination is in the PublisherReport class

class ReportController {
def print(PublisherReport report) {
JasperRenderer.render report
}
def json(PublisherReport report) {
render report as JSON
}
...
}
The controller is now very thin
The report can support parameters for sub-reports etc.
The domain model is embodied in the command object

CQRS

C
Q
R
S
ommand
uery
esponsibility
egregation
The writes use a different model from the reads
Will be coming back to this later

What is my domain?
Domain Model
HTTP Database
? ?
Always ask yourself this question throughout life of project
And is it closer to the user’s perspective or the persistence model? Or neither?
Former argues for a model based on command objects, the latter based on domain classes.

Post content
The command model is very simple: author + post content + date

Query model much more complex
Multiple timelines
Conversation threads
Retweets

So working from your domain ﬁrst is a good thing
And remember that different contexts have potentially different views of the model, i.e. the
user/client, persistence, other system components
DDD doesn’t preclude the CRUD/service-based architecture
So what are the driving forces behind architecture beyond the model?

Rich clients
We’re not talking Warren Buffet here
Things like GMail

Once upon a time...

Flash
Pretty (but often useless - or just pretty useless)

Java
Remember applets?
Liked the approach (particularly WebStart) but not often used. The browser was a delivery
mechanism, not a platform

It’s all about the
Javascript!
AngularJS
Knockout.js
Backbone.js
Underscore.js
jQuery.js
Moustache
The browser is now a platform for rich applications
But how do these impact the Grails app?
The whole process of building a page on each request goes out the window

Google I/O 2012
Android activations to date
400 million
Apple WWDC 2012
iOS devices sold to date
365 million
Let’s not forget Firefox OS
Lots of people potentially hitting a site at any one time!
Typical Grails architecture may struggle to handle the load (OpenSessionInViewInterceptor,
transactions, GSPs, thread-per-request)

An aside
If the whole Java client thing had worked out, would
you use it for every web application you wrote?
Would you use it for Wikipedia?
Before jumping onto the whole “single-page app” bandwagon, work out whether it’s
appropriate for your app

Shared templates
HandlebarsViewResolver
or
<hbt:render template="..."/>
GSP
Not much to talk about on client architecture, but template reuse is something to think about
View resolver only makes sense if client-side templates are complete views
hbt is a ﬁctitious tag namespace representing a plugin based on Handlebars for Java

AJAX + JSON endpoints
enabler for async
Rich UIs don’t talk HTML - use JSON endpoints (aka “REST”)
Asset delivery via Resources or asset-pipeline plugins
More scope for asynchronicity, since no wait for full page update
Grails 2.3 introduces some nice features for REST

What’s the need for
SiteMesh & GSP then?
Difficult to impossible to remove these currently
Grails 3 will ﬁnally extricate them, allowing you to remove them from your project

Aside 2
Don’t be afraid to use Ruby/Node.js tooling
Grunt
Bower
Yeoman
Compass/SASS
If you go for a heavy Javascript UI, consider Ruby/Node.js tooling
Generally richer than Java-based tooling

Async
for scalability
To solve the problem of dealing with large number of concurrent requests
Without adding lots more servers

Grails Promise API
import static grails.async.Promises.*
def print(PublisherReport report) {
task {
// Expensive report creation here
}
}
...
}
We can now return Promise instances from actions
The expensive task no longer blocks the request thread, but...

Controller
Request
Thread Pool
Worker
Thread Pool
HTTP
Request
Ofﬂoad
Task
Return thread
The request threads are now free, but burden is on worker thread pool
If all worker tasks are synchronous, have we gained scalability?
In cases where just a few URLs are blocking for long(ish) periods of time, yes (kind of)
But otherwise, now bottleneck is on worker thread pool

Make efﬁcient use of
server resources
Async all the way through - Grails Promises, GPars, messaging
Remember that some things are inherently synchronous (think Fibonacci)

Grails app
ReportController
TagService PostService
Remote
access
NetFlix style model: coarse-grained, self-contained services/apps accessed from other apps
Usually via REST

Async controllers
def tagService
def postService
def home() {
tasks tags: tagService.tagsWithCount()
trends: tagService.trendingTags()
timeline: postService.timeline(
params.userId)
}
...
}
tagService and postService are both async
The model values are evaluated in parallel
This is a PromiseMap - view rendered only when all map values evaluated

Async controllers
class TagService {
def remoteTagService
def tagsWithCount() {
task {
remoteTagService.tagsWithCount()
}
}
...
}
You can also use @DelegateAsync to create async version of synchronous service
Currently not Grails’ sweet spot due to the solution’s lightweight nature...
...perhaps makes sense with Grails 3?

Rich domain model +
Promises API/GPars?
Fully async backend
A good domain model makes it easy to identify parallelisable work
No simple solutions though! Concurrency is still a tricky problem.

GPars supports
• Dataﬂow
• Communicating Sequential Processes (CSP)
• Actor model

Messaging
A common solution to concurrency and scale

MyObject TheirObject
call

MyObject TheirObject
Router
Router
message
response response
message
Headers
Body
Decoupling via messages
Encourages separation of concerns & responsibilities

MyObject OtherObject
Router
Router
message
message
response
response
Cloud
Easy to change and move objects
Scales well (think Actor model of concurrency)

Internal External
JMS
RabbitMQ
Events
Spring Integration
Apache Camel
Internal and external can be integrated
Events is a special case of messaging (which I look at next)

Spring Integration
MyController
MyService
message
DB Persister
SplitterJMS Twitter
A channel (pipe)
Message endpoint
Based on Enterprise Integration Patterns (ﬁlters & pipes)
Many options for routing and transforming messages
Logging adapters and wire tapping for debug

Spring Integration Groovy DSL
def builder = new IntegrationBuilder()
def ic = builder.doWithSpringIntegration {
messageFlow("flow") {
filter { it == "World" }
transform(inputChannel: "transformerChannel") {
"Hello " + it
}
handle { println "**** $it ****" }
}
}
ic.send "flow.inputChannel", "World"
ic.send "transformerChannel", "Earth"

Debugging
Code comprehension
Performance (kind of)

Events
Special case of messaging

Event bus - ApplicationContext
ApplicationContext
PluginService
publish
PluginUpdateService YourListener
GORM

Event bus - ApplicationContext
class PluginService {
def publish(PluginDetails info) {
...
publishEvent(new PluginUpdateEvent(...))
}
}
class PluginUpdateService implements
ApplicationListener<PluginUpdateEvent> {
def onApplicationEvent(PluginUpdateEvent e) {
...
}
}
with spring-events plugin

Immutable “mesages”
@groovy.transform.Immutable
class PluginUpdateEvent {
String name
String version
String group
...
}
Event listeners on separate threads (from thread pool)

Event bus - (grails-)events
Event bus (Reactor)
PluginService
publish
PluginUpdateService YourListener

Event bus (Reactor)
Browser
RabbitMQ (pending)
events-push plugin

class PluginService {
def publish(PluginDetails info) {
...
event "pluginUpdate", info
}
}
class PluginUpdateService {
@Selector
def pluginUpdate(PluginDetails info) {
...
}
}
with spring-events plugin

AppEvents.groovy
includes = ["push"]
doWithReactor = {
reactor("grailsReactor") {
ext "browser", ["pluginUpdate"]
}
}
In grails-app/conf
Can control which events are propagated to the browser
The “push” include sets up a

Include grailsEvents.js
window.grailsEvents = new grails.Events(baseUrl)
grailsEvents.on("pluginUpdate", function(data) {
// do something
});

A CQRS architecture
Updates
Views
Concurrency
via event bus
Store changes
Separate data stores
for queries
Why? Updates and querying often have different data requirements.
For example, Lanyrd use Redis structured data support
All read databases can be rebuilt from master events DB
CQRS designed for scale

Plugin Architectures
App
Feature
plugin 1
Feature
plugin 2
Feature
plugin 3
Events/SI/Message broker
So why use messages to interact between the plugins?

Plugin Architectures
App
Feature
plugin 1
Feature
plugin 2
Feature
plugin 3
Events/SI/Message broker
App 2
Easy to separate out into apps deployed independently

Ultimately, think about
what you need...

...don’t just go the
“standard” route
automatically

Thank you

Application Architectures in Grails

Recommended

More Related Content

What's hot (19)

Viewers also liked (20)

Similar to Application Architectures in Grails (20)

More from Peter Ledbrook (11)

Recently uploaded (20)

Application Architectures in Grails