- reasons why you should adopt these new architectures;
- opportunities they provide;
- impacts for enterprises.
Why adopting these new architectures?
Address heterogeneous clients with the same back-end code
A major advantage of this architecture is the development of an API: functionally oriented and developed using standard technologies such as JSON over HTTP, it can be used by many other clients than the initial Web application. It is a well-known architectural pattern, widely used in the mobile world. Enterprises usually have experience in implementing Web services linking complex information systems with mobile applications.
With a server-side MVC architecture, we would first need to develop a service layer calling the back-office, before using it into the Web application. With a client-side MV* architecture, we no longer need an extra-layer, as APIs can be consumed directly. Besides, when starting from scratch, we can invest right away in a “clean” API, free of any specificity related to the GUI technology.
… and open the API?
If you already use an API for your applications, making it accessible to the outside should be quite easy. You would thus embrace the concept of Open API. This obviously requires adopting a specific approach and setting many other elements, like an ecosystem for your API customers, but it is a good opportunity to consider when you have these Web services available!
Improve development productivity
At OCTO, this architecture already allowed us to realize a dozen projects of all kinds: Web, mobile or desktop, business or data visualization applications. Looking back, using technologies like AngularJS or Backbone.js significantly improved the productivity over using server-side MVC frameworks such as JSF or GWT. When working in a Java or .Net environment, if we do not want to overload the infrastructure with a new middleware, the productivity of front-end development with technologies like AngularJS is thus a very strong advantage. This is less true if we compare with more web-friendly technologies such as Ruby on Rails or PHP; in that case client-side MV* architectures still retain the advantage of consuming agnostic APIs, as explained before.
Deliver more powerful, rich and ergonomic Web applications
Beyond the productivity, it is also necessary to compare the end product. When using a MV* framework, we develop the whole application in the browser, for the browser. This allows developers to directly and easily access all features offered, which are numerous since the advent of HTML5: data storage, offline, file system access, multi-threading, data push…
Remember the features coming with HTML5:
How many of them do you currently use? How many will you use in a year from now?
Replace a heavy and complex application and deploy it as a SaaS
Complex business applications were also mostly provided as fat clients. This can be explained mainly by the bad performances of Web technologies back then. Now, CIOs generally want to get rid of fat client technologies like VB or Swing, but no long term and open solutions have emerged. One of the last challenger was Flex, but his destiny left in the hands of Adobe is not reassuring. Another one is .Net combined with WPF, in the Microsoft ecosystem. GWT tried and almost succeeded in making realistic the development of complex Web applications. In the end Google, always at the cutting edge of technology, decided to reduce its involvement in this framework, to hire the AngularJS developers and to invest in the Dart platform.
The alternative to the maintenance of old applications is now to look into new Web architectures. We still have to be very careful about the relative immaturity of the technologies before revamping complex applications. The platform itself (the Web and the browsers) are mature enough, but technologies are moving fast and can induce a significant maintenance cost for an enterprise that is not a “pure-play” internet company.
What impacts for my enterprise?
From a technical perspective, the impacts of these technologies on the enterprise are actually quite limited: we know how to develop and run Web applications in production. Besides, setting up an API is nothing really new and security patterns are already used for mobile applications and RIAs.
Knowledge of application architecture and development industrialization (tests, etc.) are prerequisites for these new technologies.
Fortunately, the latest MV* frameworks offer ease-of-use and guidance, which greatly lower the entry barrier even for a non-expert developer.
And this is the major achievement of this evolution: client-side MV* applications development is now as easy as that of classic MVC applications.
Temptation to create teams by technology layer: front-end and back-end
Reorganizing the team must be considered: we could simply dedicate development teams for the front-end and others for the back-end. However Agile methodologies recommend building feature teams instead, covering all the required skills for developing features rather than technology layers.
Conclusion: some pitfalls to avoid
In conclusion, we must keep in mind that the new Web architectures provide great opportunities for developing applications and offer new possibilities that can benefit to end users and enterprises.
Though we must be careful when choosing the right technology:
- These solutions are not necessarily the best for all use cases: there are for instance better solutions for building static websites, in terms of performance and SEO.
- Comparing native mobile applications with Web applications is still not in favor of the Web: there are still many possibilities with native mobile technologies with no equivalent in Web technologies. Each context must lead to a different strategy choice.