JHipster http://jhipster.github.io/
It's a yeoman generator actually, generates a Spring based project with all the CRUD stuff ready for you.
Ask HN: What stack would you use to build a CRUD web app on the JVM today?
51–60 of 213 posts
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#52I 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. Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui... [EDIT] Removed the unnecessary/unhelpful opening statement.
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.
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#53Earlier quoted context omitted.
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…
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…
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.
[1] http://w3techs.com/technologies/overview/content_management/...
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#54Spring 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 cl…
If you're favoring Boot, why not just use a newer version of Grails?
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.
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#55Earlier quoted context omitted.
Sangria is scala. React is the client in the browser. That doesn't run on the JVM.
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
}
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.
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#56Earlier quoted context omitted.
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…
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…
He did start with the use case -- "a simple CRUD app".
That is sufficient to start looking for a framework, in my opinion. Cases where that is wrong aren't simple.
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#57Definitely Clojure with http-kit [1]. Easy to use, minimalist and supports websockets. However, it depends from your use-case. Could add some detail please? [1]: http://www.http-kit.org/
That looks like it is a HTTP server.
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?
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#58Play Framework
I like Play too.
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#59Earlier quoted context omitted.
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, Spr…
It doesn't change my impression much if the answer to "lots of boilerplate" is to use another tool to generate it automatically...
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.
Re: Ask HN: What stack would you use to build a CRUD web app on the JVM today?
#60JHipster http://jhipster.github.io/ It's a yeoman generator actually, generates a Spring based project with all the CRUD stuff ready for you.
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.