[Versión en castellano]

I’ve always tried to adapt our working methods to new market needs. All of this has led to an improvement in our processes, tools used and, also, in our products.

Througout the last years, we have analyzed how new paradigsms of web development could affect our products, our developers and our clients. It cannot be denied that there has been a change, since the former thin client has mutated into a new thick client.

This client uses different technologies than there used to be. Nowadays using javascript frameworks as React.js, Angular, Vue or apps developed in Swift, Kotlin or Java are the de facto standard. And serverside code has changed into an API or a set of them.

This approach, in several cases, makes the client code almost monolithic. We could consider if it wouldn’t be better to split this monolith in snippets. In my opinion, this division could give us a set of advantages as, for example :

• Controlling the avalaibility of a snippet taking into account security, permissions or even marketing needs.
• Making easier the snippet development by different working teams.
• Improving the release to production, considering how this snippet should be tested.
• Provide an integrated response to different strategies such as marketing A/B.

In fact, all of this division and composition has been tipically provided by service orchestrators or portals, such as Proxia®.

In order to provide you with a deeper understanding, take into an account that in a typical Java based Portal you have the Portlets standard. This standard defines how these snippets lifecycle must be.

image000

If you notice, new development paradigsm doesn’t fit very well with this approach. Since presentation logic and some business logic are done client side, which could be the purpose of this state machine in the server ? In my opinion this traditional approach of portlet development is a no-go. But service orchestrator, as stated above, is yet an actor to take into consideration.

So then, the challenge was to be able to enhance the orchestrator including those new web development application approachs. In order to solve it, we have used all of our previous experience, including portlet support and also plugins & services support based on OSGi standards, which allowed us to create isolated modules.

However, we shouldn’t consider this module as only server-side code. If we proceed that way, frontend layer would be disconnected from the orchestration capabilities. Our solution was to define that module as a container for server-side and client-side code. On the one hand server side is intented to be an API, acting as business logic, middleware or even a proxy. On the other one, the client side could be developed with a modern technology framework or library.

Image0001

Therefore, this module is transformed in a new portal service a de facto portlet but without server states. But like old portlets, it could be dragged on screen and configured. Moreover this approach allows us to combine this new development pattern with the old Portlets one

Image002

Credits

Icons created by Flaticon

• Programming icons created by juicy-fish – Flaticon
• Css icons created by Freepik – Flasihicon
• World icons created by amonrat rungreangfangsai – Flaticon
• Paper icons created by Freepik – Flaticon
• Box icons created by Good Ware – Flaticon
• Sass icons created by Smashicons – Flaticon
• People icons created by Sudowoodo - Flaticon
• Dashboard icons created by Freepik - Flaticon