Client-side MVC frameworks like AngularJS are getting more popular over time. They represent a big architectural change to what web developers are used to: moving from server-side MVC to a browser based one. In this talk I will speak about how Grails can fit with a single-page architecture and discuss the pros and cons of developing that kind of applications.
The companion code is published at https://bitbucket.org/alvaro_sanchez/backoffice
2. About me
• Passionate software developer.
• Founded Salenda in 2005.
• Co-founded Escuela de Groovy in 2009.
• Groovy/Grails lover since 2007.
• Working now at Odobo.
3. • HTML5 games platform for:
• Game developers.
• Casinos.
4. Typical Grails
Architecture
This is about architecture.
Grails is essentially MVC.
This can be fine for some projects, but may have drawbacks in large projects
5. Monolithic!
Although the individual Grails artifacts can be developed in a modular way, it still has the
views and the business logic on the same artifact.
6. Slow GSP rendering!
Slow startup time!
Memory consumption,
reloading issues...
Sitemesh and the GSP rendering engine it’s not the fastest thing in the world...
Large projects may suffer slow startup times, intensive resource usage, ....
7. Other problems
• It’s tricky to decouple the view layer to
render views for different devices.
• It’s difficult to do frequent deployments.
• It’s hard to scale development.
Although there are plugins to solve this, it’s not that agile to have different renderings for
different devices.
Changes on the UI will require to redeploy the whole thing.
The development efforts must be synchronized.
8. Grails 3.0 will have
application profiles
The Grails roadmap is already embracing the change, and 3.0 will offer different profiles:
- Classic MVC.
- Netty.
- Vert.x.
- Etc.
9. So... WTF is a Single
Page Application?
SPI or SPA.
10.
11. • A webapp where you can navigate
without any page refresh.
• Ajax/REST is used to communicate with
the server.
• The MVC is in the browser, written in
Javascript.
16. • It’s faster.
• It has better user
experience.
• It may be easier for
the developer.
• How to gracefully
degrade?
• How to deal with
communication
failures?
• Can I use the
application offline?
need
• Do IMVC? to duplicate
the
The applications are usually faster and more responsive, so the user experience is better.
It may be easier for developers, as they don’t need to deal with callbacks, the views are
updated automatically.
---What if there is no Javascript enabled?
How to handle network issues?
Are we going to have duplicated efforts?
17. Other benefits
• You get ready to expose a public API.
• It allows you to update the UI frequently.
• It’s easier to create mobile apps.
• You can organize/scale your teams
better.
Separating the view you get ready for exposing an API.
The UI can be redeployed frequently, without affecting the platform.
It’s easier to create different views, for different devices.
The dev teams can be reorganized and some development can be done in parallel.
19. • Use Grails 2.3 REST capabilities.
• Define your backend: GORM? Other web
services?
• Make it a robust, powerful black box for
the front end.
Grails 2.3 comes with significant improvements to build REST API’s.
You can still use all Groovy ecosystem to consume any backend.
Then, you can concentrate on building a robust, tested, black boxed Grails layer.