Tuesday, December 2, 2014

Npm, Bower, CI and the Network

Ok, I accepted the reality that building single-page applications (SPA) is better done using the tooling options embraced by the JavaScript community, rather than building those apps using purely Gradle or Maven (and respective plugins). The reason being that building a complete web-UI is rather involved and tools like Yeoman, Grunt (Gulp) and Bower provide quite a bit of useful tooling while also having a much larger user-base than the (less complete) options in the Java world.

So life was good. Everything builds. Of course we still need to integrate the app with our backend that provides the REST endpoints. Personally, I prefer it that developers can build the entire stack at once. Also, can we assume that every (Java) developer has Node/Npm intalled?

Luckily, there are some plugins available for Maven and Gradle that provide useful wrappers around Npm and Node:
Thus, with some trial and error you get a fairly portable build (Linux, Mac and Windows) that not only executes the Grunt build but also downloads and installs Node and its dependencies, Grunt, Bower etc.

You think you finally arrived...Things run mostly okay on the continuous integration (CI) server...mmh, wait... "Mostly" is causing some headaches. This is actually an area where I have some frustrations lately. Looks like the Maven Central in the node world is a tad more volatile than Maven central itself.

In the Java world you have 2 layers of protection that ensure that the CI server build process is fairly resilient to internet hick-ups. Heck, it would even build off-line (assuming no library dependency changes were done). First, you have your local repository of course, which in the case of Maven is typically ${user.home}/.m2/

Second, any serious CI environment would also use a dedicated repository manager that serves as a proxy to the outside world, so that for already retrieved dependencies you would not need to hit Maven Central or other 3rd party repositories.

With NPM you all of a sudden realize you are a tad back into the wild west. Not only do you have to consider NPM (Managing tooling dependencies) but Bower (managing JS/CSS dependencies) as well.

NPM actually provides npm-cache - and you see dependencies being cached in your home directory under ~/.npm/. But try to disable your network card...the eternal spinner is yours. It does not even seem to timeout.

You can go offline - kind of - using “npm install --cache-min 9999999 --no-registry” but it does not seem to support things the way Maven/Gradle does: Check the cache first, and only if the dependency does not exist fetch it remotely. See also: https://github.com/npm/npm/issues/2568

Another issue I encountered is with using Protractor for the E2E testing of my AngularJS application. You will usually use webdriver-manager to retrieve the necessary Selenium files/driver for your targeted Browser, e.g. Chrome. Since, I like to make the build as portable as possible, I do a post-install of the web-driver manager, which requires direct network access in package.json:

"scripts": {
  "postinstall": "node_modules/protractor/bin/webdriver-manager update"
}

Bower unfortunately, does its own caching approach which is configured in .bowerrc, e.g.:

"storage": {
"packages": ".bower_cache"
}

So what about using dedicated repository managers as proxy for NPM and Bower?

Artifactory provides support for NPM but not Bower. There is a feature request to support Bower in Artifactory, though. Nexus also has support for NPM. For Bower an open ticket exists.

