Figure out MVP backend architecture/technologies

[sharmaneil]

The prototype right now is a static-site with no backend. Depending on what the MVP looks like, we'd need a solution for:

Acceptance criteria:

Updated Nov 2, 2020

• [x] decided on a database
• [x] decided on a backend/API
• [x] shared understanding of what the priorities are for the next prototype version (ie: multi-user, sync, offline, etc)

Questions to answer:

• by which stage do we need to support multiple users simultaneously (this sounds like an MVP requirement)
• should the backend serve the client app
• do we need to make requests to the data hub routing services

In other tickets: ~- persisting users~ ~- authenticating users~ ~- logging/analytics~

[pete-gov]

For data storage / sync / transfer I recommend we use existing solutions rather than rolling our own. Implementation would require changing the way we store documents a tiny bit, but would be overall much easier. Examples include:

• https://github.com/share/sharedb : "ShareDB is a realtime database backend based on Operational Transformation (OT) of JSON documents."
  • Realtime synchronization of any JSON document
  • Concurrent multi-user collaboration
  • Synchronous editing API with asynchronous eventual consistency
  • Realtime query subscriptions
  • Simple integration with any database - MongoDB, PostgresQL (experimental)
  • Offline change syncing upon reconnection
  • etc.
• https://pouchdb.com/ : "PouchDB is an in-browser database that allows applications to save data locally, so that users can enjoy all the features of an app even when they're offline. Plus, the data is synchronized between clients, so users can stay up-to-date wherever they go."
  • ... designed from the bottom-up to enable easy synchronization between different databases.
  • It is framework-agnostic, and you can use it with Angular, React, Ember, Backbone, or your framework of choice
  • your backend needs to speak the CouchDB replication protocol.
  • PouchDB is just a script tag and 46KB (gzipped) away in the browser
• https://turtle-db.github.io/ : "Web applications will work seamlessly online or offline, and developers can leave the backend to turtleDB - it will handle all data synchronization and conflict resolution between users. Works with MongoDB out of the box!"
  • fairly new, haven't used this one
• https://github.com/pubkey/rxdb/blob/master/README.md : "To replicate data between your clients and server, RxDB provides modules for realtime replication with any CouchDB compliant endpoint and also with custom GraphQL endpoints. "
  • first read about this here: https://news.ycombinator.com/item?id=24340802
  • seems a bit cutting edge but also moving very fast
  • fairly in depth example here: https://slacker.ro/2020/01/06/building-an-offline-first-web-app-with-rxdb-hasura/

If possible it probably makes sense to just default to any such system that our devs have experience with, if anyone else has used one of these?

[sharmaneil]

Thanks for the initial research.

I haven't used any of these, but we can check with the the new engineers next week. Of the options listed, Pouch and RxDB seems interesting! It's a bit hard to evaluate without playing around with them.

I've used firebase way back when for real-time syncing, but sounds like google may be out of the question. I've used dynamodb for tiny scrappy projects, but not for any real-time work.

If it helps to evaluate, here are some of the queries we'd need:

MVP must-haves:

• uploading patient (single)
• adding to queue
• removing from queue
• submitting test result

MVP maybes:

• uploading patients (bulk)
• archiving patient
• update global settings
• update ordering provider
• exporting csv (should happen on the backend, could happen on the frontend)
• updating testResult (ie: has it been reported or not)
• adding device
• updating device
• removing device

Post-MVP:

• real-time patient-search
• ...lots of stuff, tbd

[pete-gov]

Theoretically on the must-haves, those can all be sync based operations (sync from local). I think most of the maybes should be the same (also doable via syncing local data). That makes this a lot easier.

[sharmaneil]

AWS also has appsync https://aws.amazon.com/appsync/?sc_ichannel=ha&sc_icampaign=acq_awsblogsb&sc_icontent=mobiledev-resources

Might be a little more work to setup for an MVP tho, but could be a better long-term solution

[pete-gov]

Some of this is already in other tickets so I'm going to pull them out of this for now:

User Management / Auth is here: https://github.com/CDCgov/prime-central/issues/89

Analytics (placeholder) here: https://github.com/CDCgov/prime-central/issues/67

[aliciabeckett-gov]

@sharmaneil not sure we can guarantee our hosting platform will be AWS. @RickHawesUSDS has more details here. But wanted to warn you early on.

[sharmaneil]

In that case, I'm going to try out one of the databases in Pete's suggestions instead of picking something AWS-specific. If we don't decide soon, it'll create tech debt if we ever want to switch databases, but that may be unavoidable.

