This document summarizes an approach to modern web development that separates applications into logical components with single responsibilities. It advocates for building APIs with frameworks like Grails to handle data exchange, separate admin interfaces, and static single page applications using front-end frameworks. Key points include using test-driven development, continuous integration, and pre-generating static content to improve performance and reduce server loads.

1. El presente y futuro del
desarrollo web y APIs REST
Flisol, ITToluca, Abril 2013

2. Web development
PHP
Ruby
Python
.NET
Java

3. Typical web
development approach
Server side framework
The framework handles all the incoming http request and
process them
Extract data from request and generates response to the user
The framework generates data representation mostly in
html
We can use the framework to generate only data (JSON,
XML)

4. Pros
Very simple to develop
All the app code in a single place
Unique development model
Well know patterns
Tons of libraries and framewoks out there

5. Cons
The server needs to handle several things
database connection
Failure and recovery
User session
render all the time the response to the users
frameworks limitations (user interface, scaling,
adopting new technologies, support lacking)

6. Modern features
Mobile support
Asynchronous processing (server side & client side)
Content negotiation (JSON, XML, html, SOAP?)
View technologies independence (JavaScript, Template engines)
NoSql support (MongoDB, Redis, Cassandra, etc)
Development
Full stack
Specific stack
Cloud deployment

7. Is your framework friendly?

8. Beware
‘Full stack frameworks’
Do you really need a ‘full stack’ framework?
Are you using all the features provided by the full
stack framework?
Sometimes we don’t need a full stack framework
ex. Simple app or service (REST)

9. Real life webapp, web traffic

10. Real life web system
• API:WebServices REST for information
exchange
• Admin.Web application for internal use
• WebSite.A totally static HTML application built
with Chaplin and several JavaScript
microframewoks

11. WebApps architecture
Built your complete solution using several logical
components
Each component has a single responsability
Built each component with the right tech stack

12. Apps
• API
• Typical Grails application, with no GSPs.
• Speaks only JSON
• Used by partners (remote services) and
HipStore
• Admin
• Typical Grails application

13. Development
enhancements
• Increased test cases in both Grails apps
• Spock
• Jasmine for JavaScript code
• Introduced Jenkins
• Jenkins Jobs to deploy automatically to QA &
Production environments
• Bash shell scripts

15. HipStore
• Static HTML application built with Chaplin
• Chaplin is an architecture for JavaScript
applications using the Backbone.js library

16. HipStore
• Developed in CoffeeScript
• Uses PushState
• RequireJS (AMD Support)
• HandleBars (Template Engine)
• JQuery
• Underscore
• Twitter Bootstrap
• Build and packaged with Jake

17. HipStore
• Single Page Application
• Chaplin consumes JSON from the API to
render the store items.
• Uses PushState to update the URL in the
browser.Very useful for bookmarking and
social media sharing, even for SEO.

18. Our approach
• Write to disk all the possible links in
HipStore. Crazy?
• We use ZombieJS to navigate the website
and then write to disk the generated HTML
• Put those static files (HTML) in the
webserver document root
• The best cache ever

19. Why do this?
• When the user visit our website, the
webserver will respond with completely
static HTML, CSS, JavaScript files
• Very fast
• The user never hits the Tomcats, we reduce
the load in the app servers.
• The webserver always responds very fast

20. ZombieJS

21. HTML harvesting
• The Node app receives the JSON message
• Navigates to HipStore with ZombieJS
• Executes the JavaScript (Chaplin app)
• Extracts the generated HTML with jQuery
• Saves to disk in the web server document
root

22. Things to consider
• When an item in the Store is modified, we need to
regenerate the appropriate HTML file only once.
• Then all the users will receive the same file
• The user only hits the Tomcat when really need it
(CheckOut, Registration)
• When the user click in some action in the app, the
interaction is handled by Chaplin controller if the
browser supports JavaScript
• Remember in our website the content is almost static?

23. Results
• The load in our Web Servers was reduce a
lot.
• The load in the database reduced a lot.
• The users can share the links.
• Store becomes very search engine friendly

24. Photo credits
http://flic.kr/p/7gerV8
http://flic.kr/p/5yZGvb