navapbc/wic-mt-demo-project-eligibility-screener

Eligibility screener for State of Montana Special Supplemental Nutrition Program for Women, Infants, and Children (WIC)

WIC Eligibility Screener

This eligibility screener for the Special Supplemental Nutrition Program for Women, Infants, and Children (WIC) was developed for the State of Montana. It was designed so that, with a little bit of work, it could be adapted to the needs of other agencies. A demo of the project can be found at https://wic-eligibility.demo.navapbc.com. The storybook for the project can be found at https://navapbc.github.io/wic-mt-demo-project-eligibility-screener.

Contents

This template includes setup for:

• .github: common GitHub configuration, such as a PR template and GitHub workflows
• app: the Next.js application
• docs: project documentation

How to Run

Connecting to API

The eligibility screener application is designed to send data it collects to an API (see example). However, by default, this application assumes that the application is NOT running in tandem with an API and will run in "demo mode".

To turn off demo mode, configure the following environment variables:

• API_HOST: The url of the API including http/s protocool
• API_AUTH_TOKEN: The authentication token required to connect to the API

If you are running in development (i.e. using yarn dev), then set the environment variable NEXT_PUBLIC_DEMO_MODE to "false". If you are running in production (i.e. using yarn start), then set the docker build argument NEXT_PUBLIC_DEMO_MODE to "false". Do not set the environment variable when in production. Nextjs will report console errors if you do.

See /docker-compose.yml and /app/Dockerfile for more details.

Without Docker

You can run the Next.js app without docker as follows:

1. yarn install
2. yarn dev
3. Navigate to localhost:3000 in your browser to view the application

You can run storybook without docker by running:

1. yarn storybook
2. Navigate to localhost:6006 in your browser to view storybook

With Docker

The Next.js application is dockerized. Take a look at ./app/Dockerfile to see how it works.

A docker-compose.yml has been included to support local development. Take a look at ./docker-compose.yml for more information.

2. Make sure you have Docker Desktop installed & running.
3. Run docker-compose up -d --build to build the image and start the container.
4. Navigate to localhost:3000 in your browser to view the application. Note that it takes a few minutes for the initial sass compiling to complete and load.
5. Run docker-compose exec nextjs yarn storybook to build and run storybook. Note that the initial compiling for storybook also takes a few minutes to complete and load.
6. Navigate to localhost:6006 in your browser to view storybook.
7. Run docker-compose down when you are done to delete the container.

To support local development, the docker-compose.yml runs the nextjs container in development mode (i.e. yarn dev) instead of production mode (i.e. yarn start). This allows Next.js to do things like hot reload.

The docker-compose file bind mounts app on the host machine to /srv in the guest machine. However, to ensure that the container uses the correct packages in node_modules, we use a named docker volume for the node_modules dir. The named volume will take precedence over the bind mount, so that the node_modules dir in the guest machine will not be overwritten with the host machine's node_modules dir. This also means that if you run yarn add <package> on the host machine in development (which will update yarn.lock), you'll also need to run docker-compose exec nextjs yarn install --frozen-lockfile to update node_modules in the guest machine.

Disclaimer

This public repository exists purely for the purposes of hosting a snapshot of code to serve as a reference for similar efforts and is therefore not actively maintained. Entities wishing to use this code should do standard security due diligence and make sure to use up-to-date dependencies.

wic-mt-demo-project-eligibility-screener's Issues

Migrate Modules (Networking)

This ticket is part of the tech spec that came out of #196. The other ticket proposals can be read here

Context: This ticket involves migrating network configuration from the infra-template to the eligibility screener. While not much work is needed, these configurations span quite a few files.

Work involved:

• Make sure the networking resources are configured in a way that matches the infra-template
• Networking.tf (screener) is fairly close to what we should see in
• Make sure the networks module is copied over and called appropriately.

Definition of Done: Terraform can plan and apply successfully, screener has no change in functionality.

Migrate Github Workflows

This ticket is part of the tech spec that came out of #196. The other ticket proposals can be read here

Context: Similarly to the initial migration ticket, this ticket is focused around copying files from the infra-template.
Work Involved:

• Copy over GH workflows from the infra-template
• Copy the cd-storybook and the ci-app jobs from the NextJS template
• Do not replace the README files in the screener
• Ensure that workflows keep their functionality while matching what is in the infra template
• Cd.yml in the screener will need to have its functionality split to match the build-and-publish and cd-app in the infra-template

Definition of Done: All of the workflows work as intended.

Tech spec for re-implementing infra using the v0.2.0 release of the infra template

Context

The MWDP project originated the infra template. Since then, a lot of progress has happened on the infra template, but this project's infra has stayed static.

In this previous tech spec, we outlined what it would look like to migrate to the infra template. This tech spec asks a slightly different question. I would like to know what it would take to re-implement the infra for the eligibility screener (in other words, starting over) using v0.2.0 release of the infra template. Imagine we could destroy the current AWS account and start fresh.

Tasks

Create a tech spec that:

1. Outlines what AWS resources are needed to deploy the eligibility screener (e.g. ECR, ECS, IAM, etc)
2. Outlines the new CI/CD process and any changes that need to be made to the github repo
3. Explains pros/cons of re-implementing
4. Outlines risks for re-implementing
5. Estimates the amount of effort to re-implement
6. Outlines the plan for re-implementing
7. Outlines the plan for testing the implementation (can be very simple!)

Notes: This tech spec can and should re-use content from the previous tech spec where relevant.

Begin Migrating Files from Template-infra

This ticket is part of the tech spec that came out of #196. The other ticket proposals can be read here

Context: This ticket is all about getting the initial framework for migrating the infra template.

Work involved:

• Create a new terraform workspace locally
• Copy over template files from directories that don’t have an equivalent in the eligibility screener.
• bin directory
• Root-level files such as Makefile, trivy-secret.yml etc.
• Do not replace the README files in the screener

Definition of Done: Files are successfully copied over from the infra-template and pass basic linting

Migrate Modules (Database)

This ticket is part of the tech spec that came out of #196. The other ticket proposals can be read here

Context: The database isn’t necessary for running the eligibility screener. This ticket is more about cleanup for consistency sake.
Work involved:

• Remove the database configuration from service.tf in the eligibility screener
• Make sure the database in AWS is spun down
• Clean up any other resources that reference the database (e.g. security groups)

Definition of Done: The eligibility screener demo functions normally

Document Eligibility Screener demo domain setup

Context

This ticket builds on top of navapbc/wic-participant-recertification-portal-demo#7. All the same considerations should be taken into account for this demo site:

• Eligibility screener: https://wic-eligibility.demo.navapbc.com

Task

• Confirm that Option 1 is indeed how we set up the domain for the eligibility screener
  • Things to consider: How will you demonstrate that this true? Links to AWS pages? Screenshots? Links to AWS documentation?
• Document the domain setup process in this Confluence page
  • Don't overthink this. It should be at most 1-2 paragraph long (but they can be densely linked paragraphs).
  • Build on top of the documentation in this related ticket on PRP demo domain documentation
• Document any ongoing tasks that need to happen
  • This will include the certificates being renewed. Anything else?

Migrate Modules(ECS Service)

This ticket is part of the tech spec that came out of #196. The other ticket proposals can be read here

Context: This ticket involves migrating a module from the infra-template to the eligibility screener, however it will require maneuvering a few resources, and making sure that the module references correct information(e.g. AWS account, dynamo DB table)
Definition of Done: Terraform can plan and apply successfully, screener has no change in functionality.