For our non-prod apps, cloud.gov seems to have a limited set of managed database options:

• redis
• s3
• postgres, mysql, oracle https://cloud.gov/docs/services/relational-database/

Don't know what the LoE is to spin up a different database

[RickHawesUSDS]

@sharmaneil Suggest Postgres because it is open-source, works on dev machines, and can be deployed anywhere including the environments being considered. You can also just store JSON in Postgres, if that makes things go faster.

[sharmaneil]

Building off of the recs and research so far, here's an idea:

MVP: postgres + graphql + hasura (backend)

• hasura - an open source Backend as a Service to create graphql APIs
  • this should minimize our need to write our own backend, and comes with a lot of handy tooling around graphql
  • comes with JWT auth support
  • has postgres adapters
• graphql
  • comes with subscriptions built in, so it lays the groundwork for sync (for multiple simultaneous users).
  • USDS has engineers who know and use this, so we have lean on them for support if needed
• this can be dockerized and deployed in any environment, which is helpful if we end up going the self-hosting route
• cons:
  • could take some time to learn and setup
  • hasura has a paid, managed version. It is unclear if the benefits of hasura exist in both the open source and paid versions.

Post-MVP: add RxDB for offline support

• RxDB - this is a wrapper around client-side databases. It uses observables, which is a javascript programming paradigm that deals with streaming data.
• RxDB could be configured to use graphql to sync with the db instead of the more common couchDB path.
• cons:
  • RxDB + graphql is a little fuzzy in terms of documentation
  • more things to learn and setup
  • not sure how this plays with redux

Not wed to anything; we can discuss more early next week.

[sharmaneil]

Another option for offline support: Redux Offline

Pros:

• seems easy to use, esp since we are already using redux
• has support for optimistic, pessimistic offline requests, as well as rollbacks if things don't work

Cons:

• doesn't have any proactive conflict resolution strategy baked in, but maybe the app is simple enough that we don't care.

[pete-gov]

Some of these options still look like building a lot of stuff to make them work (i.e. Redux Offline seems to primarily be built to handle network resilient API calls rather than data synchronization out of the box, so we have to build that API). I think we'd be best off avoiding anything more complex that basic data sync for early stages, but we keep coming back in this direction so maybe that's the way we need to go.

[aliciabeckett-gov]

@pete-usds - can you give an order of magnitude or time difference for what it means to build a lot of stuff vs. not build a lot of stuff? Want to make sure we're coming from the same set of assumptions about what is acceptable vs. not.

[sharmaneil]

I think we should have a synchronous discussion with the expanded eng team today/tomorrow to see what skillsets folks have and figure out what path makes sense. Doesn't seem like we're moving toward a consensus, and several of the engineers who'd be working on this aren't in this thread.

I'd like to roll out a locally-running solution to all of this -- wired to the frontend -- in this sprint, so making a decision soon here would be helpful

[RickHawesUSDS]

@sharmaneil I think GraphQL makes a lot of sense for the PDI backend. No experience with Hurusa, but it looks like a fit on the surface.

[aliciabeckett-gov]

Did the synchronous discussion happen? Also, let me know if I can be helpful on:

• [ ] shared understanding of what the priorities are for the next prototype version (ie: multi-user, sync, offline, etc)

Overall my number 1 priority is avoiding data loss of test results. That would completely destroy trust in our app.

[sharmaneil]

Decision

Based on the latest discussion with @RickHawesUSDS @benwarfield-usds and @nickrobison-usds, the tech stack decision is:

• Java Spring Boot
• Postgres
• GraphQL

Rationale

Benefits

• we need to move fast, and If Ben and Nick would be doing most of the backend work, it makes sense to do what they are comfortable with
• GraphQL seems like a meaningful quality-of-life upgrade over REST from a front-end perspective, and Java <-> GraphQL bindings are established (ie: https://www.graphql-java.com/tutorials/getting-started-with-spring-boot/)
• USDS has experience in graphQL, so we have folks we can lean on if needed.
• this is a familiar tech stack to contractors

Tradeoffs

• Ben has 6 months left at the USDS and we may lose most of our java backend skills. This may mean we'd need to rewrite it 4-6 months from now (likely to node/express). The server code should be relatively small given the size of our app, so it should be doable.
• unless engineers are comfortable with both javascript and java, our team would be split into frontend vs backend instead of full stack.

[pete-gov]

Final acceptance criteria checkbox is addressed by this Epic from Alicia: https://github.com/CDCgov/prime-central/issues/105

tl;dr: multi-user sync, but not offline.

Going to go ahead and close this out, woo!