In this post, we are going to show how to use and build a friendship between the back-end and front-end. For the back-end, we are going to use Clojure (Compojure + Hiccup + Ring + Sandbar), and for the front-end, we are going to use AngularJS.
We are not going to explain how to set up a project and use both languages and frameworks, but how to implement and build the friendship of these two frameworks. Our idea won’t be based on building a monolithic application using AngularJS for the whole front-end while talking to the back-end using a REST layer or similar. Instead, we are going to use AngularJS for building small mini-applications that do something very specific, call it domain driven if you wish, while using the back-end for “glueing” the pieces together.
The benefits that I see using this approach are:
- We can use sessions, the front-end is a collection of small applications that are driven by the back-end.
- The back-end does not do all the job, we just route the user to the right place and let our friend AngularJS to drive from there.
- Since AngularJS is a front-end MVC framework, every mini-application will act on their domain expertise and call the big brother (Clojure) to drive/route after finishing.
- We use client-side routes and server-side routes. We will use the former to let the front-end take actions within their domain expertise area, and the latter to drive the application and glue together the different mini-applications.
- Mini-applications imply “divide and conquer” based on small domain-driven apps.
- Loading time is faster since you do not need to load all the JS files, just what you need, making the apps smaller in size as well.
For the back-end, we are going to use something similar to this script:
In this script we just created the handler in charge of taking the request and sending it to the right controller based on the url, a kind of dispatcher basically. We have added as well the sandbar session manager just in case you would like to know how to deal with sessions (function stateful-route).
After that, we are going to handle the requests in the controller (private.clj), where we are going to create two small domain-driven apps. One is going to be just the welcome page (in this case, simple HTML but it could also be an AngularJS app), and the other one is going to be a small app in charge of creating questionnaires (in a really basic way):
From the privateview.clj you should understand that we are going to load one or another view based on the function that gets called (since we are using Compojure as if it was an MVC framework, the controller wants to call a view). Both views have been created using Hiccup, although the one that uses AngularJS is the one that comes from the function new-questionnaire. Therefore, we are just routing the request to a JS mini-application that lives on the client side:
From this moment on, the application is managed by the AngularJS application, and the user has no interaction whatsoever with the server.
The questionnaire.js is just a really simple app that uses services, routes and two controllers, so nothing to write home about. For more information about how AngularJS works you can check their website. In our case, we have decided to use the service layer as an intermediate layer where we store the info:
So, when we finish the questionnaire, we click on the “Save Questionnaire” button, and the application will issue a POST request to the server, and redirect afterwards to another address, which makes the back-end being able to drive and route the user to the next domain / application.
This example is quite basic and at first sight might not make sense considering the effort, but I do really believe that when creating a real-world application you will have to deal with different domains, and, keeping all of them as if they were small applications, is a great advantage.
Thanks for reading and opinions are welcome!!!
P.S. I am going to create this example as a github project as soon as I have some free time. Meanwhile, I leave you the gist code which is quite complete although it might have minor errors.
P.S.2. Recommend reading: How Basecamp Next got to be so damn fast without using much client-side UI