search

OHDSI / WebAPI

OHDSI WebAPI contains all OHDSI services that can be called from OHDSI applications
Apache License 2.0
126 stars 156 forks source link

WebAPI 3.0 Change List #2354

Open chrisknoll opened 4 months ago

chrisknoll commented 4 months ago

Starting this thread to capture WebAPI 3.0 proposed changes New suggestions can be raised in comments and those that make sense can be promoted up to the top thread. This list is not exhaustive but is geared towards the changes that would alter existing functionality in a backwards-breaking change (hence the 3.0 version bump).

Major Version Changes

  1. Update JDK to JDK 17+
  2. Security is no longer optional
  3. Permission Rewrite
  4. Update Java Libraries to Latest Versions
  5. Caching Implementation
  6. Analysis Execution Pipeline via Strategus (including new Analysis Designs deprecating old)
  7. Refresh Flyway Migrations: Remove old non-supported Flyway Migrations
  8. Maven Dependency Management
  9. Remove outdated endpoints that don't have function.
  10. Make necessary changes to support multi-homed (ie: load-balanced) configuration
  11. Leverage websockets to faciliate server-side changes (ie: polling for cohort generation status)
  12. Integrated runtime statistics (time spent in queries, time spent processing results, cache hits/misses) so we can understand runtime dynamics.
  13. Move away from storing execution status in job table.

Notes

This section captures notes about items in the above list, as well as reasons why something is not in the list.

  1. Module System: There has been discussion about making WebAPI more modular to support customization. While this is something that could be discussed as a 3.x feature, it's not something that currently exists in 2.x. This Issue is focusing on current functionality that changes in a backwards-breaking way. A better approach implementing modules (or miicro services) would be to start a new project with that architecture in mind).
chrisknoll commented 4 months ago

I should also add that the OP list is not the list of changes that must go into next release, just the list of things that would 'break' 2.x compatibility. There was an issue raised that if we didn't do all of these for 3.0, that the ones introduced later would be breaking changes spawning a 4.x release, but we can decide how major we want the 3.x line of changes to be and if a 4.x is required later, then we will live with that decision.

anthonysena commented 3 months ago

Noting that we may want to consider JHipster per @ecruz165 : https://www.jhipster.tech/

qcaas-nhs-sjt commented 3 months ago

I would like to suggest that it might make some sense to split up the WebAPI java into multiple component libraries based on subject areas rather than one big one, each library can then be versioned and tested in isolation before being integrated into the overarching project. This should reduce build times and should have other benefits.