Hacker News Reader

Comment by folli | Hacker News Reader

If I want to build a web app from scratch which should have some basic features (user identification, some standard level of security, REST interface, database integration) and I have some okay knowledge of Java (mainly CLI applications and some Android programming), which framework would you recommend for me to get started? I'm afraid to get lost in the details too quickly, so a framework that provides a working example which can than be adjusted to my needs would be very welcome. Any suggestions?

View on HN

Dropwizard and Play are very good alternatives to Spring if you don't need the whole kitchen sink or you absolutely want to use X library for Y application function and Spring doesn't necessarily have very good out of the box support for said library.

The upside of Spring over Dropwizard or Play (or any of the lighter touch frameworks) is that it's so much more than an MVC or REST controller framework. The report in question is literally comparing it against the entire Java EE ecosystem. Spring is not a library or a framework anymore, it's practically an entire stack that you can pick and choose from.

Play and DW are likely to be easier to get your head around than Spring, there's a lot of magic going on in there and (not unlike getting into the JS world these days) you will find that setting the thing up from scratch takes a whole lot more time than you ever would have guessed. There's 1000 ways to do the same thing and sometimes doing it one way is a real issue later on, and worst of all it may not be apparent that that is the root source of some seemingly unrelated issue.

Spring Boot aims to solve a lot of that by taking an opinionated approach to how the project should be laid out, libraries, and default configuarations- more along the lines of a .NET MVC + database, etc. There's still the same amount of complexity and configuration, it's just hidden from you until you need to dig in.

I generally use Spring Boot to start greenfield projects these days, we deploy to AWS and their extra libraries for handling and working with that save a lot of boilerplate that's so common with Java.

I would suggest you get your feet wet with either GP or DW, but don't forget about Spring Boot down the road. I've gotten to the point where I've got a stack including Vault (secrets) + Spring Config Server (distributed config application) + a fleet of various Spring Boot microservices running in Docker on AWS and they (mostly) just startup and run the way I wanted them to. It's really awesome, and wildly overkill for that proof of concept API or personal project we would be doing a lot of, but allows me to run my company without a huge team.

Hi, I'm on the Play team. We've got a number of Play maintained example projects that show how you can configure different projects:

https://playframework.com/download#examples

Should save you some time if you're looking to get started with JPA, different libraries, etc.

Also, this doesn't really get at the strengths of Play as a reactive application. For example, here's a talk where I discuss using Reactive Streams with Play to stream video through Play. It's about two years old now:

https://www.youtube.com/watch?v=zUB7GJMe_WY

Thanks!

Play framework is easy to get started with if you just go by their documentation. I switched from php to play and was happy with the result. Admittedly, I did not try spring, so I don't know how it compares.

http://sparkjava.com/

Definitely not all batteries included, but a great minimalist web library to get started with.

Have been using Spark a lot recently. Very impressed. Gets out of the way and makes Java considerably less painful then it used to be.

I'd recommend Grails. https://grails.org/

You use Groovy, but it's pretty similar to Java and there's plenty of resources to bring you up to speed.

Grails 2.x or Grails 3 ? Many sites using version 2.x haven't bothered upgrading to version 3 in the two years since it was released, nor are there many version 3 plugins converted. And very few new Grails projects are started.

We use Grails for a lot of internal applications at our company, all 2.x (2.3.x through 2.5.x).

I can't really comment on Grails 3, funnily because the applications were written before 3.x came out and we haven't bothered upgrading them yet... :) I've only taken a brief look at what's involved in upgrading them, but other stuff has always been higher priority.

It's probably worth being familiar with both versions, because Grails had plenty of adoption before 3.x came out and 2.x is still being maintained.

This question usually comes from a person trying to build their resume. My suggestion would be to do a search for Java jobs in your area and see what other libraries they are using. That will be way more useful to you in the long run than learning what the HN crowd thinks is fashionable. In my experience around here that means Spring, but it could be different in your area..

Take a look at JHipster: https://jhipster.github.io/. Web application generator for the front and back ends using development best practices. Can be extended to be used with Docker, Kubernetes, and CI/CD.

Dropwizard http://www.dropwizard.io/1.1.0/docs/

Spring Boot.

I have been writing Java for 10 years now. I've used many different frameworks and libraries. But now all my new projects are Spring Boot projects.

