10

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...)

StackExchange What The Heck
  • 328
  • 1
  • 3
  • 14
  • why did you change question title? "separating" felt okay, "ideal" sounds rather subjective – gnat Dec 30 '13 at 12:12
  • 1
    I think I thought it might catch more eyes with the second. I'll change it back if you think it's better :) – StackExchange What The Heck Dec 30 '13 at 12:14
  • 3
    yochannah - "ideal" and other absolute qualifiers are generally red flags that a question isn't well formed or that the problem isn't understood. That's because the ideal rarely exists within development. –  Dec 30 '13 at 13:17

1 Answers1

14

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 :-).

Martijn Verburg
  • 22,006
  • 1
  • 49
  • 81
  • I'm intrigued, could you tell me more? Specifically, where does the front end reside in relation to the back end? Is it served by tomcat or another server? – StackExchange What The Heck Dec 30 '13 at 13:12
  • Front end is also hosted on a verticle (as such). Vert.x has this really nice concept of a shared event bus all the way to the browser (we use SockJS on the frontend to send/receive events from that bus). – Martijn Verburg Dec 31 '13 at 10:03
  • @MartijnVerburg, can you share a link for example project for the same, so that i can understand it better. Thanks – shizan Dec 22 '16 at 13:51
  • Take a look at a sample project from the https://jhipster.github.io/ framework - that's probably the easist place to start. – Martijn Verburg Dec 23 '16 at 14:02
  • How did you manage authentication. I want to recreate your project structure, but our current company has JOSSO auth. From JOSSO login I would have to redirect to the SPA page, served in another war. – dantebarba May 11 '18 at 18:28
  • Authentication for us is OAuth via Okta which is well supported out of the box by the Vert.x framework – Martijn Verburg May 13 '18 at 08:23