Generator-jhipster: Provide First-Class Support to Neo4j

[conker84]

Overview of the feature request

Hi @deepu105, we meet (with @jexp) at the Code Motion in Rome the last march.
We want to provide first-class support to Neo4j with JHipster so as we discussed we open this issue in order to gather the ideas and define a development plan.
Please let us know how we can develop this.

Motivation for or Use Case

Enable Neo4j to JHipster

Related issues or PR

• [x] Checking this box is mandatory (this is just to show you read everything)

[deepu105]

Welcome @conker84

Yes so to start with here are my thoughts

We already have Cassandra, mongo and couchbase integration and the problem is they are not as widely used as SQL ones but have high maintenance overhead since they need separate branching in templates. I remember you mentioned integrating Neo4j should be simpler. So looking at our current templates what do you think? how much branching would be required.

based on that assertion we have 2 options but of course, this needs to be agreed by @jhipster/developers and maintained by someone from Neo4J as we won't have the bandwidth.

• If the branching is minimal and can be done using Spring data easily then this can be a core option
• If it requires branching like Cassandra or Mongo then better would be to create a blueprint https://www.jhipster.tech/modules/creating-a-blueprint/

@jhipster/developers WDYT?

[jdubois]

I totally agree with you @deepu105 of course, but @conker84 you seem to work for Neo4J, so could we have some kind of "official" support? That would eliminate much of the maintenance overhead for us.

Also, iit seems discontinued but you could contact the people behind https://github.com/jhipster/jhipster-neo4j-app as this is probably a first start, and they could be happy to help you.

[pascalgrimaud]

If the branching is minimal and can be done using Spring data easily then this can be a core option
If it requires branching like Cassandra or Mongo then better would be to create a blueprint https://www.jhipster.tech/modules/creating-a-blueprint/

Agree with you @deepu105

[arabbani]

Any update on this?

[michael-simons]

Hey everyone,

Michael from Neo4j here. I'm working on Spring Data Neo4j (both SDN+OGM and our new implementation SDN/RX).
Our team would help @conker84 with integrating https://github.com/neo4j/sdn-rx/ into JHipster.
We prefer the work based on SDN/RX as this will support

• Neo4j 3.5
• Neo4j 4.0+

and both imperative and reactive repositories.

@deepu105 @jdubois

Would you please shed some lights on the branching you speaking about? I'm not yet familiar with the Template mechanism, but I already found those here:
https://github.com/jhipster/generator-jhipster/blob/master/generators/server/templates/src/main/java/package/repository/PersistentTokenRepository.java.ejs
and the related, dedicated Couchbase and Cassandra repositories.

Something like you're doing for Cassandra wouldn't be necessary, I don't understand why you're doing something special for Couchbase.

Also pinging @atomfrede here. Frederik, it would be most awesome to talk about the ideas played here tomorrow at Java Forum Nord in person.

[atomfrede]

We can do! Will ping you via the jvm slack if that's okay.

[jdubois]

Awesome news @michael-simons !!!!
Yes it would be the same idea as Couchbase or Cassandra. If you're using Spring Data is shouldn't be too complicated.
For the reactive part there's a specific branch by @cbornet for this, but it's still experimental: you should focus first on the non-reactive part, this is where you will have the most people interested.

[atomfrede]

Hi everyone,

We had a nice conference and talked a bit about how we could move neo4j support forward. We decided to go first with a dedicated blueprint, although the branching would not be that large at first glance. Nevertheless putting it in the core would mean a lot of maintenance burden and commitment which currently neither we nor neo could do.

@michael-simons will create a blueprint and I will support him in doing so such that @conker84 could go on with the implementation. The goal is to have blueprint which replaces the date persistence layer with neo4j completely.

I hope I didn't forget anything important.

[arabbani]

Great. Keep us updated

[michael-simons]

Thanks for the great summary, @atomfrede

I'll evaluate creating a blue print first, but also have a look at adding something to core again.

Specifically the maintenance burden needs to be clarified: SDN/RX is a standard Spring Data project. Dedicated maintenance would be required if one decides to provide embedded Neo4j support as well. I'll keep you posted.

[sendilkumarn]

Wow so nice to see this happening. 🎉 Congrats @michael-simons & @atomfrede

@michael-simons feel free to reach out if you have any issues/questions with the blueprint. More than happy to help.

[michael-simons]

As a quick feedback: We evaluated both options: Modifying the core and on a blueprint. While I personally like the blueprint approach a lot, it seems to be like a lot more effort (i.e. adapting options, covering all paths that may be taken).

Therefor I focussed on modifying server and entity-server of the core generator.

You can keep track here
https://github.com/michael-simons/generator-jhipster/tree/feature/neo4j-server-entities

or even grab that branch and help me with it.

