Multi Schema Support (Versioning)
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)
- 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.
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.
- Base applications (User Service, Developer Company Service, Authorization Service)
- Version specific application (client-api, bulk uploader )
- Admin application
- 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.
- 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).
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.
- 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.
- 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)
- 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).
