Same entity name in several MicroServices collide in the Gateway

Overview of the issue

When doing microservices, you often find the same entity name but with different purposes. For example, a Customer in the Invoice microservice, does not have the same attributes/methods as a Customer in the Shipping microservice.

When those two Customer entities are generated in the Gateway, they collide: only the last one remains. So it makes it totally unusable to have the same entity name in different services.

Motivation for or Use Case

We have an architecture with a few microservices. Following some DDD principles, we end up with a few similar entity names, but doing different things (eg. Customer, Document, Service, Event…). They have the same name because it’s important for our business, but they have totally different attributes.

We would need the Gateway to make a clear separation between those “similar” entities (in terms of TypeScript code, and in terms of graphical components and menus).

Reproduce the error

Create an Invoice microservice and import the following JDL :

entity Customer {
    firstName String,
    lastName String,
    company String,
    linkedInUrl String
}

Create a Shipping microservice and import the following JDL:

entity Customer {
    firstName String,
    lastName String,
    gender Gender,
    blogUrl String,
    twitterUrl String,
    githubUrl String
}

enum Gender {
M, F
}

Now, create a Gateway, import first the Invoice JDL, and then the Shipping JDL. Only the Customer from Shipping will remain.

Related issues

• https://github.com/jhipster/generator-jhipster/issues/6480
• https://github.com/jhipster/generator-jhipster/issues/4431

Suggest a Fix

One easy fix would be for us to have different entity names. Instead of Customer, we could have ShippingCustomer and InvoiceCustomer. But this is not acceptable.

One fix would be to have different packages (based on the baseName of the microservice). For example, on the web part of it, instead of having :

gateway/src/main/webapp/app/entities/customer

We would have a sub-package with the baseName of the microservice:

gateway/src/main/webapp/app/entities/invoice/customer
gateway/src/main/webapp/app/entities/shipping/customer

There is also one and only one “Customer” entry in the “Entities” menu. There should be two (with sub-menus)

JHipster Version(s)

gateway@0.0.0 /Users/agoncal/Documents/Code/Temp/jhipster/buggateway/gateway
└── generator-jhipster@4.9.0 

JHipster configuration, a .yo-rc.json file generated in the root folder

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "org.demo.gateway"
    },
    "jhipsterVersion": "4.9.0",
    "baseName": "gateway",
    "packageName": "org.demo.gateway",
    "packageFolder": "org/demo/gateway",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "hibernateCache": "hazelcast",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Memory",
    "prodDatabaseType": "postgresql",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": "eureka",
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "enableSwaggerCodegen": false,
    "jwtSecretKey": "replaced-by-jhipster-info",
    "clientFramework": "angularX",
    "useSass": false,
    "clientPackageManager": "yarn",
    "applicationType": "gateway",
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "enableTranslation": false
  }
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory

JDL entity definitions

entity Customer (customer) {
  firstName String,
  lastName String,
  company String,
  linkedInUrl String
}

Environment and Tools

java version “1.8.0_131” Java™ SE Runtime Environment (build 1.8.0_131-b11) Java HotSpot™ 64-Bit Server VM (build 25.131-b11, mixed mode)

git version 2.14.2

node: v8.6.0

npm: 5.3.0

bower: 1.8.0

gulp: [21:40:22] CLI version 1.3.0

yeoman: 2.0.0

yarn: 1.1.0

Docker version 17.09.0-ce, build afdb6d4

docker-compose version 1.16.1, build 6d1ac21

[jdubois]

• as @deepu105 says this has never been thought of
• and @agoncal I agree having a prefix is better

Who’s OK for doing the prefix solution? Please vote 👍 on this comment, and help on a PR if you can.

• I have no idea of the work this involves, but at least it needs quite a lot of tests
• this is going to be breaking change for many people

[agoncal]

@deepu105 I just regenerate my app with the latest version of JHipster. Now, all my components directory are suffixed with AngularJS suffix. So, under entities instead of:

├── entities
│   ├── address
│   ├── contact
│   ├── tenant
│   └── venue

I have

├── entities
│   ├── address-sponsor
│   ├── contact-sponsor
│   ├── tenant-sponsor
│   └── venue-sponsor

And because in my entities json files I have:

    "microserviceName": "sponsor",
    "angularJSSuffix": "sponsor"

I now have my modules that are named SponsorEventSponsorModule (the first Sponsor being the microservice name, the second Sponsor being the Angular suffix). We were worried about the merge issue if subdirectories were introduced, but now, with different directory name, we’ll have the same merge issues.

I still think that subdirectories would be better. An easy one would be:

├── entities
│   ├── sponsor   // microservice name
│   │   ├── address
│   │   ├── contact
│   │   ├── tenant
│   │   └── venue

A better one (well, in my opinion)

├── sponsor   // microservice name
│   ├── entities
│   │   ├── address
│   │   ├── contact
│   │   ├── tenant
│   │   └── venue

BTW I’ve created an issue about directory structure in general https://github.com/jhipster/generator-jhipster/issues/6693