While traditionally a C and Python guy - I've had to use Java a lot over the past few years and have come to like it for various reasons and am thinking of starting a new project/product/service with Java.<p>I do have a question how people in the rapid development segment (read: startups) architect your application?<p>Of course I will have a web interface, but I also feel that the web interface is just one interface, and as a whole its not a web application. I see a few options:<p>- Give into the web app frameworks and develop as war for deployment into a container (or turn it into an executable war)<p>- Embed Jetty or Tomcat and treat it as a module of my application. I feel this gives me more control over the web server component.<p>- Take on more overhead.. Develop one project which is the business logic. Then do a separate application that communicates to the back-end somehow.. ZeroMQ, or perhaps REST - but then I'm dealing with a web tier again. But maybe my web tier on my back end service can be simpler in this case.<p>Thanks for any thoughts.
Architecture and MVP I setup for a startup:<p>- database: PostgreSQL<p>- API server: JEE6 app (EJB, JPA, JAX-RS, Jackson, Jasypt)<p>- Web server: JEE6 app (JSF, Primefaces, PrettyFaces, Jackson, commons-http)<p>All packaged with maven, and deployed on two glassfish instances on a dedicated server, but it could have been deployed on the cloud with Jelastic.<p>Better that embedded Jetty/Tomcat, you'd better use a more classical approach to remain compatible with the hostings providers. Also targeting a full JEE6 server is not insane anymore (light for some values of light, fast, well documented)<p>Please, make an API server, even basic, from the start and keep the web front-end as much stateless as possible.<p>Shameless plug: I'm a freelance, I rock in JEE6 and I'm a Ror padawan.
The most important thing is that you separate the different layers of the app so that you can refactor later. Using Spring is a good way to keep that separation.<p>The frontend layer needs to be agnostic of how the middle layer is implemented, and the middle layer agnostic of the backend.<p>JSON and REST are universal, so if everything communicates using that, you are in good shape if you ever partner with other companies or get acquired.
It really depends on what you want to do, and/or what the scope of the project is. If it's a self-hosted blog, I would personally think that a WAR would be hugely overkill (ignoring that Java might be overkill altogether anyway). If it's for a project that you intend to sell to Enterprises though, a drop-in WAR is a huge benefit.<p>If you're planning to build the front-end with a lot of JS or Backbone-style interaction, you'll want an API anyway, so you might go with the last method of developing REST endpoints and just accessing them via JSON and Backbone. (This is the approach I'm taking on my most recently project, though Python is the backend, not Java).<p>Without knowing the scope of the project, whether there are customers, what kind of customers they are, etc., it's a little hard to make an informed decision, however one thing I didn't see was Play[1]. The last Java project I had was done in Play and I found it pretty easy to get up to speed on, and it's designed to act as a web framework. If you're looking for something new to learn, or an easy way to transition from systems development to web work, Play might be a fun transition for you.<p>[1] - <a href="http://www.playframework.org/" rel="nofollow">http://www.playframework.org/</a>