There's a gotcha, though: SDN/RX requires Spring Data 5.2 and thus Spring Boot 2.2. That said, the generator generates compilable code now, but it doesn't run yet. At the moment I'm patching https://github.com/jhipster/jhipster to get Boot 2.2. and related.

Question is now:

If we (Neo4j and @conker84) work on that contribution, including the reactive support we have upcoming in both SDN/RX and database 4.0, would the JHipster team consider accepting it?

From my personal perspective working on integrating SDN/RX already spotted some open issues on our side and I'd love to keep working on the integration.

Looking for your feedback.

[atomfrede]

@michael-simons Thanks for your heads up! Nice work. So it seems my assumption a module is to less and a blueprint way too much overhead for such a "small" change has proven to be true.

I would appreciate having neo4j in the main generator and having e.g. you and @conker84 as maintainer (I will help where I can of course) and have it for example as a beta option (as we have for infinispan). I think the benefits for all involved projects (spring data, neo4j and jhipster) are quite huge so I would suggest let's go with adding a beta option to the main generator and have it ready when we switch to spring boot 2.2 which would be a nice feature.

[arabbani]

What about JDL. Is there gonna be jdl support for neo4j

[michael-simons]

@atomfrede Yes, totally correct.

@arabbani I didn't touch it yet, but there's no reason why it shouldn't work for Neo4j SDN/RX, we support all the relevant mappings.

[arabbani]

Great

[arabbani]

Will try it out

[arabbani]

What about GraphQL integration. neo4j-graphql-java.
It would be very good to support graphql

[atomfrede]

@arabbani GraphQL is out of scope for now as. Imho that would be more of blueprint as not only the database is changed. So there would be a lot of branching in the templates

[atomfrede]

@jhipster/developers As we have Boot 2.2 merged now, I would like to go on with the first beta support for neo for the next release and use @michael-simons work and create a first PR to get this forward, any objections?

[michael-simons]

Not from our side. Quite the contrary, we have a SDN/RX Beta out with all required features as well as the final Neo4j bolt driver. Let’s pair on this sometime early January.

[atomfrede]

Sounds great! Thanks for the swift response. Have a happy new year!

[atomfrede]

Just for reference:

• [ ] Add support in main generator
• [ ] Reactive repositories
• [ ] Add JDL support
• [ ] Add proper integration testing to our pipeline (nightly builds)
• [ ] Add support in kotlin blueprint

@deepu105 @pascalgrimaud @jdubois It would be nice to have bounty on this :wink:

[deepu105]

How much bounty would you like?

On Sat, 4 Jan 2020, 8:07 pm Frederik Hahne, [e-mail]
wrote:

Just for reference:

• Add support in main generator
• Add JDL support
• Add proper integration testing to our pipeline
• Add support in kotlin blueprint

@deepu105 https://github.com/deepu105 @pascalgrimaud
https://github.com/pascalgrimaud @jdubois https://github.com/jdubois
It would be nice to have bounty on this 😉

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/9967?email_source=notifications&email_token=AAIOKF34NMU7JXLO5OTEQ2TQ4DNANA5CNFSM4H2RUMYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC6FKA#issuecomment-570811048,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOKF2GNXICVHIXA5YXMS3Q4DNANANCNFSM4H2RUMYA
.

[atomfrede]

Would say 200 so it can be split nicely is fine.

[atomfrede]

The initial work is done, thanks to @michael-simons and @meistermeier :heart: When all related PRs are merged we will have Neo4j support in both generator and JDL and updated documentation and a nice demo case which can show the benefits of neo4js graph capabilities (blog entry upcoming). After that we will go on and port the support to the kotlin blueprint for sure. Not quite sure if there is a simple way to bring it to .net and node.js blueprints. But I think support for mirconaut and quarkus is already planned/

[pascalgrimaud]

@atomfrede : don't forget to update the jhipster-online for the next version too.

Then, I'll need you @PierreBesson to upgrade the jhipster-online. It was not updated since months... I only used npm install -g generator-jhipster to upgrade the version of the generator, but not jhipster-online itself

[atomfrede]

Good point would have totally forgotten about it.

[trixprod]

@atomfrede , hello, do you have some informations about Quarkus impl in jhipster ?

[pascalgrimaud]

@atomfrede : excepting the jhipster-online and the failures on daily builds, is it finished here ? can we close the ticket ?

[atomfrede]

@pascalgrimaud Yes let's close it. It works for most cases, some things need to be changed, but in general I would say we are good to go and promote it as "BETA". Thanks again to @michael-simons for support and the work. Let's have a :beer: at Javaland to celebrate.

[jdubois]

Oh @mraible and myself will also be at JavaLand -> let's do a JHipster meetup! Beers will be paid by the project's Opencollective 😀

[atomfrede]

:+1:

[pascalgrimaud]

Increasing the bounty as it was more work than expected and it will be well deserved

[michael-simons]

Looking forward to meet you all in Brühl.