Monday, January 13, 2014

Developing first-class web applications (Part II)

OK, so now that we have realised that separating our front- and back-end code bases is the way to go then how do we do build the projects in practice?

First, we are going to need a build server and for this example I used the Jenkins service that Cloudbees provides.

As you see in the screenshot, I have two different projects, one for the front-end part and another for the back-end part. I have used 2 super-amazing MVC-ish frameworks: AngularJS for the front-end and Grails for the server-side.

Here is the front-end project configuration in Jenkins:

First we install Node, PhantomJS and Lineman and then we build the project using that. As explained in Lineman's excellent documentation, the spec-ci target will compile the app and run our tests using PhantomJS. The resulting assets are zipped and stored in the project workspace.

And now the back-end configuration:

As shown by the screenshot we copy the latest front-end assets into the current (back-end) project and then we unzip them to the web app directory before Grails builds the WAR file that will be deployed to the container by the build server.

Every time we build the client app, we trigger the back-end build project, effectively deploying our application in the cloud. We have now setup a basic deployment pipeline.

And that's it! A cloud-based continuous integration project that uses Jenkins and Lineman to build a rich client web application that is developed and built completely separate of the backend.

Links to the Git projects

Monday, January 6, 2014

Developing first-class web applications (Part I)

I recently discovered Lineman, a fantastic productivity tool that takes the pain away from front-end web application development.

Traditionally, at least for Java developers, the front-end part of a web application is just an obnoxious detail, an unpleasant experience that needs to be survived. The effect of this is that backend developers hate front-end code.

I believe this is not so much because of the language (usually JavaScript) but because of the lack of structure and other problems arising from not having a clean separation between the front and back end assets:

  • To be able to work on the front end you have to check out the whole backend project
  • The Javascript code is completely dependent on the backend running in order to run itself.
  • The Javascript code has no unit tests since it's not first-class.
  • The Javascript code is probably coupled in some way with the backend code so we can't easily make changes to the front-end without having to change something on the backend (or viceversa).
  • The front-end application is forced into a very particular structure that suits the backend application.
The downside of this is that client-side code is not given the same amount of care and attention that is given to server-side code. Typically, client-side code that is part of a server-side application is a big ball of mud without real structure and usually without tests. It is hard to understand or to change. 

Lineman allows you to build fat-client web apps and completely decouple the front-end from the back-end. In addition it builds assets, mocks servers and runs tests on every file change. It also comes with an API proxy that allows you to pair your client app with a server-side app whenever the development mock server is not enough. Yes, you can work with front-end code and not miss the server-side tools a single bit :)

Liberating client-side assets from the opinions of a server-side framework works wonders. You can now develop the front end in a much more agile way. It is much easier to give it the proper structure and write tests when the front-end project becomes first-class.

As an introduction to Lineman I recommend watching the following video with Justin Searls.

In the next post I will post the details of a small application that I built with Lineman using continuous delivery on Cloudbees.