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