Skip to content

[173] Adds Architecture Decision Record for app containerization discussion. #181

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

AlexanderNull
Copy link
Member

@AlexanderNull AlexanderNull commented Aug 11, 2025

What type of PR is this? (check all applicable)

  • Refactor
  • Feature
  • Bug Fix
  • Optimization
  • Documentation Update

Description

Attempts documenting potential decision for containerization of the application

Related Tickets & Documents

QA Instructions, Screenshots, Recordings

Attempt to read the docs, if they are not readable then fail QA

Added/updated tests?

  • Yes
  • No, and this is why: documentation change only
  • I need help with writing tests

[optional] Are there any post deployment tasks we need to perform?

None

Copy link
Contributor

@yangm2 yangm2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for bringing a structured process to the analysis. I added some comments (to one, but could be applied to all) to explicitly call out some assumptions and get additional details. Perhaps the answer to all of those are 'NA', but it's good to acknowledge that as part of the decision.

Comment on lines +31 to +34
## Considered Options Utility Scripts
* Run RAG generation script manually & locally
* Run RAG generation script in GH actions on change
* Deploy RAG generation script as Cloud Function
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing Pros & Cons for Utility Scripts

Comment on lines +62 to +63
* Good, because likely the cheapest solution
* Bad, because more GCP infrastructure to track
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming it is minimal, but might be worth noting relative performance metrics. It would be good to know if the payload (can the size be estimated/quantified? or just define a reasonable upper-bound?) for static content meaningfully slows down the initial page loading. Would this make any difference to mobile?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this affect developer experience at all? Testing? Browser compatibility (e.g. Safari)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this affect site security (i.e. smaller/larger/different attack surface?) or maintenance (i.e. audit/update JS dependencies, additional secrets management)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Audit the project for Containerization
2 participants