Multi Schema Support (Versioning)

Approach 1:

For each schema we will have maintain a separate version of micro service and separate db schema. On Apache, we configure Redirect rules to point to appropriate API version.(based on the schema given in the URI)

Challenges

• Each schema will have to maintain its own common data (like users, trusted apps, ACLs ). So, there need to a sync process that will keep all the common data consistent across the schemas
• User will have to be authenticated across each schema
• Changes to common components should be propagated to each version of code base.

Approach 2:

Data Base will be divided into 2 schemas.

• Base schema This schema will contains all the commons tables like, User tables, Developer Company Tables, User permission tables, Organization Table
• Versioned schema
• This schema contains all the client api related entities.
• "hmis-core-serialization” project will have multiple packages for each version (2014, 2015 and so on)
• "hmis-core-model” project will contains will have multiple packages for each data base version. (2014 , 2015 and so on)
• “hmis-core-service” will be a separate module for each version.(2014, 2015 and so on)
• “hmis-user-service”, “hmis-developer-service” & “hmis-authorization-service” are NOT version dependent applications and all these applications connect to base schema.
• “hmis-clientapi” will have multiple versions for each schema and connect to respective data base schema.

With this approach all the issues with Approach #1 will be addressed however, this approach poses the following issues

• “hmis-core-service” code maintenance is difficult. If any change made related to user, developer and authorization services need to apply same change in all version “hmis-core-service” projects.
• "hmis-core-model” will have multiple classes with same name but different packages. In this case maintenance will be difficult.

Approach 3

They are three kinds of web applications

• Base applications (User Service, Developer Company Service, Authorization Service)
• Version specific application (client-api, bulk uploader )
• Admin application

Data base schema is divided into 2 schemas

• Base schema (contains all base application data base tables like user tables, developer company table, profile tables)
• Version schema it contains all the client data base tables, mapping tables with base tables like sharing rule, user project map, project project group map etc.

Core-model module is divided into two modules,

• One module (base-model) for performing CRUD operations on base schema like creating user, creation trusted app etc.
• A schema specific module (core-model.v2015, core-model.v2016 etc).

Core-service module service project divided into two modules,

One module (base-service) for perform business logic on base schema using base-model project.

A schema specific service module (core-service.v2015, core-servive.v2016 etc). This is module will be dependent on all base modules (base-model, base-service, base-serialize) and respective schema specific core-model and core-serialize modules.

core-serialize module is divided into two modules

• One module (base-serialize) will have all the serialize classes which are common across all the applications and objects required for base-service module.
• For each version we will have separate package for respective models in core-serialize project.

Client APIs

• For each version of data base schema there will be aclient api application, and its dependedent on base-service, core-serialize, versioned core service (like core-service.v2015)

Note:

• With this approach, GET_USER_BASIC_INFO endpoint will be able to fetch "Only" project group details. If user needs project details as well, there will be a separate endpoint that fetches this information from version specific schema.
• Organization controller will be moved to user service from client api application (because organization entity is going to be in the base schema).
• All end points related to sharing rules to be moved to admin application (Because sharing rules entities are moved to version specific schema).