Having used both I'd say JavaEE 7 is more concise and less complex of an API than the Spring framework. Unfortunately it's hard to predict the future of EE and its implementations thanks to Oracle. Spring uses some EE technologies and adds its own abstractions on top of them, which adds a whole layer of complexity.

My recommendation is Vertx.io

It is a very lightweight framework with support for most of the plumbing a developer might want without imposing its will on anyone.

If you are not that worried about having a REST or HTTP or TCP front-end, LMAX disruptor is amazing as well.

Have you ever made anything real with Vert.x? I found several aspects of developing for it problematic, such as it's rather odd module sysem.

I'd (of course for those who know me) suggest taking a little time to learn JavaEE (not J2EE).

I have had great success with the examples from TomEE (free) + the (paid) videos from Adam Bien (I normally shun videos but lke his).

The examples from TomEE often come in the form of something you can run with a single maven command.

Dropwizard is one of the simplest way to get started and remains well suited for larger applications:

http://www.dropwizard.io/1.1.0/docs/getting-started.html

Since ur not tied to the Java language (but want the power of the JVM platform) - I would say vert.x with kotlin.

I'd say Spring Boot. When you use JPA for basic data access, you don't have to have much in the way of data code. It's really easy to use Spring MVC for web front ends with Thymeleaf. It's really easy to make REST for when you don't want to render server side. All of this plugs into a free version of Eclipse called Spring STS. You can also use IntelliJ if you so chose. The nice thing about all of this is that you can simply deploy a JAR. No need for Tomcat or some other web container.

There is also a huge number of tutorials from the horse's mouth on the topic.

These are good answers but nowadays we would be remiss not to mention so-called "serverless" frameworks. Dropwizard et al are good suggestions for running your own instance, but more and more the serverless approach is an attractive alternative to implementing a web app.

AWS Lambda now supports Java, so perhaps we could consider API Gateway, Cognito and DynamoDB/Aurora as one of the new "frameworks". Google has their own competing offering as well, e.g. Cloud Functions. Firebase deserves a special mention as a rapid development framework, although at the moment it only supports Node.js. Like many frameworks it has pros and cons, but in my opinion full-on websockets support OOTB is a pretty cool pro.. especially since Lambda/Cloud Functions/FaaS can't do websockets on their own.

RE: AWS Lambda, there are a lot of shortcomings, the biggest is latency when it's cold. Another is duration, if your process takes too long and you can't break it into smaller steps (probably not a good sign, but still...) Lambda is no-go.

Configuration generally kind of sucks to manage, you don't get some of the role inheritance you can get from standard EC2/IAM, and forget running inside a VPC.

The idea behind using something like API Gateway + a Lambda for the various end points sounds awesome in theory, but going beyond contrived examples shows that we're a long way out.

There's a lot to criticize about running your own Dropwizard, Play, Spring and Java EE instances as well, including the same issue of management headaches. In fact one of the key advantages of the "serverless" approach is less devops management overhead. To consider running your own instance "management suckage free" but calling something like serverless.com a headache is definitely not an apples-to-apples comparison.

Cold start time is a known issue but frankly, not that big of a problem in practice for many apps. Definitely I feel that dismissing this out of hand (I even got a downvote) is more of an emotional reaction to something really different and new than a rational one. There's nothing contrived about implementing a REST service with FaaS -- it's just simpler. It's worth giving it a serious look even as an experienced Java developer (as I am). There are a lot of benefits to the architecture, like minimal devops and tremendous cost effectiveness.

I definitely didn't downvote and I agree that there are tradeoffs with any choice- but serverless doesn't mean Ops-less. I use Lambdas for lots of things, actually a lot of my Ops use Lambdas for various tasks (like SES catch all mail forwarding for example).

Don't think I'm dissing Lambdas (or anything like them in a non AWS context). There's a lot to love about them, not the least of which is that for small (in time to completion, request volume, and memory usage) units of work they are significantly cheaper.

There's a config management nightmare for everything but there are known ways to answer it for a traditional server/fleet approach. Run time configuration of Lambdas is still evolving and there aren't many options to choose from that are much better than just deploying the code and config as one as part of a delivery pipeline. It's workable now, but there are gaps. There aren't any gaps with running your own applications, it's literally what's always been done. There are certainly pain points, but the problem is already well understood.

Reply on news.ycombinator.com