While it may be nice to choose the techniques you are familiar with, it’s certainly not wrong to diverge from paved roads. Of course, it is easier to choose the path you’re familiar with, but it is not said that the comfortable paved road provides the best solution and delivering the best solution is what we get out of our bed for every day.

So, for a new project that I recently started working on for one of my regular freelance clients, I decided to step out of my comfort zone. In Sprint 0 of the E-Commerce platform project I started looking at another approach that lends itself better to this project. Among other things, one of the key requirements was the ability to hook the application up to the existing database and at the top of the requirements list was the performance of the application.

Diverging from paved roads does not necessarily mean that we do not use the knowledge we already have. Applications are increasingly being made up of separate components. We can also make new combinations of frameworks. I therefore chose in this project to develop the backend with Springboot. A framework everyone on this project has previously worked with and which is flexible and very easy to expand through standard modules.

In order not to bother the user with a flat HTML page, of course a “front” had to be developed. Matt Raible, one of Devoxx 2015’s favorites made a beautiful source of inspiration with his talk about hot javascript frameworks he gave on SpringOne 2GX. This was a nice starting point.

Based on this presentation, we assessed a number of front end frameworks on suitability for the project, including: EmberJS, AngularJS, Angular2 and ReactJS. One by one we examined these frameworks, with findings:

  • EmberJS was not flexible enough in terms of integration and held a very strong way of making it all in the ‘ember’ way;
  • AngularJS is leaning towards EOL, due to the introduction of Angular2;
  • ReactJS is beautiful, but for this project, it’s not really the full application framework we’re looking for.

Angular2 did meet the requirements for this project. And the other freelancers also appreciate the use of Typescript as their background consisted mostly of Java development.

Based on our research, Angular2 thus seemed the right choice to be used as a frontend framework in the realization of the platform. During sprint 0, Angular2 was not yet released, Beta 12 was just out. It seemed that a final version or a production-worthy Release Candidate should be there in a short period of time.

Then we stood for the next challenge: providing a single page application in Springboot. There are hundreds of AngularJS examples in combination with Spring Boot, but not one based on Angular2. Most Angular2 ‘Getting Started Guides are based on a full Javascript approach with, for example, a Node.JS backend. Also very cool, but this is not entirely within the comfort zone of most people I worked with. In spite of the lack of useful examples, we eventually chose one template that matched all requests that were not specifically mapped as REST endpoint. This template then launches the Angular2 application.

One thing to take into account is to set the Angular2 routing to “HashLocationStrategy.” Then the routing between client side components will take place. Otherwise, for each link, reload the template (and restart the application).

In previous projects we have been able to compile and pack scripts and styles using Gulp.js. That works on the basis of file change detection. We have now also used this and it integrated perfectly:

[15:23:02] Starting 'watch-js'...
Event type: changed
[15:23:06] Starting 'copy:assets-only'...
[15:23:06] Finished 'copy:assets-only' after 138 ms
[15:23:06] Starting 'compile-ts-files'...
[15:23:11] Finished 'compile-ts-files' after 5 s

In our new project Gulp compiles the Typescript sources (to JavaScript) and puts the files in the correct location so that they can be served by Spring Boot as static resources. The fun of Gulp is that it also matches the source maps and supports the same trick for Sass.

A small part of the E-commerce platform is also available to unregistered users. In order to let the application go with non-logged-in users, we used a PreAuthenticationStrategy in Spring, which allows you to use an ‘@AuthenticationPrincipal’ annotated parameter in any RequestMapping. If someone is logged in, it will be filled with the user object that has set up the PreAuthenticationStrategy. Useful!

Through this flexible approach, integration with the CMS pages (running on another application server) is also possible. Nowadays, that kind of Cross-Site requests is very strictly validated in the browser and a “handshake” must first take place. Spring also offers possibilities for it: eventually adding a @CrossOrigin annotation to the RequestMapping is enough to get this done.

That was largely the “plumbing” of the backend. But how does it work with Angular2? Well, pretty good! It feels very mature despite the fact that beta and release candidates have worked. IntelliJ offered the integration of integration and code completion for the beta. The challenge has been in the Release Candidates. We expected that would contain only non-breaking fixes or new functionality. The reality is unfortunately different: some of the new RC versions seemed more like a major version upgrade. Fortunately, Angular2 has now been released and promises stable updates.

In the meanwhile, the project has been completed and the project’s release is scheduled. Despite some startup problems and major Release Candidate changes, we are more than happy with the chosen layout. The performance is great and what a relief to develop component-based, reactive applications in this way.

What makes you choose a specific framework for the back or frontend?