Converting an Application to JHipster
I've been intrigued by JHipster ever since I first tried it last September. I'd worked with AngularJS and Spring Boot quite a bit, and I liked the idea that someone had combined them, adding some nifty features along the way. When I spoke about AngularJS earlier this month, I included a few slides on JHipster near the end of the presentation.
This week, I received an email from someone who attended that presentation.
Hey Matt,
We met a few weeks back when you presented at DOSUG. You were talking about JHipster which I had been eyeing for a few months and wanted your quick .02 cents.I have built a pretty heavy application over the last 6 months that is using mostly the same tech as JHipster.
- Java
- Spring
- JPA
- AngularJS
- Compass
- Grunt
It's ridiculously close for most of the tech stack. So, I was debating rolling it over into a JHipster app to make it a more familiar stack for folks. My concern is that it I will spend months trying to shoehorn it in for not much ROI. Any thoughts on going down this path? What are the biggest issues you've seen in using JHipster? It seems pretty straightforward except for the entity generators. I'm concerned they are totally different than what I am using.
The main difference in what I'm doing compared to JHipster is my almost complete use of groovy instead of old school Java in the app. I would have to be forced into going back to regular java beans... Thoughts?
I replied with the following advice:
JHipster is great for starting a project, but I don't know that it buys you much value after the first few months. I would stick with your current setup and consider JHipster for your next project. I've only prototyped with it, I haven't created any client apps or put anything in production. I have with Spring Boot and AngularJS though, so I like that JHipster combines them for me.
JHipster doesn't generate Scala or Groovy code, but you could still use them in a project as long as you had Maven/Gradle configured properly.
You might try generating a new app with JHipster and examine how they're doing this. At the very least, it can be a good learning tool, even if you're not using it directly.
Java Hipsters: Do you agree with this advice? Have you tried migrating an existing app to JHipster? Are any of you using Scala or Groovy in your JHipster projects?
I also used JHipster for some early prototyping / playing around kind of projects.
What I don't like about it when it comes to production systems is, that it actually combines client side stuff and server side stuff.
I'd definitely prefer a solution (most probably even for prototyping stage) where the REST API is served with Spring Boot and the client side stuff is served e.g. with NodeJS - on a different port which forces you to get CORS implemented correctly right from the beginning.
And preferably the client side code should not include any server side logic (beside maybe compiling CoffeeScript to JavaScript or LESS/SASS to CSS. 'Cause that allows to deploy the final version of something like AmazonS3.
Posted by Michael on February 12, 2015 at 07:09 PM MST #
Same way as Michael says. However, the backend was an integration project where SOAP over HTTP services were already created. I used to WSO2-esb and WSO2-api-manager to reuse these services and expose them as REST for later consumption to presentation layer made by the jhipster generator through the scaffold of yeoman.
This alternative is a backend that requires some setup time, not really applicable for a short number of applications and I would prefer to use a lighter backend stack where "capabilities" could be included according the needs of the projects, but having a base stack that the majority of all microservices could reuse. The closest approximation is spring boot, an evolution of the old friend spring, where capacities can be included according the intended use. Other stacks on the side of backend often provide the very-fast and efficient creation of database-oriented applications (rails, django, grails) but sometimes does not have the expected integration capabilities. Then we need to include brokers or middleware to access another applications.
Posted by andres on February 17, 2015 at 03:21 PM MST #
Posted by Rob on May 27, 2016 at 07:37 PM MDT #
Posted by Matt Raible on May 27, 2016 at 10:45 PM MDT #