I second Play Framework. Have used it and Scala is a very nice language to learn. If I had invested in so much into the JVM, Play Framework would be it. But, if it's just a simple CRUD app, and if you had a choice, I'd recommend you to give Ruby on Rails a try. Hope this helps!
I agree.
And I'd add that the continuous compilation of the Play framework allows for a great, fast workflow. Even in combination with non-JVM compilation like for Typescript.
The last version comes with Slick integration which brings Ling-for-Sql style persistency to the JVM. In combination with support for Postgress JSON persistency that makes for a great fast prototyping stack.
I highly, highly recommend squeryl over slick. Much more readable as you're basically writing SQL in scala; you don't have to translate constantly between orm methods and SQL.
I agree with Play/Scala combination. Play is light enough for simple tasks, but at the same time it's a feature-complete powerful beast - built on Akka and capable of potentially handling millions of requests.
+1 for Meteor. We've been using Meteor for about 8 months now and are amazed with the productivity and no-boilerplate code. To give some context, we were previously a JVM-only shop. In the past we've used Spring+Hibernate+GWT for one project, Ninja for another project, and a full blown custom stack + Dojo client side in a third project.
If JVM is your only choice because you want to connect to legacy Java API, consider wrapping the Java API with REST interfaces and use them with Meteor.
TBH, we didn't have to do much performance tuning. The Meteor app we are building is heavy on the database CRUD (like real heavy) so there is not much to tune code-wise other than define good data structures for your db. And really, if you have to do any GC tune up for your node app, you really have to ask yourself if there's something you could do instead in your code first.
I must admit that initially it seemed that node js profiling sucks, but it's just that we are still not used to the internal intricacies of V8. When we did profile a couple of times (we use Webstorm so just used flag in the run config), there were too many things out of the context of our code showing up. I think if you show a snapshot of YourKit to someone who hasn't worked with JVM before they would have a similar reaction.
If you're looking for a Play-like framework but that's just Java, not Scala, you could check out Ninja Framework. I tried it for a simple CRUD app last year and it worked out pretty well. It's not as widely used or as maintained as Play though (+Play does have a Java API).
Glad to see support for Scala/Play sprinkled throughout the responses here. I love working with both. Now I'm considering taking the next step and adopting ScalaJS for some small internal apps.
I don't agree because 1. Play!2.x is asynchronous, and you need to find NIO-compatible libraries, 2. I like Jersey for REST resources better than Play!2.x's "routes" file. I had to build a stack this year for an app which needed to share code with another Spring app. I've chosen DropWizard because I could share the Jersey resources and I didn't have to learn everything again.
You do not NEED to find NIO libraries. It sure helps, yes. But it comes with a wrapper of a webservice library, and slick does the RDBMS nicely (and offshoots like phantom to do cassandra, etc).
I used to be a big fan of http-kit, but it seems like it's not maintained anymore. I've since moved on to Immutant 2, which seems to offer much more. The primary difference between Immutant 2 over 1 is that it's not monolithic and you can just import what you need. And I believe it's faster too.
I can personally second this. It is pretty quick to get a micro service up and running with Clojure. My team has been using the Duct[0] generators which set up a nice scaffolding. It also includes some decent examples writing components, models and endpoints. Plus swagger is free out of the box.
What parts of CRUD does it help with, does it have say an ORM (or equivalent way to interface with a database) and some sort of default interface so the user can work with it?
Spring MVC + Hibernate. I'm familiar with those libraries and they provide almost everything I usually need.
For frontend I would choose either JSP or Thymeleaf, both are good, depends on your taste and whether you're writing HTML markup. Another option is a JavaScript-powered SPA website. You have plenty of choices there.
And I highly suggest using Intellij Idea Ultimate + JRebel. Those technologies provide tremendous productivity boost and I can't imagine working without them. Though they are not free (AFAIK you can get JRebel for free).
For people whose impression of Spring and Hibernate was formed a decade ago, its really worth another look now. You can completely manage them with annotations in your code and lots of the boilerplate will be generated for you based on naming conventions.
JHipster (https://jhipster.github.io/) provides a Yeoman generator to make a basic project template as well as generate entities and screens using an Angular, Spring Boot & Hibernate stack which makes it super easy to get started with all of these components.
An open source alternative to JRebel is https://github.com/dcevm/dcevm - it works great with Java 8, Intellij, Spring & Hibernate.
Actually the example I was thinking of is the finder methods which require only an interface definition conforming to a naming convention. Bytecode is generated at runtime - there is no generated source to manage.
Not much of what Jhipster generates could be considered boilerplate - the application code is pretty DRY. I've used Rails off and on since 2005 and it is fairly comparable in that respect at this point though Java is more verbose of course.
It's difficult to take Spring seriously after trying Jersey. Resource traversal is a powerful concept. Also, recent or not, Spring still comes with way too much complexity and magic. I'd really go for something more Sinatra/Flask-like. Haven't tried Dropwizard, but from what I saw it looks a lot more sane.
> It's difficult to take Spring seriously after trying Jersey
I'm using Spring Data REST at work. We have a dozen endpoints. We've had to write code for one of them.
The rest were generated by introspecting our models. Complete with HATEOAS links, sorting, searching, paging and HAL. It made a whole bunch of work simply disappear -- even compared to Rails.
I attempted to learn Spring framework about a year ago since I wanted to build a quick CRUD app on the JVM too. However, I found the Getting Started guides really difficult to learn from. In addition, I found myself quite confused as to which templating engine to use and how to use it in Spring. I stopped working on CRUD for other reasons (pursuing an MSc where I mostly wrote C code).
Yep, similiar situation here. The getting started guides often just introduce a single concept and stops there. Many seems outdated as well. However, Spring Boot with whatever DB choice you make is a winner imho. Found it really easy to get going after just investigating a sample project.
Yeah, as long as you go with Java 8, then I think the Spring+Java app is still a viable and also pretty powerful option. Although I disagree about Hibernate as I've found it ends up causing a lot more problems than it solves in the end.
Java + Spring is still a very safe (albeit boring) option for a lot of different types of web apps today.
+1 for getting rid of hibernate (and JPA et al). We've been mucking around with JBDI recently it really seems to work well. We haven't done anything extravagant yet, but initial impressions are good
Spring Boot backed with Postgres and Maven to wrap it all up. Spring Boot is really years of distilled knowledge of creating web servers in Java. Its opinionated but for good reason; you'll very quickly get everything you need for a RESTful API and there's extensions for almost everything you'd need. Need to work with websockets? Just add a few lines to your POM. Need scheduling? Include an annotation on your main class. It really is a solid framework.
I don't understand the question, beyond the fact that Spring and Grails both had the same corporate sponsorship at one point in the past.
Spring Boot is a rapid, flexible, and fairly tight (as far as Java frameworks go) foundation for building Java applications. Grails is a Groovy-based wrapper layer around Spring and Hibernate.
So if you want to use Groovy for application development, then Grails is certainly there for you. However, I don't think it's the most competitive option. I think Groovy's great as a scripting language, and I use it for things like automated testing, but I wouldn't enjoy using it for primary application development because it's not a statically-typed language.
Although recent versions of Groovy allow you to designate typesafe "areas" within your code, it is still fundamentally non-typesafe. Because of this, tooling is always going to be weaker than it is for typesafe languages. IntelliJ is probably the best Groovy IDE out there, and it's still frustrating to work with because it can't detect autocomplete options most of the time.
If you're doing development on the JVM in the first place, then odds are you favor static typing. Plain Java, or Scala, or most of the fringe options like Kotlin or Ceylon. If you're in the minority camp who want to use a language with dynamic typing, even THEN there are better options than Groovy for application development. JRuby has a much broader and more active community, and Clojure will give you more "Internet cool points" on HN or Reddit or wherever.
Finally, the last time I looked at Grails, it was FAT. Building an application took forever. I'm sure they've (hopefully) optimized or rebuilt things since then. However, since it's a wrapper around Spring and Hibernate, it's never going be any lighter or faster than Spring and Hibernate.
I don't mean any disrespect to Groovy. I've been using it forever, and it comes in handy with certain use cases. However, it's primary niche is being the dynamic JVM language that most "enterprise" shops have become comfortable with... and so if you're trapped in an "enterprise" shop and are dying to use something other than plain Java, it's the thing you'd most likely be allowed to use.
I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible.
Just because uncle Bob says something doesn't mean it's true.
Frameworks and stacks provide templates for building CRUD apps. Building CRUD apps (read: database skins) isn't a big technological challenge most of the times anyway. So picking a stack that abstracts most of it for you could be a great help to only focus on the parts you care about.
Not every project requires astronaut architecture and grand design. Half the internet runs perfectly fine without these considerations.
Scaffolding a project through the tooling of a framework (tooling matters!) and having something up in a day instead of philosophical debates about your data is huge. Having something up in production super fast because you didn't stop to think about architecture is perfectly fine for 95% of software projects that are just CRUD.
It seems to me that you intentionally misrepresent the argument to make it easier to attack. No one is claiming that Uncle Bob is always right or that an "astronaut architecture" is the correct design.
On a different note, I would also recommend to not start picking the framework or stack: Instead I would start by creating a couple of basic classes that represent the business logic.
I would also write tests for those classes. Furthermore I would probably introduce some repository classes that would interface with the database. Lastly I would try to find a library that handles HTTP routing - if the CRUD app was meant to have an HTTP I/O channel.
Not everyone wants to "go fast and break things" or blindly let their codebase depend on a third-party framework. This is usually what ends up happening when you don't think about architecture.
Check out the most popular Angular posts on HN this year [1]. Notice a trend?
I would start by creating a couple of basic classes
How would you do that without deciding on a language/framework?
Suppose the goal is a shared calendar and message boards plus some way to buy ski passes. Doing this using SharePoint is going to be vastly different than Ruby on Rails.
My inclusion of these two reading resources were only meant as examples. The reader is still required to make their own mind up.
I haven't suggested astronaut architecture; the question didn't indicate the size/scale/importance either.
50% of the internet runs perfectly fine without consideration...wow! Have you looked at all the source code yourself to make such a ridiculous conclusion.
Tooling does matter, but I'm suggesting the point of focus to start with is the requirements.
As a data point, 20% of the internet runs WordPress [1], think these people spent a lot of time thinking about architecture.
A lot of time the problem being solved is in fact simple enough and easy enough to solve without thinking about architecture, not everything is a hard problem - and there is nothing noble about solving things over and over.
The point I was disagreeing with was "Pick stacks as late as possible". If you have a large project by all means do that, if you're just building a REST API in microservice architecture, or you're building a blog or something that's fairly simple to model - you're perfectly fine picking a framework you like first.
I'll skip the flame about WordPress developers as I don't know any, or, viewed their work.
If you think building micro service architecture can be done without consideration I'm lost for words.
The question–as I've been rightly reminded–was 'CRUD Web App in JVM'; furthermore, we now know that the domain part of the application is already done, so my comment is moot.
Yes/No, depends on many factors IMHO. Mostly on the person/team that needs to build/use it.
We know nothing of OP's case so the best thing we can do is trying to answer his question instead of answering to go read some lengthy book.
OP might be in a team that needs to develop an API for a product that will be deployed to millions of people(I doubt it) or could be someone that just wants to know what is the current fashion to develop a CRUD application while learning a new stack that is up to date.
In the first case, you might want to learn more of the situation you are in and pick around that. In the second case, there is nothing wrong with just picking one and hacking away.
That is more than sufficient to pick a framework/database and start working. I'm not sure how many simple CRUD apps you have built, but the challenge tends to come when you put them in front of users who can't figure out the interface. Consequently, I'd argue to choose a framework quickly and get it in front of a user as fast as you can.
For context, I already have a JVM application that handles the business domain. Adding a CRUD user interface (and, coincidentally, a database) is the next step I have in mind for its development. However, I didn't want to state those constraints in the OP because I wanted the answers to be broadly applicable.
> I despise writing a bunch of dao/repo code, so I've resorted to codegen-ing my daos/repos.
Spring Data does this very well, in a fashion partly inspired by ActiveRecord. You define a Repository interface with whatever search methods suit your case; a concrete class is built and injected for you. The same interface can back onto JPA databases, Mongo, Redis and I forget what else.
If you add Spring Data REST, you get a complete RESTful API -- complete with HATEOAS, paging, sorting, searching and HAL -- automagically.
Use Spring Boot and you won't need to do any more than include the dependencies in your Maven POM or build.gradle file.
By future-proof I didn't actually mean forever. It heavily makes use of es6/es7, so it was designed with "forward-thinking" design choices (forward thinking is what I intended when I wrote future proof). Right now it relies on babel, but as es6/es7 gains adoption it'll grow out of requiring it. Similar to Angular 2.0, which is also being developed with a forward thinking mindset.
I used Scalatra on one other project, and I found it to be difficult to deploy. Whether it's true or not, my impression is that Spark is a little simpler to use and deploy than Scalatra. Scalatra is my second choice though.
Probably playframework [1] or maybe Spark [2] if it's a really simple app, along with jOOQ for persistence [3]. If I was just writing a REST API, then Dropwizard [4].
The reason I would not choose Spring despite the fact that it is better now than it was 10 years ago is because it still approaches things with the wrong mindset, IMO. The reason JVM technologies are so loathed is because of the stupid, pointless complexity that's so pervasive, where Spring is/was the poster-child. Building generation after generation of newer APIs on top of the old stuff doesn't remove the fact that the old stuff is still there. Hiding complexity with code generation doesn't remove the fact that code still needs to be generated. And the same with annotation driven programming. And JPA/Hibernate/etc.
Simplicity isn't about hiding mountains of legacy complexity under a shiny new API, or annotations, or code gen - it's about having a stack that is understandable and easy to use from top to bottom without requiring magician's toolbag of tricks to hide the complexity. I get the feeling that most JVM developers don't even know what this looks like - Dropwizard is a great example. Other languages/ecosystems tend to not have this legacy baggage, so you can't blame their developers for thinking that the mainstream JVM frameworks are ridiculous. Because they are.
For anyone who still thinks it means loads and loads of boilerplate code but wants to check, read Adam Bien, check out the TomEE examples, the Wildfly examples etc.
This is so true! ... I was ready to give up on J2EE (prior to the name change and version 1.5). Java EE 7 is wonderful and more tools are coming. It's no longer an XML configuration nightmare with 10 classes to define all the required interfaces and implementation.
To reduce even more boiler-plate, I've recently started using project Lombok [1]. Code generation provides all the standard methods and allows JPA @Entity objects or JAX-B objects to be completely declarative. Start with @Data and @Value.
My argument isn't about using tools that reduce boilerplate through codegen or annotations, it's to use tools where boilerplate doesn't exist. Why do you need JPA? Why do you need EE? Chances are, you don't.
I'm guessing you like annotations because they're less painful than what you were used to previously. You don't need an EE server to serve up a basic web app. Or even a complex one.
Indeed. I recently received a pull request to swap Hibernate into a Dropwizard project with a relatively simple data model that was operated on by some simple JDBI repository implementations. The pull requester obviously spent a lot of time on it, and I felt bad rejecting it, but in total the Hibernate impl would have added several thousand lines of code to something that worked perfectly fine as it was. I really don't understand the need to use complex things just because they're popular.
Groovy / Grails. It's what we chose to base all of our products on and it has worked out really well for us. If there's any complaint / negative, it might be that the ecosystem is in a bit of a "state of flux" with Pivotal dropping support for Groovy and the language moving to the ASF, etc. One bit of fallout from that, for example, is that the GGIDE isn't available for Eclipse Mars yet (or it wasn't last time I looked).
Still, it works, it's easy to learn, there's a rich assortment of plugins for adding functionality, GSP's are nice, it's easy to make custom taglibs, etc., etc.
I'm hoping v3 support turns a corner soon - IntelliJ 15 public preview now supports Grails 3. I'm thinking this may get more people back in to it, and more contributions back. It's been in a limbo state since April, and seeing jetbrains support it (finally) gives me more reason to continue to support it.
I would have agreed till Grails 3. It doesn't work in so many different ways and it's never clear why. The reload stuff seems completely broken if you have dependencies that use many Java 8 features.
Many of these suggestions here sound really complicated.
At Addepar, we use plain Java. A REST API can be served with Jetty + Jersey. We have zero XML configuration of any kind. JOOQ for DB access. HikariCP for connection pooling.
Use Postgres, if possible.
Start with the data models and keep it simple. Favor composition over inheritance. The inheritance-heavy Java you see in old parts of the standard library and certain "Programming 101"-type courses is really bad, in my experience. Use Java 8. Modern Java can be v clean.
If you're starting a new project, use buck as the build system. At Addepar, we migrated from Gradle to buck, and our builds became less flaky and 2x-5x as fast. The build files are cleaner and more concise.
Composition is very comfortable with Kotlin. I think one of the reasons why inheritance is used so much in Java, is that composition always leads to a lot of boilerplate code. Kotlin (and Scala) fixes it.
Grails/groovy with postgre. Grails is so ridiculously simple to set up and code with... you can literally parse JSON out of a request and map it to an object with "Object yourObject = request.getJSON". Then you can save it with another line like "yourObject.save()".
Honestly it blows my mind why more people don't use it. Grails wraps Hibernate/Spring, the two most robust java abstractions that exist. Then, it adds the out of the box ability to do things like parse JSON, re-direct, handle AJAX calls easily, manage session object, ect. ect. In my experience coding web apps there is nothing that even comes close to touching the simplicity of Grails.
Obviously I was unlucky : my experience was things didn't work and was next to impossible to reason about. This was 4 years ago and I went with (and burned myself on) Play Framework.
And to go even lighter I use pippo(https://github.com/decebals/pippo). I like the modular way that allows me to tailor my apps to be <1MB final size. Really helps with lightning fast deployments on my many DigitalOcean smallest 512MB instances.It also works great on raspberry pies - I was using nodejs webapps until pippo because they were lighter on resources(I rather hate js and nodejs and hence the praise for pippo) .
I also pair it with jooq for db access when needed.
I'm trying pippo for the last couple of weeks, its quite lightweight and really fast. I could customize it for whenever the need arises, better than sparkjava. For eg: I couldn't customize the Jetty server params with sparkjava, I could with pippo.
Unfortunately the actual documentation of Pippo it's a little bit behind of the implementation (from documentation are missing some nice concepts: named routes, finally filters, custom route context, ...) and from this reason I cannot give you more useful links but I will fix this aspect asap.
Another difference in Pippo to other (micro) java web framework (spark, ninja) is that a RouteHandler it's a real endpoint (the handle method return void). You can finalize/commit the response using send, render, redirect. Everything is transparent.
The need for codegen to approach LINQ-level magic on the JVM is unfortunate, but jOOQ is killer compared to the JPA/ORM bloat that most folks can't seem to stop themselves from using.
Definitely Spring Boot with spring-data (if it supports your database/nosql system) since you're going to do a CRUD app, it will manage a lot for you. Add it spring-data-rest and you've got your models exposed on REST for free. If you want to secure some REST operations, spring-security got you covered.
Then on the client side you can add some hype using React or what's hot at the moment. Joke aside, on the server side Spring is solid, the whole thing is well engineered and it got you covered on every aspect of this kind of app, and then more.
Probably start with `rm` of the current project and start over with something else.
I call it rm-driven development. It'll be a thing in a year.
In all seriousness, I'd probably look at Scala and Play if JVM was absolutely required, but I'd first look into why that requirement is in place and if the requirement can be removed.
I've used all the technologies in DropWizard, but not DropWizard itself. I do think their project is on the right track and pretty much my ideal solution.
But because they've designed a one-size-fits-all stack for any project, it looks overkill for a lot of apps. I.e., you can just use plain Jersey+Grizzly/Jetty+Freemarker.
I've been meaning to put a simple project together which ties all those into a functioning web and app server. The trick to turning Jersey into a web server (for static files) is along the lines of this: https://github.com/MachinePublishers/ScreenSlicer/blob/maste...
I've heard good things about it, but my understanding is it's ideal for creating REST endpoints, so it doesn't have some standards MVC stuff out of the box. Spark is a JVM version of Sinatra which may be closer to what you're looking for.
If you can render HTML in responses and accept multipart/form-data in requests, does Jersey become an adequate MVC framework? If not, what is it missing?
Grails hands down. I work on an enterprise team and every time we pull a developer in who has no experience with it they fall in love. It's just so easy to work with. We spend maybe 2% of the time configuring something and 98% solving the business problem.
I actually did this. Our main app is a rails app with MRI, which has worked well but comes with a bunch of opts complexity (even with heroku / AWS you're still setting up background workers, caching, queues, etc).
We built an internal webapp using torquebox (http://torquebox.org/). It's kind of a weird project (run your rails app on JBoss of all things), but it's actually worked out wonderfuly for us. I know it's all the rage to build your app out of a bunch of separate services right now (and the next version of torquebox is split out into smaller pieces), but for our small team wrapping all the stuff you need for an app up into one box has been great. Torquebox gives you:
- In-memory cache
- Message queue
- DSL for defining services (can be singletons or not) which torquebox will ensure are running. Your services are plain ruby classes but they can access to your rails environment.
- Threads! Coming from MRI it's really nice to "background" some things via threads.
- Mount other rack apps at "/app" and they share the environment (e.g., queue)
It's been running rock solid for a year with basically no ops maintenance. I'd encourage anyone building webapps to read through the torquebox documentation, it's clearly written by a team of people with experience deploying and maintaining "serious" stuff.
Clojure on the back end and ClojureScript on the front end.
Some reasons:
1. It's a proper full-stack solution. You can share code between client and server if you need to.
2. There is some amazing front end technology (Om, figwheel etc.) that can change the way you think about front end development.
3. It is hard to match Clojure for productivity / interactive development. You can code almost everything at the REPL without restarting (no restarts or edit/compile cycle time needed)
4. You can use all the Java libraries very easily (although idiomatic Clojure wrappers exist for almost everything you are likely to need)
5. The usual Clojure reasons: functional programming, concurrency, immutability, Lisp macro etc.
Grails, I really like Groovy as a language. Grails provides a lot out of the box and is good enough performance wize for small to medium sites with no tuning.
Meh... vorg posts on nearly every thread that mentions Groovy and rants about all the perceived wrong-doings in the Groovy community. Some of his points have some merit, but he seems to tend to make mountains out of mole-hills.
You didn't comment on any of the specifics mentioned in that linked-to comment, instead you attacked my behavior, just like one replier to that comment.
You mentioned Groovy moving to the ASF in another comment above, but if only two people control the DNS name and physical access to that server in Germany hosting the websites, receiving the Nabble mail archive and Apache website redirects, creating the phantom downloads from Maven and Bintray, etc, then the list of committers and mentors at ASF for Groovy is meaningless. Because Groovy isn't really protected by the ASF guidelines, its future is uncertain.
As for Grails you also mentioned, Grails 3 also has an uncertain future, what with so few people upgrading from version 2, just like with Python version 3. Grails 3 bundles all of Gradle, and its business case seems less about modernizing Grails 2 than about its founder wanting to muscle in on the Gradle consulting market, just like he did with Spring in Grails 1, until SpringSource bought his company to protect their cashflow. He's trying the same with Gradleware.
instead you attacked my behavior, just like one replier to that comment.
Have you considered that your behavior might be at issue then? Seriously man, you seem to go out of your way to find any and every thread that mentions Groovy in any way, and then launch into your rant about all the evils of the Groovy community.
The thing is, I said that you have some merit in what you say. But the repetitiveness and the vitriolic presentation make you look like somebody who has an axe to grind or something, instead of a dispassionate observer.
You mentioned Groovy moving to the ASF in another comment above, but if only two people control the DNS name and physical access to that server in Germany hosting the websites, receiving the Nabble mail archive and Apache website redirects, creating the phantom downloads from Maven and Bintray, etc, then the list of committers and mentors at ASF for Groovy is meaningless.
When existing, long-established projects move to the ASF, they always deal with shit like this. It takes time to sort this stuff out, that's why there's an incubator. And if it doesn't work out, then so be it. At that point, I'd reconsider my position of advocating for Groovy. But I'm not going to rush to judgment and focus on all the negatives, which is what you seem to do.
> you seem to go out of your way to find any and every thread that mentions Groovy in any way, and then launch into your rant
The most significant thing you've really said here is that I generally post comments under my own name, as I suspect you also do, given how active your "mindcrime" user is and the implicit assumption in your above comment that you're seeing the entire picture by looking at who's posting comments. Have you considered that other "entrepreneurs" involved with Groovy keep hundreds of HN logins each to obfuscate their mischief here and engage in illicit surveillance of people whose comments they don't like? This I don't say in my comments, instead I keep what I say seemly and do it in my own name. It's because I use my own name that I "seem to go out of my way to find any and every thread ..."
Have you considered that other "entrepreneurs" involved with Groovy keep hundreds of HN logins each to obfuscate their mischief here and engage in illicit surveillance of people whose comments they don't like?
Honestly? No, the thought never crossed my mind. And now that you mention it, it doesn't sound terribly likely to me. Not "hundreds* of such people anyway. Maybe two or three. Why do I say that? Simply because Groovy just doesn't come up that often to begin with. And a decent percentage of the time, when it does, I'm the one bringing it up, and know where I stand. And while "mindcrime" clearly isn't my birth name, my HN account is clearly linked to my real world identity, so no one can really claim that I'm trying to hide anything here.
One other person here to mentions Groovy / Grails occasionally is @mgkimsal, and I also know him in the Real World, and have no suspicion that he's up to anything nefarious.
That said, people never cease to surprise me and clearly some people post on HN largely for commercial gain. I don't think anyone questions that. I just don't see what you seem to see, in terms of large numbers of users here trying to manipulate the discourse around Groovy in particular.
> other "entrepreneurs" involved with Groovy keep hundreds of HN logins each
> post comments under my own name, as I suspect you also do
I would agree probably 2 or 3 people -- I never said "hundreds" of people, and I specifically said you post comments under your own name, not the opposite.
If that's only me or me and a few experienced Scala developers I would use more cutting edge stuff - Akka HTTP. If the team is less experienced or have more experience with traditional web apps - I would go with Play framework. It's well supported, not difficult to get into.
A nice complement to Akka is Spray.io[1]. Not really meant for CRUD type apps that is the subject of the original question, but very well suited for REST systems.
As redtuesday correctly noticed, Akka HTTP is a successor of Spray.io. Mathias Doenitz, the main author of Spray.io, worked on Akka HTTP as well. They are similar in many places, just powered by different "engines". Akka HTTP is built above new Akka Streams, while Spray.io is powered by plain Akka. But, for example, routing DLS is very similar. Our main API is in Spray, but when I tried Akka HTTP for a new microservice, I actually reused most of things from our customised stuff above Spray.
Akka-http is basically the successor to spray if I remember correctly. At least I believe jonas boner said so. Not sure I would invest much time in spray at this point in time.
Slick has a bit of a learning curve, but it's really a thing of beauty once you figure it out. I never make syntax errors in queries any more. Getting the code generation from the DB model going is a must. It makes things go really fast, especially for a large data model.
First of all, I have to agree with dommer. You pick the stack depending on the use case.
That being said, in most use cases I've encountered I would've gone with a REST API on the server for CRUD operations and an SPA framework on the UI side. I've found that the use of a classical UI Framework like Play, Grails or JSF make seperation of UI and business logic harder, rather than easier. Especially Grails is a huge vendor lock in and the framework leaks through all layers.
To "scaffold" your REST+SPA application, I've found Spring Datas automagic generation pretty useful, but you're free to use any technology you like.
Grails is great for building a REST API. Especially the latest version. It makes it dead simple. I do SPA frameworks on the front and JSON APIs from the back.
Grails is great to get things done quickly (scaffolding). But if you want to write vendor independent code, Grails makes your life unnecessarily hard by providing a full stack from Database to UI. Somewhere something leaks into the business logic. This is less the case if you can pick and control exactly what Database and REST technology you use. Of course you can ignore the DB part in Grails and plug your own thing, but then, why should I use Grails in the first place?
i recently wrote a small blog engine in vert.x (http://vertx.io/). i'm not fluent with reactive programming yet (so i didn't use RxJava), but the callback hell was manageable enough. among the upsides are the seamless integration and handling of websockets. the blog engine is a bit of an outlier though because it's embedded and fully single threaded. there are a lot more advantages if you leave out the embedding, like several more languages (several languages with interpreters available on the JVM).
My honest opinion is that JVM folks love complexity though. It's a mix of popularity, job security and good marketing that allow the traditional bloat-powerhouses to remain popular while technologies like Vert.x remain criminally under-utilized (see the rest of this thread for evidence). I don't know how or if this will ever change, but the downside for the JVM ecosystem overall is that people associate the JVM with things like Spring and Hibernate rather than things like Vert.x. And that's a shame.
Unfortunately the documentation is pretty poor. You'll definitely run into troubles with any non trivial app due to the lack of proper documentation (and there is not much third-party documentation around).
In scala-land, I've got experience from Scalatra, http4s and Play framework. We've recently migrated a large Scala project from Scalatra to http4s. I would not recommend using the current 2.x version of Scalatra. The biggest issue I've got with it is it's lack of type-safety. Each REST-endpoint in Scalatra is basically a function from Request to Any. So you can return anything and cross your fingers it works runtime (see e.g. https://github.com/scalatra/scalatra/issues/534). I believe many of the core Scalatra-contributors are nowaday much more active in development of the http4s (see https://github.com/scalatra/scalatra/graphs/contributors vs https://github.com/http4s/http4s/graphs/contributors).
I really like the design of http4s; services compose really nicely -- each service/server is just a partial function from Request to Response. It utilizes Scalaz Tasks for asynchronous opeartions / streaming. On the other hand, I would not consider http4s very mature yet. We've encountered some issues during refactoring from Scalatra to http4s. Also, they offer support for both Servlet- and Blaze NIO -servers, but I've had the feeling that Servlet-support feels a bit like second-class citizen. Maybe not so thoroughly tested (I'm just spitballing here)? But still.. I like it and based on current experience would not advice against using it. Also, I've had great help from their Gitter-channel. :)
Play framework, is nowadays pretty mature. I've used it in multiple projects, and love that nowadays it's sbt compatible (just declare the dependencies) -- I think in the past you had to download a separate distribution for using it.
I think http4s and Play are both excellent choices. Play feels a bit bloatish and maybe opionated compared to http4s, but on the other you've got everything ready (play-ws, play-json, play-twirl etc.). Once http4s gets a bit more mature, I believe it'll be awesome! :)
P.S. With http4s my current recommendation would be: Argonaut for JSON, and Slick for RDMS-support (Postgres all the way).
I'm building something with React + Relay + Sangria and it's working out well so far. There's a sample sangria project showing how to use it on akka-http, and if you write a pure web app like this, you could serve the javascript client from somewhere dumb like S3. Plus with this stack you can plug in react-native apps as well once your server is written.
can you talk a bit more ? How do you write your views and integrate them with sangria. I'm coming from nodejs .. where everything is JS, so I'm trying to understand how this stack works.
Sangria is a scala GraphQL server. Facebook released an initial reference implementation in javascript, but I wanted the type-safety that scala gives. If you're more comfortable with JS you could check that out. See https://facebook.github.io/relay/.
With GraphQL you don't write views per se, but you make data available. The client can pick and choose which of the exposed attributes it needs to render a view. So if you have, say, a user profile page, you might use relay to declare that you need something like:
user(id: $userId) {
username
age
}
Then relay will hit your graphql server and add this data to your react props.
It's a similar thing with mutations - you expose operations through your server and then relay handles calling it with the necessary data, and propagating back the response into the UI.
I've found this approach to be very powerful and quick to develop in (once I got my head around it). With REST, you have to keep on adding new endpoints or fiddling with your server if you need more attributes from it. E.g. say you also want the user's gender. With traditional REST you'd need to make this change in your client (to request that extra data) and update your server to expose it. Or perhaps you'd add a new endpoint that returned more data about a user. Then you may also need to decide what happens with legacy clients. Should they fail if they receive extra, unexpected data, or do you version your API, etc.?
With GraphQL you can choose to expose all of the different attributes on your user model (with authentication/authorisation, etc as appropriate) in-advance, and then if clients need the gender, they can just request it via relay.
After I tried writing an app using REST and continually feeling like I was walking in mud, this is a real breath of fresh air, and I feel productive again. I definitely recommend checking it out.
I'm assuming your views are written in React.js - how does that get served to your clients ? does the Scala relay server serve it ... or do you have a separate client webapp ?
Yeah the views are all just react.js. The JS for the webapp is dumb so can be served by S3 (i.e. no server-side rendering). It's basically REST++ - a pure server that just serves data (sangria/graphQL server) and a decoupled client (which in my case happens to be a react web app for now).
It depends on your needs, and what you want to do. If you're a big Pythonista, perhaps Jython is worth a look in. Lisper? Look more towards Clojure. Need to be able to hire developers? Plain Java will help you on that front.
Often, choosing a JVM language does not lock you into that language, as there's good interoperability. Be prepared that the first choice of language for a project might not be the best choice.
In response to the question, Java, Spring, Hibernate, and Postgres have served me well on a variety of projects. However, you need to take it with a grain of salt -- my needs will likely be different to your needs, and my skill set is almost certainly different.
I'm actually building one right now using Scala + skinny-micro-framework [1] + Slick and it's going pretty well. Very nicely composable, easy to work with Futures (unlike Scalatra) and very easy to extend to handle new types globally. (Just added an `Option -> response getOrElse 404` and if I need it I can add `actorRef -> Future -> rest-of-pipeline` too.).
http4s and rho also look interesting, but they suffer from the magic operator soup that made dispatch a pain to work with (IMO).
We use Play for www.faqt.co, and it's been nice, but (like any framework) you start hitting random limitations that takes a lot of work and occasional Scala code to get around. Sometimes I wonder if using something like dropwizard.io for a single page app would of been better.
But if your project is only going to be a crud app with limited traffic volume/life time, I'd personally probably pick an interpreted language and framework.
Being the author, I'm of course biased, but I made Boilerplay (https://github.com/KyleU/boilerplay) for this very reason. It's a Play/Scala app, uses postgres-async for database access, and provides most of the boilerplate you'd need for non-trivial apps (admin, metrics, reporting, sign-in, etc).
My background, which informs my personal taste here:
- Most recent 8 years, have used dynamic languages on the server (Node.js, Ruby, PHP, some Python)
- Have dabbled in C# (ASP.NET MVC and WPF)
- First 4 years professional experience as a Java web developer (servlets, Struts, Spring, Hibernate, etc)
- Have needed recently to generate greenfield Java apps for relatively straightforward CRUD web apps / JSON APIs
I personally would have a hard time going back to Spring or JEE. I initially looked at Play, which is very cool in many respects, but comes with a high complexity/magic level that makes me nervous. Probably it's great, my old bones just can't deal with another long walk to mastery like with Rails.
Here's the stack I have been most comfortable with - note that this has been for relatively simple CRUD app development, and may or may not suit your hyper-enterprise-iot-multitenant-whatever use case:
Kevin likes: Easy to generate single runnable jar, simple route configuration, no heavy abstraction over HTTP (easy to filter, redirect, return status codes, set cookies, etc), support for a variety of modern template engines.
Kevin dislikes: pretty small community around the software
Kevin likes: terse syntax I came to enjoy from Node/Ruby, can easily re-use templates on the front end if needed in Backbone. Integrates easily with Spark.
Kevin likes: <troll>it's web scale</troll>, no schema maintenance, easy to configure for dev/test/prod, easy to create fat models, doesn't require a ton of annotation for persistent fields.
Kevin likes: doesn't matter if I like it, all Java packages live there. Lots to use and choose from both for build tasks and in your code. Make note of the Shade plugin, which makes it easy to generate a single runnable "fat jar":
Kevin dislikes: OMG XML. Super verbose. Pretty slow. Seems to frequently download the Internet. Not fun to extend - consider shelling out to your own scripts:
With the above tools, I found that it's easy to take advantage of the great software packages that do exist for Java, without making my brain hurt too much.
Why Maven rather than Gradle? Gradle has all the libraries in Maven Central. Gradle also has an extensive set of useful plugins built in [1], and many more available externally [2]. In particular, there's a plugin for making a fat jar [3], and even without a plugin, it's a few lines of code [4]. Or you can also make something more exotic like a capsule [5] or a shell script [6], or my preferred format, a 'distribution zip' file containing loose jars and a shell script [7] - which you can even make executable, because i wanted to troll my boss one day [8]).
And there's no XML, it's pretty concise (Groovy syntax, convention over configuration, sensible defaults), and although its raw speed is no better than Maven's, it is smart enough to only execute tasks which are needed (rather than everything, every time, as Maven does), and can run as a daemon to avoid startup costs [9], so in practice it's far faster than Maven. Still downloads the internet now and then, though.
But extension is an absolute joy - there is simply no comparison to Maven. There's a very satisfying spectrum of ways to define your own tasks, from blocks of code right in the build script, to classes defined in the build script [10], to externally packaged plugins, all of which are easy to do and integrate fully with the existing machinery (task dependencies, handling files, inputs and outputs, and so on).
Then there's the stuff you might not even notice until you get off Maven. Gradle builds are graphs of tasks, not sequences of lifecycle phases, so it's trivial to add more tasks, rearrange, tasks, etc. Concrete example: Maven provides a single test task (surefire); if you want a second (say, for functional tests), you can use a plugin (failsafe); if you want a third (say, for external contract tests), you'll need to write a plugin. In Gradle, you'd just make another instance of the test task. It's a few lines of code.
Sorry if i sound like a fanboy or a shill, but Gradle, while far from perfect, is so much better than Maven in every way that it pains me to see a fellow human being suffering under the latter. Seriously, Maven is obsolete. Just use Gradle. Until something better comes along.
> Maven is obsolete. Just use Gradle. Until something better comes along.
Google released Bazel a few months ago, which runs on Linux, tho not Windows, and fully supports JVM-hosted software. It's better than Gradle, so why not move straight from Maven to Bazel? See http://bazel.io/docs/bazel-user-manual.html
Definitely worth considering! I've never used Bazel, so can't give a very helpful answer. Two things discourage me.
Firstly, it's still in beta - 0.1.0 is out [1], and there's plenty to do before 1.0. [2].
Secondly, according to the article on Bazel currently floating up on HN [3]:
"Blaze was designed to work for Google's unified codebase and Bazel is no different. The implication of a unified source tree is that all dependencies for a given software component exist within the tree. This is just not true in the open source world where the vast majority of software packages have dependencies on other libraries or tools, which is a good thing. But I don't see how Bazel copes with this, if at all."
How would i use Bazel to build a project which uses dependencies from Maven Central, or my company's internal repository? It seems that Bazel can fetch jars from Maven repositories [4], but i don't think it does transitive dependencies.
Also, the extension story looks a bit weird [4]:
"Skylark is a superset of the core build language and its syntax is a subset of Python. The following constructs have been added to the core build language: if statements, for loops, and function definitions. It is designed to be simple, thread-safe and integrated with the BUILD language. It is not a general-purpose language and most Python features are not included."
Whilst i'm no fan of Groovy, it's nice to be able to write plugins in a general-purpose language. For example, in one of the build scripts i linked to in my comment, i have a custom build step which processes templates by running another Java program (which was downloaded as a JAR from Maven), and in other builds i've written plugins which call directly into Java libraries (again, which were downloaded as JARs from Maven). Could i do that with Skylark?
You could be right about Bazel's unsuitability for open source software.
> The following constructs have been added to the core build language: if statements, for loops, and function definitions
The whole point of using a declaratively-configured build product rather than procedural scripts is to simplify the logic and be easily extendable. Maven provided the declarative DSL and removed totally the procedural language so you needed an addon like polyglot-maven to do anything "out of the box". Gradle then added the whole procedural language back in to be used with the DSL, but it's hardly used as most build scripts out there are just standard 30-liners. Perhaps Bazel's way of providing just enough procedural features (sequencing, selection, iteration, subroutines), and no more, with the declarative DSL is the best mix.
I second this. while creating a CRUD app for a college project, springroo helped me bootstrap it to the point that i was able to complete the entire app in 6 hours.
At my office we've got a whole bunch of Spring Boot projects happening. A workmate of mine began making a screencast series, "Annotated Spring", a la Railscast.
If using Java and not Clojure, maybe I'd use enunciate again on top of the standard JavaEE stuff. http://enunciate.webcohesion.com/ Deploy with tomcat.
I don't see how this question is answerable in any meaningful way in its current form. You're going to get a list of basically every JVM framework there is, and you speak nothing of your front-end requirements.
I admit OP's question is a little vague, but as someone who hasn't touched Java in a while, I appreciate it. True, the answers are just as vague as the questions, but to someone who is familiar with Java and not the frameworks for web development it does enumerate the options that can be explored
I'm the creator of JHipster, thanks for the link :-)
Yes we do generate CRUD entities, from the database (SQL, Cassandra, MongoDB) to the view layer (AngularJS/Bootstrap). All this with security, caching, monitoring, documentation, tests... So this is very different from Play, Dropwizard or even vanilla Spring Boot (on top of which JHipster is built).
I'm not saying it's better or worse, just that it's a totally different beast: depending on your needs, JHipster can be a huge time-saver.
I'd say it depends on your data model. If it is fairly simple, Ruby on Rails is quite awesome. I didn,t experiment with Clojure, Scala, etc. but RoR is a quite impressive toolset to do CRUD on simple stuff.
spring mvc for the rest controllers with spring data jpa for the repository layer. The frontend in Angular 1, nothing beats that in terms of simplicity and flexibility.
Dont try to do your frontend in java using jsf, wicket, gwt, vaadin, play framework the scala compiled templates or anything they are too complex and unflexible compared to what you can do with angular in the browser in a fraction of the time.
The nice thing about Django is the combo of its model layer and forms library handle the most boring bits of CRUD without generating a bunch of code or being tied into a particular templating library. I'd be tempted to go with this answer if the frontend is going to be a basic forms 'n links affair.
Is there anything comparable to django.forms in Java yet? There wasn't the last time I went looking a few years ago.
