Support for microserviceName

[PierreBesson]

For JHipster 3 we added a new field (microserviceName) to the entities JSON for micro-services entities.

microservice1/.jhipster/Foo.json :

{
    "relationships": [],
    "fields": [
        {
            "fieldName": "name",
            "fieldType": "String"
        }
    ],
    "changelogDate": "20160322132123",
    "dto": "no",
    "service": "no",
    "entityTableName": "foo",
    "pagination": "no",
    "microserviceName": "microservice1",
    "searchEngine": "no"
}

On the micro-service, this file is used to generate only the back-end of the entity. Then the same Foo.json is reused to generate the front-end on the gateway. And thanks to the microserviceName property, it can prefix the API endpoint with the correct route to use the microservice as a back-end.

It would be great to have support for this in the JDL.

In JDL this could be something like that: setMicroserviceName Foo with microservice1

[MathieuAA]

Ok! What about searchEngine? I've never seen it before.

[deepu105]

@PierreBesson I think there might be a better way to get both fileds without having to have them in the json while using entity sub generator. With JDL its a different scenario we need to have a way to identify if an entity is normal or from a microservice first else if you run them it would be considered as a normal entity for the gateway.

One way is as you suggested use an instruction to set the name as well as to determine if its a microservice entity

[PierreBesson]

@MathieuAA, "searchEngine: elasticsearch" means that elasticsearch is enabled for this entity. This is added to entities json files for apps that are generated with elasticsearch support. It will even create a little search box to let your search results.

@deepu105 I have trouble to see your point. What would be your idea to integrate this in the JDL ?

[MathieuAA]

Oops we've never added that. Gotta do it.

[deepu105]

@PierreBesson for entity sub gen I have a solution to do this without adding to json but for JDL it needs to be added to Json as you propose.

@MathieuAA the elsatic serach option again is applicable only when an entity is from a microservice, (for normal monolith its not required in the json as its an app option) its a workaround since we wont know if the micro service had elastic search or not to render the client side for that.

[MathieuAA]

I guess I'll need to check what the user wants against the .yo-rc.json file. How fun!

[deepu105]

you wouldnt have the yo-rc as the microservice would be in some other folder.

You need to check if an entityy has a microservice name declared if so you need to add that and search option to the generated json

Thanks & Regards, Deepu

On Tue, Mar 22, 2016 at 11:49 PM, Mathieu ABOU-AICHI < notifications@github.com> wrote:

I guess I'll need to check what the user wants against the .yo-rc.json file. How fun!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-domain-language/issues/5#issuecomment-199876073

[MathieuAA]

No yo-rc file? JUML's code might need some change... Gotta test.

[deepu105]

I think you just need to handle thse 2 param in the json

Thanks & Regards, Deepu

On Tue, Mar 22, 2016 at 11:59 PM, Mathieu ABOU-AICHI < notifications@github.com> wrote:

No yo-rc file? JUML's code might need some change... Gotta test.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-domain-language/issues/5#issuecomment-199880362

[PierreBesson]

@deepu thanks for pointing out that the searchEngine field is only for microservices. I had forgotten.

@Mathieu, you can just worry about doing the correct json. Anyway we will demo microservices on the April 11th meetup and you shall see why we made you do this !

[MathieuAA]

@PierreBesson I've taken the time (quite some time =/) to think about that, and I'd like to add it so that the following JDL will add the microserviceName:

entity A
entity B

microservice {
  A with microservice1,
  B with microservice2
}

Do you think that this solution is possible given how a microservice project is created in JHipster?

An alternative, more project-oriented this time would just consist in declaring the microservice name somewhere in the file like with microservice MICROSERVICENAME.

As for the search engine, this is simple enough. I'll add an option just like dto or service.

After the change is made, I'll release a v1.0.0 for this project and publish it in NPM.

[PierreBesson]

Your first solution is exactly what we need. Because 1 gateway can generate entities whose back-end are located in different microservices.

[MathieuAA]

Hi, I've made a decision (depends if it's a good one or not). The solution I proposed was good, but broke the "how-we-define-options" pseudo-rule.

It's not complicated to add microservices, but I need more time to add the second syntax for the other options. Here's the implemented way (it's good, don't get me wrong):

entity A
entity B
entity C
entity D

microservice * with microservice1 except B
microservice B with microservice2

It's the same syntax as the other options'. The previously proposed syntax is good, but I can't just add it to one of the options and not add it to the other.

I'll add it in 1.0.1.

[deepu105]

Some how I feel that this is not very intuitive and I really lean towards having a declarative syntax like annotations we discussed earlier or something more readable @jdubois @MathieuAA as JDL becomes more and more famous we should discuss and have a better roadmap and I really dont think the way current syntax is going is future proof