This document discusses strategies for improving monolithic applications by breaking them into modular components. It recommends identifying modules/components based on requirements and ensuring they are small and decoupled. Distribution of components can be done using private repositories for Bower or NPM. The model should be abstracted and enriched with metadata to define relationships and rules rather than tying it to a specific client library. Components should have well-defined scopes, and demos, resources and the speaker's contact information are provided.

2. About Me
• Technical Leader and Agile Coach
• Front-end Developer (test first!)
• Mobile Developer (Hybrid with Cordova, iOS, Android)
• Technology Enthusiast
• Mentor @ Airpair.com

3. What's Next?
Scotch Streaming
and Scaling
11 Feb 2015
www.meetup.com/mobiletea

4. Agenda
• Monolithic applications
• Identify modules and/or components
• Distributing modules in your organization
• RESTful and Hypermedia models
• Demo

6. Enterprise
Applications
• Existing code base and legacy code
• Short time to market
• Prototype based
• Lack of planning and strategy
• Adapting to marketing needs

7. M/S Size
Applications
• Unexpected success
• Budget constraints
• Missing expertise
• Lack of planning and strategy
• Adapting to customer needs

8. What's in Common?
Lack of design iterations and separation of concerns
monkey animated GIF

10. Major Problems
• Maintainability
• Scalability
• Learning curve
• Difficult setups
• Complex release procedures
• Difficult to test
• Integration nightmares
• Long build cycles

11. Possible Solutions
• Refactoring
• Documenting
• Decoupling
• Move the mode on the server
• Add computation capabilities (e.g. clouds)
• Etc.

12. No Escape
eating animated GIF

14. Modules
An application module is a class that represents a business
application task. (Oracle)

15. Components
A component is a reusable program building block that can be
combined with other components.

16. That's Good!
robert deniro animated GIF

17. Identify Them
Starting from Your
Requirements

18. Small and
Decoupled
• Identify small and decoupled parts of your application
• Try to understand which are reusable across several apps
• Iterate across your modules and/or components list before
implementing a new feature
• Pick-up the right toolset to implement a specific set of features
• Never reinvent the wheel!

20. Distribution
Requirements
• A module/component should be easy to install
• Dependencies should be easy to manage
• The features of every module/component should be very clear
• All the releases of a module/component should be
always available (eventually dismiss the support)

21. Possible Solutions

22. What's About my
Privacy?
wtf animated GIF

23. Bower
Use a private git repository on github.com or create your own git
server
{
"name": "my-amazing-component",
"version": "1.0.0",
"ignore": [
"**/.*",
"node_modules",
"bower_components",
"test",
"tests"

24. NPM
Try the npmjs.com enterprise service or create your private npm
server using Sinopia to create private packages

25. Using NPM
You can then use npm as usual but everything will live into your
private repo, the only difference is that you set a different registry
(actually you can switch between them)
$ npm set registry http://your_external_ip:4873
$ npm adduser
$ npm publish

26. Results
• You can install and uninstall components easily
• The dependencies management process is automated (kinda!)
• Every component/module can be unplugged from your
application and changed
• The source code is better organized (components should work
also stand alone)
• Etc.

27. What's Missing?
The model...
tech animated GIF

29. Abstract the Model
• Keep always the model independent from your client side
architecture
• JSON or XML are valid formats to distribute the data
• Use data adapters (Backbone, Ember Data, etc.) to deal with the
model in your client side code

30. Enrich the Model
• Don't deliver just data but also business logic information like
related links
• Use the flexibility of JSON or XML to provide a structure to your
models
{
"href": "http://example.com/api/v1/users/john",
"type": "user",
"head": {
"allow": ["GET","PUT","PATCH","DELETE"],
"related": {

31. Deliver Your Rules
• Use the model to explicitly set the rules to follow to
post/put/delete/ information to your system
• Deliver form validation rules (e.g regexp) to avoid to re-build the
client if something change
• Provide live update information (e.g. web sockets) to update
your application
• Etc.

32. Always Avoid
To define a model that fits the needs of a specific client side library,
it's a path that is very hard to undo

34. Recommendations
• Try to don't depend only on a single client side library
• Don't be too lazy, JavaScript can handle natively the tasks
performed by external libriaries
• Keep the communication as simple as possible
• Write clean and testable code
• Etc.

35. Components Scope
• Use web components CSS scoping if your concern is the look and
feel of components/module
• Use an iFrame to enclose your component in a sandbox

36. Demo
https://github.com/GiorgioNatili/undoable-architectures

37. Resources
• http://almostobsolete.net/talks/hypermedia
• http://liquidmedia.org/blog/2011/01/backbone-js-part-1
• http://madhatted.com/2013/3/19/suggested-rest-api-practices
• http://emberjs.com/guides/models/the-rest-adapter
• http://cwbuecheler.com/web/tutorials/2014/restful-web-app-
node-express-mongodb
• https://oncletom.io/2013/live-development-bower-component
• http://tech.pro/tutorial/1308/emberjs-views-and-live-templates-
with-handlebarsjs-part-1

38. @giorgionatili
#mobiletea #javascript #swift #wearable #agile #android #tdd

39. Thanks!
Grazie! Graçias! Danke! Merci! !
thanks animated GIF