Customisation strategy after project generation is heavily missing

[vedranstanic82]

Hi guys,

Sort of new to JHipster. I have been aware of it for many years, tried it once long time ago, I can see it has matured a lot. This stuff is amazing. I could speak many many great things about it, but let's cut to the potential improvements, or in fact 1 key improvement in particular: customisation strategy.

What is customisation strategy: for the lack of a better expression, it is how you add your own code once you are ready to stop auto-generating the code so often. In other words, once you get your auto-generated project in the right spot and now you need to start making your app.

Why is this a key moment: because, let's be real, the auto-generated code is non-production stuff. It is a mere scaffolding for something real, mostly because of the look and feel and the UX/UI. No sane modern user will be happy with using these screens OOTB. So for every single project out there that is using JHipster, the auto-generation is just step 1, and the immediate next step is customisation of the auto-generated code.

Why is this lack of customisation strategy a problem: I've been tinkering with JHipster for a week now and only by specifically googling and ChatGPT-ing have I found some potential old ways of customisation strategies (side-by-side and blueprints). This is just bad from a learning material perspective. This definitely needs improvement. Even if I have somehow missed something obvious, some obvious link, that means it needs to be better surfaced in the learning materials. It is NOT ok for new JHipster users to wonder around aimlessly trying to figure out how to approach this step 2 (customisation of JHipster generated code). Again, the only way I found the two approaches were by clicking on some youtube link in one of the learning materials articles and this video is from 2019 and in this video the dude says "we should get some proper customisation strategies documented". So, even if I missed it somehow, it should not be this hard to find it and figure it out. Secondly, I had to dig for it and piece it together and am not confident that I found the right approach (sbs, blueprints). Just to re-emphasise: the whole 10000ft view purpose of JHipster is to build production apps, not just try-it-locally-cool demo apps that go nowhere. The step 2, the "customisation strategy", the key for future well being of this eco system is MISSING!

What to do about it: on the main jhipster page, where all the learning tutorials are, there should be a lvl 1 menu item solely dedicated to SBS and Blueprint and some other customisation strategies with youtube links, github examples, etc. You cannot let the average Joe's of the world try and figure this out on their own. This need to be documented as "best practice" by the people that understand and work with JHipster day in day out. Otherwise the average Joe will give up and JHipster will miss it's 10000ft purpose or making development of apps today fun by allowing the average Joes to focus on what matters (business logic and UX/UI) vs the scaffolding.

Disclaimer: this is my opinion piece straight from the heart, I understand I could be wrong or having missed something simple. Please forgive the way it is worded - I love the idea of JHipster, I love the auto-generated projects it spits out - it is magic, I am although stuck on the customisation strategy and am wondering if I should pursue using JHipster which is unfortunate for me. What is unfortunate for JHipster as a project though is that this is probably how thousands of average Joe developers feel like and JHipster is very slow to popularity. In other words you are missing one key piece to the puzzle guys.

[atomfrede]

I agree we lack a lot of documentation with regard to sbs customization and blueprints. While this is not such of a problem for spring boot server side part the ui part is hard.

I suppose most of the time the generated jhipster ui should be used as an admin/management part and one want to create a dedicated ui for the user facing parts maybe.

We are trying to update our homepage and hopefully find some good way/examples to customize generated code.

Nevertheleaa it is also a valid and not uncommon way at some point removing the connection to jhipster and evolve the application on your own.
If you are looking for less generated code and maybe something like ddd approach you could have a look at jhipster light.

So long my first thoughts and happy holidays everyone!

[vedranstanic82]

First of all thank you for the prompt reply and thoughts. Here is some feedback from an average capable dev (someone who does not want to dig deep into doc or source code, but just sort of use the framework), a user of the framework:

• spring boot: while it is intuitive to a senior java dev that you should just inject/extend, it wouldn't hurt to have this in writing so that people are more confident that this is the way and that the JHipster team did not have some other better way in mind
• overall having this stuff in writing on your home page would give users confidence on how they will use the project in the future as their personal projects grow in complexity. In other words, when I try to image how my project will look in one month from now, I want to be confident that it will not be sunken cost of learning and using JHipster and that I understand the road ahead - just trying to paint the mindset of an average guy
• even for SBS that youtube video mentioned a couple of different ways it could be done (the presenter was not aware of it before he put together the presso, so he just mention it, but it would be nice to see it in writing)
• rewriting code files: for large projects it could be hard to manually click yes yes no (vs all) when rewriting files. I wonder if JHipster could have markers in the files themselves that say: do not touch (maybe they already do)? or even lines of code not to rewrite by auto-generation. Thinking here of an Angular router file
• Removing the connection is OK imo, but only if you state it on your official website. Otherwise the average joe will scratch their heads and be like: "is this how they intended it to be? am I doing it wrong? should I find a way to keep working with it? when should i remove it? how is it don?" etc.
• I haven't had time to review jhipster light...such is life of a family man

Basically the overall sentiment from me is: the pros of JHipster should try and walk in the shoes of an average JHipster user and document the whole "customisation" step or how the roadmap may look for the app down the line (ie. at some point you may want to remove JHipster from your app, this is OK and this is how it is done, ie2. it might be best sometimes to use the JHipster UI for admin stuff (which is true by the way I came to this same conclusion) and have a fully separate UI For your real app. However in this case it would be great to actually be able to generate both projects and setup the scaffolding of security and services or importing of modules, etc. for the user - the idea of me setting up my own project and trying to figure out how to include the admin project into the public project scares me). Sorry for the horrible writeup, my baby is pulling on my leg now... gotta go, all the best guys!

[vedranstanic82]

Found a short article with the suggested strats: https://www.jhipster.tech/tips/035_tip_combine_generation_and_custom_code.html