navapbc/platform

A platform that empowers teams to accelerate delivery through self-service tools and training.

platform's Issues

Feature idea: Low-risk functionality as repeatable starter task

idea from Kevin Boyer: API endpoint returns a static list of the contributors to the project

see slack thread

Create template structure for architectural decision records

See https://adr.github.io/

Document scanning service

Architecture diagram templates

It takes a lot of time to create architecture diagrams on a project. It would be beneficial to have templates for the common architecture patterns, especially ones that use the infra template's default system design.

The templates could probably just live in LucidChart for now.

Once the template's are created it would be good to have some documentation in template-infra about the templates.

Python package with Flask blueprints for common resources

Idea: common resources like user can have common Flask blueprints.

While this idea isn't fully fleshed out, and it isn't 100% clear if Flask blueprints in an importable package is the right technical direction, but the idea of building tools around common data schemas could be further explored.

Web analytics service

Create a proof-of-concept end-to-end (E2E) starter repository

The E2E starter proof-of-concept should have:

1. a simple toy application (e.g. https://github.com/navapbc/template-infra/tree/main/app)
2. some simple playwright tests against the toy app

In addition, the proof-of-concept should address the technical implementation considerations found in the related 🔒 tech spec:

1. Provide scaffolding for Playwright configuration
2. Include an example test
3. Document initial configuration settings and setup requirements and an overview of how to run these tests as part of local development
4. Integrate Playwright with CI/CD as part of a Github Actions workflow

References

This work will help answer the last outstanding question in the "End-to-end starter" 🔒 tech spec around whether it makes sense to create a separate E2E starter template or to embed an E2E starter in existing application templates.

Related repository: https://github.com/navapbc/template-e2e

Document generator service

Add reference implementations that use the platform

Support multi-app repos

Related (or duplicate?): navapbc/template-infra#238

NPM Module for managing application flow as state machine

More complex user-facing applications, especially ones that intake claims/applications/cases often need to manage the application flow. A best practice is to manage this with a state machine and abstract it into a flow management module. This approach also provides useful product development tools like visualizing the application flow as a flowchart diagram.

This issue is to capture the idea of making a reusable module for this functionality. The current vision for the implementation approach would be to implement this as a separate npm module, and it could be imported by default in https://github.com/navapbc/template-application-nextjs. That would make it easier to rip out than if the code was baked into the application template itself.

Scope

Scope of this ticket should include designing the npm module (e.g. in a tech spec) prior to implementation

Spike: Automated testing for platform

How do we automatically test the platform e2e, from installation to deployment?

User can follow instructions on how to use template-infra with either of the template applications

Context

Now that we split up the infra and application templates, we need to help the user of the platform understand how to use the two pieces together. We'll probably need to provide some instructions (and perhaps some tools if applicable) for the user to be able to use the template-infra with either of the template applications (template-application-nextjs or template-application-flask).

Split up platform repos into infra, application repos, and landing page repo

Context

• See Slack thread #1
• See Slack thread #2

We now need to support multiple application stacks (python in addition to javascript), but don't want to duplicate the infra code. So the solution we are proposing is to separate out the reusable infra from the application repos. The result will be several repos:

• platform – this would basically a “home page” that is mostly documentation with an index to the other repos and has instructions on how to use the other repos together
• template-infra
• template-application-nextjs
• template-application-flask
• template-application-rails

Other possible scope would be to add some reference implementations

Create a guide for how to combine multiple platform templates into a single monorepo

Each platform template is a separate repo because we want to maintain modularity and isolate dependencies. However, our projects frequently prefer to have a single monorepo to more easily manage a project.

Add a guide (or script) to support teams who wish to do this.

Move repo setup instructions out of the template repo readme(s) and into the platform repo

Move repo setup instructions out of the template repo readme(s) and into the platform repo, so there’s a single place to maintain

See slack thread

Notifications service

Platform template for static applications

Context

We may want a template for static applications sooner than later.

Note that even for the NextJS template, it will have a Storybook component that is a static application that should be deployed.

Data warehouse

Define metrics for how long each platform feature took to implement

see slack thread