Some weeks ago, Alfresco announced different additions to its framework for developers:
- The new REST API based on swagger.io, which is distributed unversioned by now and included as Early Access into Alfresco web application alfresco.war
- The new Angular 2 components for frontend developers, which are distributed as many other npm components with a ng2-alfresco prefix and releasing new versions frequently
- As usual some resources have been created independently from the existent, so the official IM channel for alfresco ng2 is Gitter instead of IRC
From Alfresco official post, some people from the Community have written also several posts on it:
- Angular is the new ECM UI hype and What’s that fuss about Alfresco Angular2 components? from Andreas Steffan
- Getting Started Guide from Martin Bergljung
Let me share below some of my thoughts concerning this new Universe.
Alfresco development before the advent of this Mars burning ball was based in mature and trustable technologies:
- Web Script pattern for REST development
- Java as main language for repository development
- FTL as mark language for assembling views and pages
- CMIS as recognized standard API to interact with repositories
- AMP as packaging and deploying tool
- Although Alfresco SDK 2.2.0 introduces JAR packaging and it’s announced that JAR will prevail in the future
- Maven as dependency resolution tool
- Spring Surf as main framework for configuration and extensibility
- Aikau as main presentation language for Share development
From now, a new catalog of emergent technologies will join Alfresco Development universe:
- npm as frontend tool for dependency resolution
- AngularJS 2 as frontend framework (including the use of TypeScript)
- Swagger.io as framework for REST development
- Node.js as base framework for Angular
- Google Material Design as CSS and Bootstrap guide to provide the same user experience as all the others
- Yeoman to help writing all this (boring) boilerplate code required for Angular web applications
Alfresco Angular 2 components, building blocks for developers, are available at GitHub and some documentation is maintained at http://devproducts.alfresco.com/browse. By now, we have following catalog:
- Core library, as base component for all the others
- DataTable, to show different Alfresco data in that structure
- DocumentList, as alternative to Alfresco Document Library
- Viewer, another implementation for PDF.js
- Login, currently just including Alfresco credentials and lacking of
- Activiti credentials integration
- SSO mechanism
- Upload, including some new features as Folder upload
This is not a closed list, as many other existing Share features can’t be developed easily with just only this building blocks.
As I said before, starting Angular web applications from scratch is not so easy, a lot of boilerplate work must be configured before real coding.
Alfresco provides two different Yeoman generators to make easier this initial tasks:
- Yeoman Generator Angular 2 Alfresco Component to start building new components
- There is no communication from Alfresco on ways or mechanism to provide customized ng2 components from external developers to this framework
- Yeoman Generator Angular 2 Alfresco Application to start building web applications by using Alfresco ng2 components
Once all those node requisites has been installed on your development environment, a web application can be generated by using yo. And the Google Material Design applied will provide you the same interface feeling as all the other web interfaces from all the other products around the world.
From my point of view, this is the worst decision that has been taken in all this new universe. Being as all the others gives you some advantages, but the counterpart is to become as dull as ditchwater.
All these fireworks for the front end must rely on a service framework, which currently is provided as an additional node component:
However, swagger.io framework provides many other features that have not been promoted by Alfresco:
- Online and offline editor for REST API YAML description
- Core implementation of REST API in Java or in any other language
- Client codegen for many development frameworks and languages (including the one selected for ng2 components Node.js)
- Web UI to explore and test the whole REST API
Additionally, this swagger.io product has become a new widely adopted standard, called OpenAPI, which consolidates the line of including standards in Alfresco product.
From two years before these ng2 components joined Alfresco universe, Activiti team was developing an Angular web application which is consolidated in Activiti Enterprise release but which is only available as beta (since six months ago) in Activiti Community:
Activiti REST API is not designed by using swagger.io or YAML, however is mature enough to be used with the new Alfresco ng2 components, as it has been used intensively with Node.js environments.
Moreover, Activiti uses REST invocations to gather data from external sources, which make this product prepared to be integrated softly with this new philosophy.
That new philosophy includes a componentized UI relying on a REST interconnected backend.
It’s like applying those microservices concepts to web applications, which allows developers to provide a unique vision for users when providing complex work environments.
Currently both ng2 components and REST API are in early access period, however Alfresco has communicated that version 1.0 will be released in November 2016.
From my point of view, this first stage will not be complete with this 1.0, so I’m thinking of a new 2.0 release where all the development cycle can be covered.
As many customers will remain using Share for years, it’s required to provide a strong integration between those Angular web applications and Aikau technologies. On the other hand, it’s also required to consolidate technologically Share web application, removing old frameworks like YUI or FTL.
In order to have a uniform platform, swagger.io will be the unique backend for both (and for any other). User experience integration can be achieved by coordinating Google Material Design principles also in the Share part.
So, although an Alfresco developer will have to learn many different technologies in the future, the possibility to provide a unique solution for every use case will worth the effort.
I’ve been writing code from more than 20 years ago, so I’m very cautious evaluating all this new frameworks and components based in node, which make me feel insecure when providing solutions to customers. However, this is a path we all have to walk, so let’s go ahead just being conscious where we are standing.