I’m currently working with a company that uses Java / Tomcat / Spring for the back end of our web applications. As a front-end developer, I’m feeling more and more strongly that the back end should be a separate project from the front end, for a few reasons:
1) Building the project – many modern projects build with grunt and other front-end tools. The front-end build goals (concatenation, minification, front end tests, pre-processing CSS) are completely different from the back end goals (compiling java code, passing back end tests, deploying to a continuous integration server)
2) Deployment: When I commit a javascript or html file to our git repo, it doesn’t make sense that our continuous deployment tool should rebuild and redeploy the whole project, but it has no way to tell the difference between a front-end commit and a back-end commit.
So, how would you restructure a project that previously automatically deployed from a single war file, living in a single git repo, to make a separate back end and front end? Can I actually do this, given that we use Spring framework?
Right now, my files live in a mixture of the /webapp/WEB-INF directory (for html pages / velocity templates) and the /webapp/resources directory for everything else (js, css, images). I’m slightly confused about how I should go about this when tomcat deploys a huge bulk of files to the /target directory, as well? If I keep a separate git repo for front end files, won’t it be wiped out if I re-deploy the back end project?
(Originally I come from an Apache background, where it seemed so nice and simple…)
3
At jClarity we’ve definitely followed this approach. We have a ‘pure’ HTML5 front end – AngularJS, HTML, CSS and a host of Javascript micro frameworks which is a separate project to the backend – vert.x with a variety of verticles coded in separate JVM languages as appropriate.
The trick is to have a well defined messaging API between the two that is tested by JUnit/TestNG style integration tests (backend) and Jasmine/Selenium tests (front end).
It’s worked really well for us, great separation of concerns with the only dependency being on the messaging API between the front end and back end. We use a bit of clever Maven magic to check that the dependencies are correct between the two as well as end to end tests.
Despite an upfront cost in getting this all set-up, I’ve been amazed to see how quickly new functionality can be added with confidence using this structured approach. Even better, there’s no stinking UI/View logic in our server side code and visa versa.
So in short – I highly recommend it :-).
6