M-Nicholls
commented
4 years ago Take out the admin DQ controller -> new project with domain objects, Quality service, etc moved across (https://github.com/AtlasOfLivingAustralia/DataQuality/issues/110)
webservice UI in front of the methods and code (https://github.com/AtlasOfLivingAustralia/DataQuality/issues/111)
Webservice client for accessing the methods - retrofit based (https://github.com/AtlasOfLivingAustralia/DataQuality/issues/112)
ALA hub - replace and use of the service with the webservice client equivalent call (https://github.com/AtlasOfLivingAustralia/DataQuality/issues/113)
ALA install for deployment (https://github.com/AtlasOfLivingAustralia/DataQuality/issues/114)
Adding for an issue to track this discussion started with Simon and Miles.
We should look into the potential of pulling most of the DQ functionality into a separate standalone service. It may serve us well to tackle this prior to further integration of DQ filters into other ALA components as covered in these issues:
https://github.com/AtlasOfLivingAustralia/DataQuality/issues/105 https://github.com/AtlasOfLivingAustralia/DataQuality/issues/74
The bulk of the DQ functionality could be implemented as a separate tool which supports an admin interface for the configuration and web services for integration in front end apps. With this approach we can keep
biocache-hubsas a front end only application (with no DB/Backend). This may prove important when we tackle stage 3 of the infrastructure project which look into the feasibility of replacingbiocache-hubswith GBIF’s front end and web services (this is all subject to a scoping exercise).