From dd97cefdd89ee2ab182a3a6896ab374a387bc710 Mon Sep 17 00:00:00 2001 From: Eleni Chappen Date: Wed, 13 Mar 2024 10:32:33 -0400 Subject: [PATCH 1/5] add data store ADR --- docs/adr/004_add-a-separate-data-store.md | 53 +++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 docs/adr/004_add-a-separate-data-store.md diff --git a/docs/adr/004_add-a-separate-data-store.md b/docs/adr/004_add-a-separate-data-store.md new file mode 100644 index 00000000..15bd6c2c --- /dev/null +++ b/docs/adr/004_add-a-separate-data-store.md @@ -0,0 +1,53 @@ +# Add a separate data store to app + +Status: + +Draft + +## Context and problem statement + +It's likely that our web app will need a data store in addition to what Cloud Foundry provides. Anticipated uses of this data store include: + +- session management +- user metrics like used platforms, browsers, etc. + +## Decision drivers / forces + +The app is a web UI for Cloud Foundry data, and so the app's primary data source will be from an API. + +Eventually, the app might need to talk to multiple external data sources, especially while other products are consolidated into it. + +While we don't see an immediate need, it's possible that this new data store will need to communicate with other clients besides our app. + +These factors lead us towards an API-first approach. + +## Considered options +1. Use a Cloud.gov RDS (Relational data Base) service with an API, similar to [this approach](https://cloud.gov/pages/knowledge-base/website-api/) or the approach used in [pages-core](https://github.com/cloud-gov/pages-core/blob/b3a1f6e3c55eba7555ba92007908b40b107886a0/docs/DEVELOPMENT.md#deployment) +1. Use a localized data source and switch to MVC (Model, View, Controller) architecture + +## Decision outcome +* Chosen Option: *[option 1]* +* *[justification. e.g., only option, which meets KO criterion decision driver | which resolves force force | ... | comes out best (see below)]* +* *[consequences. e.g., negative impact on quality attribute, follow-up decisions required, ...]* + +### Success criteria + +- We can collect and store the data we need with ease +- We can add more data sources with ease +- The app has secure and compliant ways to communicate with its data sources + + +## Pros and cons of the options + +### 1. Use a Cloud.gov RDS service with an API + +* `+` *[argument 1 pro]* +* `+` *[argument 2 pro]* +* `-` *[argument 1 con]* +* *[...]* + +### 2. Use a localized data store with MVC architecture +* `+` *[argument 1 pro]* +* `+` *[argument 2 pro]* +* `-` *[argument 1 con]* +* *[...]* From 1b222b8760b2f34fad79758b300e60e4f951a63e Mon Sep 17 00:00:00 2001 From: Eleni Chappen Date: Wed, 13 Mar 2024 13:03:54 -0400 Subject: [PATCH 2/5] Update docs/adr/004_add-a-separate-data-store.md Co-authored-by: Brian Hurst --- docs/adr/004_add-a-separate-data-store.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/adr/004_add-a-separate-data-store.md b/docs/adr/004_add-a-separate-data-store.md index 15bd6c2c..76c51d2b 100644 --- a/docs/adr/004_add-a-separate-data-store.md +++ b/docs/adr/004_add-a-separate-data-store.md @@ -10,6 +10,8 @@ It's likely that our web app will need a data store in addition to what Cloud Fo - session management - user metrics like used platforms, browsers, etc. +- allowing users to set preferences that can persist +- tailoring the experience based on user roles/attributes ## Decision drivers / forces From 82b5fbaefc2b08d5a1b8513e56b3ca26ee1280b2 Mon Sep 17 00:00:00 2001 From: Jessica Dussault Date: Wed, 13 Mar 2024 13:27:31 -0500 Subject: [PATCH 3/5] updates datastore ADR choices and possible data --- docs/adr/004_add-a-separate-data-store.md | 36 ++++++++++++++++------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/docs/adr/004_add-a-separate-data-store.md b/docs/adr/004_add-a-separate-data-store.md index 76c51d2b..f23a8e39 100644 --- a/docs/adr/004_add-a-separate-data-store.md +++ b/docs/adr/004_add-a-separate-data-store.md @@ -1,17 +1,23 @@ # Add a separate data store to app -Status: - -Draft +Status: Draft ## Context and problem statement It's likely that our web app will need a data store in addition to what Cloud Foundry provides. Anticipated uses of this data store include: -- session management -- user metrics like used platforms, browsers, etc. -- allowing users to set preferences that can persist -- tailoring the experience based on user roles/attributes +- users + - session management + - metrics like used platforms, browsers, etc. + - preferences that can persist + - tailoring the experience based on user roles/attributes +- orgs / agencies + - billing and agreements + - correlating the same person across multiple origins +- compliance + - scan artifacts + - compliance status and ATO information +- external connections such as GitHub tokens ## Decision drivers / forces @@ -24,11 +30,12 @@ While we don't see an immediate need, it's possible that this new data store wil These factors lead us towards an API-first approach. ## Considered options -1. Use a Cloud.gov RDS (Relational data Base) service with an API, similar to [this approach](https://cloud.gov/pages/knowledge-base/website-api/) or the approach used in [pages-core](https://github.com/cloud-gov/pages-core/blob/b3a1f6e3c55eba7555ba92007908b40b107886a0/docs/DEVELOPMENT.md#deployment) +1. Use a database service with a tightly coupled API built into the dashboard application. This is similar to the approach used by [pages-core](https://github.com/cloud-gov/pages-core/blob/b3a1f6e3c55eba7555ba92007908b40b107886a0/docs/DEVELOPMENT.md#deployment) +1. Use a database service with a separately managed API, similar to [this approach](https://cloud.gov/pages/knowledge-base/website-api/) 1. Use a localized data source and switch to MVC (Model, View, Controller) architecture ## Decision outcome -* Chosen Option: *[option 1]* +* Chosen Option: *[tbd]* * *[justification. e.g., only option, which meets KO criterion decision driver | which resolves force force | ... | comes out best (see below)]* * *[consequences. e.g., negative impact on quality attribute, follow-up decisions required, ...]* @@ -41,14 +48,21 @@ These factors lead us towards an API-first approach. ## Pros and cons of the options -### 1. Use a Cloud.gov RDS service with an API +### 1. Tightly coupled API + +* `+` *[argument 1 pro]* +* `+` *[argument 2 pro]* +* `-` *[argument 1 con]* +* *[...]* + +### 2. Separately managed API * `+` *[argument 1 pro]* * `+` *[argument 2 pro]* * `-` *[argument 1 con]* * *[...]* -### 2. Use a localized data store with MVC architecture +### 3. MVC architecture * `+` *[argument 1 pro]* * `+` *[argument 2 pro]* * `-` *[argument 1 con]* From 0eb0e6c99dc52db23eddd1ca3bd0f78d1d214061 Mon Sep 17 00:00:00 2001 From: Jessica Dussault Date: Fri, 22 Mar 2024 09:33:28 -0500 Subject: [PATCH 4/5] adds to datastore adr --- docs/adr/004_add-a-separate-data-store.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/adr/004_add-a-separate-data-store.md b/docs/adr/004_add-a-separate-data-store.md index f23a8e39..dd818b9e 100644 --- a/docs/adr/004_add-a-separate-data-store.md +++ b/docs/adr/004_add-a-separate-data-store.md @@ -21,11 +21,11 @@ It's likely that our web app will need a data store in addition to what Cloud Fo ## Decision drivers / forces -The app is a web UI for Cloud Foundry data, and so the app's primary data source will be from an API. +The dashboard app is a web UI for Cloud Foundry data, and the app's primary data source will be from an API. Eventually, the app might need to talk to multiple external data sources, especially while other products are consolidated into it. -While we don't see an immediate need, it's possible that this new data store will need to communicate with other clients besides our app. +While we don't see an immediate need for a datastore to communicate with other clients besides our application, it is a future possibility. These factors lead us towards an API-first approach. @@ -50,17 +50,17 @@ These factors lead us towards an API-first approach. ### 1. Tightly coupled API -* `+` *[argument 1 pro]* -* `+` *[argument 2 pro]* -* `-` *[argument 1 con]* -* *[...]* +* `+` Managing the API alongside the same application / repository means less overhead for development and deployment +* `+` Builds for our current needs rather than theoretical futures +* We will be build database models, migrations, and the API in the same tech stack as our app, which means we are beholden to its abilities +* `-` In the future, we risk storing and managing data that would be better off pulled into our app rather than being owned by it +* `-` Using out of the box software for an "admin" view would likely be distinct from the rest of the application ### 2. Separately managed API -* `+` *[argument 1 pro]* -* `+` *[argument 2 pro]* -* `-` *[argument 1 con]* -* *[...]* +* `+` Plans for a potential future where our application pulls in data from multiple APIs / sources, and where the datastore serves multiple applications +* `+` Allows for selection of technology / framework specifically for API with database backend +* `-` More overhead for our current team to support: two applications, separate authentication flow, deployment, maintenance, security scanning, etc. ### 3. MVC architecture * `+` *[argument 1 pro]* From e34dc3d5beaef659d24a4915a47707bfaf0b4aaa Mon Sep 17 00:00:00 2001 From: Jessica Dussault Date: Mon, 1 Apr 2024 17:54:15 -0500 Subject: [PATCH 5/5] adds to datastore doc --- docs/adr/004_add-a-separate-data-store.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/adr/004_add-a-separate-data-store.md b/docs/adr/004_add-a-separate-data-store.md index dd818b9e..4ce7f6ae 100644 --- a/docs/adr/004_add-a-separate-data-store.md +++ b/docs/adr/004_add-a-separate-data-store.md @@ -39,27 +39,27 @@ These factors lead us towards an API-first approach. * *[justification. e.g., only option, which meets KO criterion decision driver | which resolves force force | ... | comes out best (see below)]* * *[consequences. e.g., negative impact on quality attribute, follow-up decisions required, ...]* -### Success criteria +### Success criteria - We can collect and store the data we need with ease - We can add more data sources with ease - The app has secure and compliant ways to communicate with its data sources -## Pros and cons of the options +## Pros and cons of the options ### 1. Tightly coupled API * `+` Managing the API alongside the same application / repository means less overhead for development and deployment * `+` Builds for our current needs rather than theoretical futures -* We will be build database models, migrations, and the API in the same tech stack as our app, which means we are beholden to its abilities -* `-` In the future, we risk storing and managing data that would be better off pulled into our app rather than being owned by it -* `-` Using out of the box software for an "admin" view would likely be distinct from the rest of the application +* `-` The API would be in the same stack as our app, NextJS, which does not come out of the box with support for models, migrations, database-related tests, nor object relationship mapping (ORM). We would need to invest in additional work to implement these +* `-` We risk storing and managing data that would be better off pulled into our app rather than being owned by it +* `-` Out of the box software for an "admin" view would likely be distinct from the rest of the application and lead to two separate applications in the same repo ### 2. Separately managed API -* `+` Plans for a potential future where our application pulls in data from multiple APIs / sources, and where the datastore serves multiple applications -* `+` Allows for selection of technology / framework specifically for API with database backend +* `+` Anticipates a potential future where our application pulls in data from multiple APIs / sources, and where the datastore serves multiple applications +* `+` Allows for selection of technology / framework specifically for an API with database backend * `-` More overhead for our current team to support: two applications, separate authentication flow, deployment, maintenance, security scanning, etc. ### 3. MVC architecture