Ask HN: How are you setting up your Java applications?

Architecture and MVP I setup for a startup:

- database: PostgreSQL

- API server: JEE6 app (EJB, JPA, JAX-RS, Jackson, Jasypt)

- Web server: JEE6 app (JSF, Primefaces, PrettyFaces, Jackson, commons-http)

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.

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)

Please, make an API server, even basic, from the start and keep the web front-end as much stateless as possible.

Shameless plug: I'm a freelance, I rock in JEE6 and I'm a Ror padawan.

+1 on Postgres. But JEE ? I'd prefer Tomcat anytime over JEE (even if they became "simpler") in the past.

Apache, Tomcat, mod-jk, JSON/REST and loads of freedom...

I was like you a long time ago ;) I hated JEE until I used JEE5 in a project with really good programming peers. Once you understand and adapt to the JEE vision and do not fight it, life is more beutifull.

If a lightweight is needed, Nginx+Jetty or Resin is imho better that Tomcat ... until you need to coexist with an app that's Tomcat friendly.

I appreciate your excitement. But what I've seen over the years will keep me resistent for the rest of my life ;)

agree on tomcat vs jee but I really don't care for apache, unless they changed their implementation since I last checked... the whole epoll thing is just too exciting

With 10+ years experience optimzing/scaling PostgreSQL I wouldn't go for anything else. It also has me hesitating to use anything like JPA - Springs JdbcTemplate is about all the abstraction I can handle. But this is the kind of answer I was looking for.

In theory your JEE6 apps could be the same right? Why separate? For separation of concerns? Future scaling?

Why JEE6? I'm not familiar with JEE.. But haved produced quite the many APIs with SpringMVC/Jackson. So was thinking of going that route for now.. Even using JSP for basic pages - since modern web pages seem to be more client side anyways, I figure fancy server side templating is becoming less important.

At any rate, I think I need to soften up my stance on wanting my app to contain the web server (container), and let the container contain my app. Java life will just be easier that way!

If you don't cleanly separate, the day you'll want to write an another client (Android, iOS) you'll loose a lot of valuable time refactoring or worse, duplicating code. Separation of concerns is a good reason, too.

Spring MVC is also fine, in the end what's important is what we're effective with. I prefers to use standards, thought.

An anotehr reason to use a container: you won't mess with the configuration in your code. Normally, you just use JNDI name for resources lookup in you app and let the container admin manage these resources (configuration of the db, db caching, javamail conf, etc etc). A kind of another separation of concerns.

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.

The frontend layer needs to be agnostic of how the middle layer is implemented, and the middle layer agnostic of the backend.

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.

nginx->jetty->java->postgres with json+rest is a solid start

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.

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

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.

[1] - http://www.playframework.org/

I developed some test APIs and played with WebSocckets in play. One thing I didn't like, is like a WAR, it wants to be first level piece of software. However, I think this is an attitude I carry from embedding web services into projects years ago.. And I need to give in and develop things as web apps.

Scope is a service.. User interface for reporting and graphing, and an API for punting messages around (not instant messages or anything like that). And a database. And servers in the backend will need to talk to other peer servers in another data center.

Thanks for your input.