Code only knows

Monday, January 13, 2014

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.

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.

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.

Monday, January 6, 2014

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.

So here's a small but completely functional application written using Angular and Twitter bootstrap. In less that 70 lines of code I managed to access LastFM's APIs and show the list of top artists by country returned from the service. From there we can navigate to see the top albums for each artist and the top tracks. Can you do that as easily with other frameworks? Maybe, but doing it with Angular was easy and fun. I really recommend AngularJS to anyone looking to develop a web based interface.

So what does the code look like?

In angular you start off defining your modules, some factories or/and services and configuring which URLs will trigger which controllers. You also define which templates will be used when a controller is triggered.

Angular provides nice AJAX abstraction in the form of a $resource service that provides means to interact with RESTful server-side data sources.
And now for the controllers:

As you can see each controller has its scope and you just inject the resources/factories/services that you have defined previously. This DI has the nice side-effect that it makes your code easy to test. Angular comes with some pretty serious testing facilities so now you can easily unit test your javascript code!

As usual here's the app in action on Heroku and the whole source code.

My version is querying Neo4j using Cypher which is currently slower than Gremlin which is the query DSL used in De Marzi's example. In the next major release of Neo4j query times will likely be much faster.

Tuesday, October 23, 2012

If you want to learn more about graphs or graph databases you might want to check out Gremlin.

Gremlin is a graph traversal language that can be used for graph query, analysis, and manipulation.

As a simple example, if we have this simple graph:

And we want to answer the question "Who are marko's codevelopers?" then we could write the following query in Gremlin:

That would give us "peter and josh"

With Gremlin it's possible to work with any graph (database) that implements the blueprints property graph data model., i.e Neo4J which is probably the most popular graph database right now.

The easiest way to start working with Neo4J is to start it in embedded more but a more production-like scenario would be to send Gremlin queries to a Neo4J server using the REST API and Spring's Neo4J template.