Maybe people should start rallying behind web-jars more broadly ;-(



Labels: , , , , ,

Monday, October 13, 2014

Digging Deeper - RequireJS and ES6 Modules

I was exploring RequireJS and ES6 Modules some more this weekend. Originally I started to explore how I can use richer domain objects (classes) as part of our AngularJS application that uses RequireJS for modularization. As part of that endeavor, using RequireJS looks like an interesting approach to inject classes into the application (Remember that AngularJS injects class instances ;-)

Here is a list of interesting resources that I came across.

RequireJS Basics

In order to get a refresher/introduction to RequireJS, I found Rob Dodson's RequireJS -- Embracing the Awesomeness of Asynchronous Modules quite nice:
Integrating AngularJS and RequireJS

Thomas Burleson's Angular and RequireJS from ng-conf 2014 was high on my consumption list. I think his explanation of how RequireJS relates to AngularJS was perfect.
I thought his code example was a tad on the complex side, though (Meaning I may need to revisit it ;-). For practical purposes, I then discovered Burke Holland's Requiring vs Browserifying Angular which I think is the nicest tutorial I came across:
The tutorial also underlines the point that using AngularJS and RequireJS is not for the faint of heart. It has its challenges. Maybe I need to look at Browserify?

One challenge I came across this morning for example,  is to make angular-masonry work with RequireJS. I was able to solve that challenge using this Stackoverflow posting:
Whats is coming with ES6 Modules

When looking at modules, it does not take long to come across ES6 Modules, the next hot thing coming our way as part of ECMAScript 6 (see Using ECMAScript 6 today)

First I watched Browser Package Management (by Guy Bedford):
He also has a nice blog post:

http://guybedford.com/practical-workflows-for-es6-modules

Another good video was Guy Bedford's talk: Package Management for ES6 Modules from JSConf2014:
What was interesting to learn, is that with SPDY, the bundling of web-resources won't be necessary anymore (eventually). See Multiplexing with SPDY and HTTP/2 for explanations:
So here is what is next for me...I need to look at the following projects and see how all this is usable today. Certainly looks fascinating being to use ES6 features right now, also keeping in mind that AngularJS 2.0 will use ES6 modules.

Labels: ,

Monday, October 6, 2014

Java Template Engines Revisited Part 1

Over the past week, I spent some time looking at Java based template engines. Typically I need templating support for two areas:

  • View Templates (For rendering views in your browser)
  • Email Templates - with support for both HTML and Text emails

For email templates I had used the usual suspects such as Velocity and Freemarker in the past but both feel a tad heavy and old these days - Velocity's last release was in 2010! Eventually I settled for a simpler option a while back: StringTemplate, which as a library worked fairly okay.

As I had done some client-side templating using Mustache and Handlebars, I was intrigued in seeing Java implementations for both:


The nice thing about Mustache is that implementations are available for almost any programming language imaginable, which could be nice in case you have the need to maintain browser-bound and backend (Java) templates or in case you have multiple Java and non-Java application with templating needs.

For now I have chosen mustache.java. Looks like it is heavily used at Twitter. Depending on how willing you are towards enduring any type of logic in your templates, you may also want to check out Handlebars and the corresponding Java implementation. It is basically a super-set of Mustache, providing additional built-in helpers.

Lastly, for both Mustache and Handlebars there is support available for Spring MVC.


I have not used either support for Spring MVC, yet, though. In case you have used any of the mentioned options, please leave feedback to this blog.


Labels: , ,

Monday, September 15, 2014

Secure your AngularJS Apps with Spring Security and Spring Session


A few days ago I was in the middle of preparing for my Spring One 2GX 2014 talk Creating Modular Test-Driven SPAs (Slideshare) with Spring and AngularJS. Part of the presentation is a demo application I created called botanic-ng. This application uses AngularJS on the client side and Spring (Boot) on the server-side. As I wanted to not merely create a simplistic toy app, I also intended to add authentication and (simple) authorization to the application.

I did not want to go too crazy with this (e.g. implementing full-fledged OAuth 2.0 integration). Nevertheless, I wanted to add (I hope) some meaningful security features inside my AngularJS application.

Disclaimer: I am not a security expert. Proceed with caution as this solution may not provide enough security for your application needs.

By chance I came across a demo application that Josh Long created a while back. That application, while using Spring Security, did not integrate with Spring Security to the fullest extends, and I felt that I could improve upon that implementation using Spring Session which is new project created by Spring Security lead Rob Winch.

Spring Session

The Servlet 3.0 Specification (JSR 315) introduced several ways to customize the handling of session cookies, for instance changing the name of the cookie (from the default JSESSIONID) and providing additional security relevant settings:


However, you're still pretty much bound to using cookies in order to store your Session IDs. For cases where you need more comprehensive flexibility for handling your sessions, Spring Session comes in quite handy and provides numerous advantages.

By default Spring Session stores session information in Redis using the RedisOperationsSessionRepository. Sessions expire by default after 30 minutes but this can be customized using the setDefaultMaxInactiveInterval property. Beyond Redis a MapSessionRepository is also provided to allow for easy integration with e.g. Hazelcast.

For my use-case, I wanted to expose the Session ID not via a standard cookies but via an HTTP header. Luckily, Spring Session provides various pluggable strategies to customize that behavior. As Spring Session works as a Filter you have to configure a SessionRepositoryFilter. On this filter you can set the used HttpSessionStrategy. By default it uses the CookieHttpSessionStrategy. For my use-case, though, I am using the HeaderHttpSessionStrategy, which by default stores the Session ID in an HTTP header called x-auth-token (This is customizable though).

On the client-side in my AngularJS application, I am adding a HTTP header via $http to every request.

$http.defaults.headers.common['x-auth-token'] = user.token;

This is configured upon successful login through the LoginControllerBotanic-ng submits the login credentials to the server, which in turn uses them to authenticate the user using Spring Security (AuthenticationController) and if successful, the AuthenticationToken containing the Session ID and user roles will be send back to the client.

The Session ID on the client is stored in memory only and if you refresh the client, the user must re-authenticate.

For the full source code, please see: 




Labels: , ,

Saturday, September 13, 2014

Spring One 2GX 2014 - My session slides

Have not blogged in a while. Need to make a mental note to revive that. Just came back from Spring One 2GX 2014 in Dallas, TX. It's been a wonderful event and I learned a lot - From microservices to reactive streams. I also gave 2 presentations which I think were well received. For my AngularJS with Spring (Boot) talk I had 140 attendees, yeah :-)

Creating Modular Test-Driven SPAs with Spring and AngularJS



Spring Batch Performance Tuning


Labels: , , , ,