Provide API access for online users

[garethbowen]

What feature do you want to improve?

For performance online users don't download data to their device. When this was first implemented the simplest approach was to use PouchDB with online users having the http adapter. This means that the webapp can query a single API and PouchDB handles whether the data comes from IndexedDB or CouchDB over http. To enable this proxied all their requests direct to couch which in turn means we've exposed the entire CouchDB API for administrators to use. While this works, it means we're exposing implementation details without any guarantee of backwards compatibility which can get implementers in to trouble.

Describe the improvement you'd like

Instead we should block direct access to CouchDB and provide a complete set of APIs to allow implementers access with a guarantee of backwards compatibility. For this issue specifically, target online users of the webapp. This will provide a lot of APIs for common requests.

To achieve this will require significant changes to webapp to remove direct access to PouchDB. Specifically, create a DB service which exposes a strongly typed API that is called everywhere PouchDB is currently called. This API will return specific types (eg: Patient, Report, Form) and abstract away the access method. The implementation of the API on the webapp will either issue queries to PouchDB or issue requests to APIs depending on whether the user is online or offline. The implementation of the API will ultimately make the same requests to CouchDB as the webapp makes to PouchDB so this should be a shared lib.

This architecture gives us a client side API and a server side API that are identical and abstract away the underlying database and schema, making it easier for Core and App developers to work with, as well as allowing for schema changes without disruption, and even replacing Pouch or Couch if necessary in future.

Describe alternatives you've considered

Additional context

[garethbowen]

Discussion doc (private) for how this might work.

[mrjones-plip]

Talking to @kennsippell, he confirmed that these three APIs are using the CHT User Management Tool, all three of these in the `chti-api.ts' file:

• Download all contacts with a specific type getPlacesWithType
• Given a contact, we download their parent and all siblings getParentAndSibling
• Get a single doc with id getDoc

It would be great if the first update on this ticket (a sub ticket if you will) would be to address this use case so that we could get good impact by upgrade a production instance to no longer use these APIs.