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.

2 comentarios en “A complete vision of Alfresco Developer Framework”

The whole Alfresco web ui evolution worries me. Even though functional alternatives have started eating Angular marketing share, it is still pretty safe to say that the latter will be around for a while. Given the fact that Angular holds a large piece of the market today, I can understand they are betting on Angular – now.