Martin Fowler and James Lewis have an article on micro services here http://martinfowler.com/articles/microservices.html
Though my first reaction to it was, “what, isn’t this SOA”, the article itself had a sidebar which mentioned “service orientation done right”.
Worth a read, Excellent stuff as usual from thoughtworks folks.
To some extent, I felt Martin Fowler is taking an U-turn on
Hence, we get to my First Law of Distributed Object Design: Don’t distribute your objects!
How, then, do you effectively use multiple processors? In most cases the way to go is clustering (see Figure 7.2). Put all the classes into a single process and then run multiple copies of that process on the various nodes. That way each process uses local calls to get the job done and thus does things faster. You can also use fine-grained interfaces for all the classes within the process and thus get better maintainability with a simpler programming model.
Quote from Patterns of Enterprise Application Architecture (PoEAA) Chapter 7 Distribution Strategies.
- I am aware of the terms that Fowler uses here “Objects” – I always thought he used objects here in the sense of component objects / service objects – Earlier in this chapter he uses “With separate remote objects for customers, orders, products, and deliveries. Each one is a separate component that can be placed on a separate processing node.” So I believe he uses object in a broader sense in the First Law of Distributed Object Design.
- Granted today we have a faster network stack
- His argument about coarse grained interfaces was spot on.
- Also I understand the benefits that micro services brings.
I think, he that he should rewrite his Distribution Strategies Chapter in PoEAA to include the micro services alternative as well.
Every application has various concerns. One classification of these concerns is application infrastructure concerns and business concerns. The business concerns are specific to an application and differ with each one of them. On the other hand infrastructure concerns are somewhat similar and with right parameterization we can reuse them across applications.
Various libraries and frameworks exist in any technology space to help us with the infrastructure concerns. Writing infrastructure code is (when it is solved by someone else already) is stealing from your employer / client (http://codebetter.com/jeremymiller/2008/11/07/how-to-design-your-data-connectivity-strategy/)
- Routing, Navigation & History
- Template Engines
- Communicate with the server to read / update the model
- Responsive Web-design
- DOM manipulation
- Asynchronous Programming
- UI Widgets
- Feature detection
Another level of reuse is the reuse at the conceptual level / design level / idea level. Frameworks excel in this form of reuse. Frameworks are opinionated. They enforce or provide some default architecture / structure to your application. Frameworks have inversion of control. That means frameworks may enforce a life-cycle and typically the framework calls your application code and not vice versa.
UI Architectural patterns are all about Separation of Concerns and having more maintainable code – Divide and Conquer. Frameworks may typically follow (an) UI Architectural pattern(s)
Let us now see how angularjs helps in Code Organization and Infrastructure concerns
What is AngularJS?
I will use and elaborate a slightly modified version of Amit’s answer to What is AngularJS? When is it needed? on Quora http://www.quora.com/What-is-AngularJS-When-is-it-needed/answer/Amit-Asthana
Let us see each one of these
Angularjs code you write typically falls into one of these buckets
If you are talking to the outside world, this is a perfect use case for a service – from (http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/)
Directives are a declarative (Some call this functional, but i believe this is declarative) way of manipulating / working with the DOM. The Web standards too are polarizing in this direction – Example: Web Components. Directives are one of the key aspects of angular (often misunderstood and under used)
Directives are either completely new HTML elements, or attributes that you can throw on existing elements, to perform some kind of DOM manipulation. They can have their own scope and they can be reused, which is one of their most useful properties. – from http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/
The html templates written using angularjs directives and standard html elements
Angular lets you write non intrusive POJO model objects. Angularjs implements its own dirty checking http://stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933 which means you can write your models as POJO objects, but it does come with a performance hit.
“glue” of your application. Controllers use model (methods and data) provided by the services and provide them to the directives. – adapted from http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/
Angularjs is designed for ease of unit testing. It is made easier by
- Dependency Injection
- Standard Mock Service Providers
The whole of Angular is linked together by Dependency Injection (DI). It’s what it uses to manage your controllers and scopes. Because all your controllers depend on DI to pass it information, Angular’s unit tests are able to usurp DI to perform unit testing by injecting mock data into your controller and measuring the output and behavior. In fact, Angular already has a mock HTTP provider to inject fake server responses into controllers. – from http://www.sitepoint.com/10-reasons-use-angularjs/
See the discussion on directives above.
In addition to these angular provides solutions to these infrastructure concerns
- Template Engine – Angular provides a DOM based template engine.
- Data-binding – Bidirectional reactive data-binding
- A context aware pub-sub system
- GUI widgets
- It will be interesting to see Polymer custom elements and angularjs directives against each other.
After a long time I am posting a technical entry. I am in search of non intrusive client-side templating solution. The following are the requirements
- Non intrusive Should not require something like
ko.observable, ko.mapping and then tableMetadataViewModel.name(), tableMetadataViewModel.name(‘Employees’)
Ember.Object.create, tableMetadataModel.get(‘name’), tableMetadataModel.set(‘name’, ‘Employees’)
- Is reactive / supports ‘Live Templates’ To Quote from Wikipedia
For example, in an imperative programming setting, would mean that is being assigned the result of in the instant the expression is evaluated. Later, the values of and can be changed with no effect on the value of .
In reactive programming, the value of would be automatically updated based on the new values.
A modern spreadsheet program is an example of reactive programming. Spreadsheet cells can contain literal values, or formulas such as "=B1+C1" that are evaluated based on other cells. Whenever the value of the other cells change, the value of the formula is automatically updated.
In this specific context, when I update the name of the table object by setting an alias like
table.alias = ‘e’
It should automatically update in the UI.
- Two-way data-binding
when I update the name of the table object by setting an alias like
table.alias = ‘e’
It should automatically update in the UI.
And when I update the alias in the UI, it should update the object model.
- Model as the single-source source of truth In this specific context, when I update the name of the table object by setting an alias like
table.alias = ‘e’
All the places in the UI where table is rendered as a view should be updated.
Reactivity and Two-way data-binding go a long way in helping Model as the single source of truth.
Supports defining templates in external files and plays nice with requirejs text plugin.
- Performs efficiently
Supports r.js optimizer & requirejs text plugin
For example splitting the application into small modules that have a single responsibility requires writing many modular templates. But i may result in poor performance if we make many calls to load them from the browser. Bundling them with the r.js optimizer for example can reduce this performance hit.
Reactive templates should not mean the whole template is re-rendered every time model changes.
For example modifying an item, adding an item or deleting an item in a list should not re-render the whole template and instead just re-render / add / delete the concerned item nodes and the whole list or worse the whole template.
No dirty checking
- For example angularjs uses dirty checking that impacts the performance negatively.
Read this to see what I mean http://stackoverflow.com/a/18381836
- Plays nice with other legacy frameworks / libraries
Recently I tried my hand with Polymer Web Components Stack. I ran into a hard to identify issue. Finally the issue was joint.js(+jquery) which I was using in conjunction with polymer was walking the DOM tree and made an assumption that the root node is the document node. Which is not true when it comes to shadow dom.
- Fits well with Nicholas Zakas’s Scalable Application Architecture
Can I find the templating solution that fits well with Nicholas Zakas’s Scalable Application Architecture? Time has to tell.
object.observe, web components based?
- Some sort of a dom based templating solution based on object.observe on the modern browsers and an object.observe polyfill in other browsers which do not support object.observe should be good. But looks like knockout, ember etc are not taking up the object.observe route yet. May be I will end up forking knockout and implement one myself.
A build-time two-step transform view?
- http://martinfowler.com/eaaCatalog/twoStepView.html with one of the transforms / templating running at build-time may help support multiple template engines from a single template. But it will be really hard to build such a library.
- Taking a hard dependency on a single templating solution, esp. for a product does not seem right.
- Are there any adapters / abstractions available that help one switch templating solutions over the same Model?
- Any suggestions comments would be welcome.
You need to communicate with the server to retrieve the model from the server, and to put the updates to the model on the server. These libraries typically should provide a higher level of abstraction than xhr (or even $.ajax). Typically they should handle
- The model serialization / de-serialization (ex: date format issues). Most of the community as settled on JSON as the default format here.
- Protocol used to communicate with the server (REST / DDP – See below)
- Provide a higher level of abstraction to deal with asynchronous ajax calls like jQuery’s Deferred / Promise abstraction.
- Change tracking?
- Isolate and abstract the server communication from the rest of the application modules.
In the Requirement Specific Parameters post I talked about live / real-time updates. Meteor implements real-time updates on top of a protocol called Distributed Data Protocol (DDP). This alleviates us from a need to poll the server for updates. Other frameworks like Derby also support this real-time updates, they call it Subscriptions. I am hoping in the future everyone will settle on a standard protocol.
Some of my notes from links given below:
Explicit URL Design
URL Design is the process of designing the structure of your application’s URL. Do not leave URL Design to the framework / library you are using. Make an explicit choice about the URLs used by your application.
In a Single Page Application you want the URL to change as you navigate between views. This will provide the application the ability to deep link into specific parts of the application. Routing is the process of selecting a view based on the URL.
In a Single Page Application, when the URL changes you do not want to go the server to get the page when the URL changes. This is achieved typically by using location hashes in the URLs. Location hashes are supported in all the browsers, but they are not understood by the server.
When when the Search Engine Bot sends a Hash url to the server the server the server ignores the hash and will not be returning the right page. People workaround this by using a hack called hash bangs that is supported by Google’s Search bot. Hash bangs have been criticized by several Smart people and are not recommended.
HTML5 History API – pushState API
The alternative that is acceptable is HTML5 History – pushState based URLs. This allow to server pages in the client without going to the server on a URL change. But the issue with HTML5 history – pushState API is that it is not supported in all the browsers. So the routing engine / history library you select should be a Polyfill for unsupported browsers.
What ever polyfill hack / workaround the client-side library uses needs to be understood by the Web Server and the right pages should be served for SEO scenarios.
Traditionally these routing engine implementations were inspired their counterparts on the server-side. Server-side is a stateless environment so these routing engines on the server were designed with that limitation in mind. The client-side on the other hand is a different story where you can leverage the stateful nature. Ember’s routing library implements a stateful routing. It is something to keep an eye on.
Can you deep link to specific views in your Single Page Application?
If you can deep link are the URLs SEO friendly, are they readable?
Should you use location hashes which are supported in pretty much all browsers or should you use HTML5 Push state based navigation bowser support for which is still poor?
Do you need SEO? SEO requirement has an impact on location hashes. Can you avoid Hash bangs if you choose the right routing / navigation / history library?
What is a Template Engine?
- DOM based, DSL based (ex: Angular, Knockout)
- DOM based, Non DSL – (ex: Future browsers that will natively support DOM templating)
- String based, DSL based (ex: Handlebars, Mustache, dustjs)
- String based, Non DSL – (Plain Old Html ex: Plates)
Why is the categorization relevant?
- Using a DSL based template engine is not so user interface designer friendly, these templates are no longer Html.
- Using a DOM based engine makes it difficult to execute the template on the server-side. These factors have a significant impact on template engine selection.
I have written about some requirement specific parameters here, that are problematic if we use a client-side template engine. For the cases where we need
- SEO / Accessibility / Progressive Enhancements
- Faster initial load times
a workable solution available today is to
- Detect these scenarios
- Render the pages on the server-side rather than on the client-side.
Of course we do not want to duplicate the templates once for the server and once for the client. So for these scenarios we need a template that is isomorphic (can execute both on the server and client).
A string based template engine is the best choice for the scenario, But if you use a DOM based template engine it is still not the end of the road, there are server-side DOM simulations available.
Keep in mind
- These are DOM simulations are not real browser DOMs
- And are bleeding edge
Template engine performance
Template engine performance has a context associated to it. That is where the template is rendered.
On the client
- String based: string => template engine => string => browser => DOM
- DOM based: DOM => template engine => DOM
On the server
- String based: string => template engine => string
- DOM based: string => DOM Simulation => DOM => template engine => string Of these operations string => DOM is an expensive operation. So in theory string based template engines are faster on the server and DOM based template engines are faster on the browser. But its good to actually measure it.
The other point to keep in mind is when considering a string based template engine on the client we also need to take into account the time taken to load the template output into the DOM.
String based: string => template engine => string => browser => DOM
Notes summarized from
Updates / Refresh
Another feature that you may want to consider when you evaluate a template engine is whether the template engine can update the views automatically when the (view )model changes. Can the template engine re-render when the model changes and can that be localized to partial portions of the view or the entire view has to be refreshed. Different libraries use different terminology here, Spark – Meteor uses the term Live Page Update, Ember calls this Auto updating templates.
- Use a DOM-based template engine if SEO / Accessibility readers / Progressive enhancement are not a concern & you do not need server-side rendering. Ex: Knockout
- When both client & server-side rendering are required choose a string based template engine. Ex: Handlebars / dustjs.
- Even if you use a string based template engine it is worthwhile to keep a watch on the following categories. DOM based template engines (Angular, Knockout). Non DSL based template engine that lets you write plain old html markup and uses standard json (Plates).
Logic in templates & Reuse
- If you come from a server-side scripting environment you may be familiar with logic getting embedded in the templates. Logic-less templates are an answer to this. DOM-based template engines are generally not Turing-Complete Programming Languages so it is hard to embed logic in DOM-based templates
- If you come from ASP.NET Web Forms side you may be familiar with the Controls model which offers template reuse at control / widget level. Angular has support for something like this, they call it as directives.
The marriage of Html and your (view )model data does not end with template engines alone, because it is just one side of the story. A traditional template engine is usually about getting your data on to the browser as Html, what about the other way round. When the user inputs a value in the browser can the template engine update your model back. This called bi-directional data-binding. Some people use the term data-linking.
Many of the DOM based template engines support this bi-directional data-binding out of the box. Some of the string based template engines also support this (Ember for example implements this feature on top of handlebars).
This feature is particularly useful if your application is input intensive. Read more about Input intensive applications here.