# Quick Organics

## Tech Stack

### Backend

Rest APIs powered by
- Python/Django, or
- NestJS (a Nodejs framework)

An admin panel will be made available for direct access to the raw data

### Database

Postgres

### User Auth

Options:
- Builtin Django authentication backed by our own database
- Third-party auth, like
- Firebase auth
- Auth0

APIs would be stateless, guarded by JWTs.

#### Roles

The Figma doesn't indicate that there are users with varying levels of access. We assume that there are only two types of users - the end user and Administrator. Administrators would have access to the admin panel.

### Frontend

- React
- Chakra UI (for those not in the know it is like a "React" version of Tailwind)
- React Query (for query caching and retries)
- Redux? (it's a lot of overhead; will use only if absolutely necessary)

#### Atomic Design

UI components will be built from the bottom up. Reusable "atoms" (like buttons, dropdowns, file upload controls, etc) will be followed by higher level "molecules" like popup modals, headers, etc. Atoms and Molecules will then be used as lego bricks to assemble top level screens.

### Ops/Infra

- Gitlab for code repo
- Gitlab CI for CI/CD
- Google Container Registry for hosting our docker images
- Google Cloud Build
- Google Cloud Run for stateless, serverless app deploys
- Google Cloud Storage for storing uploaded files and other static assets
- Google CloudSQL database (this is probably gonna be the biggest recurring cost for now)
- Cloudflare for CDN + DDoS protection

**Note:** Google Cloud Run is a fully managed service that lets one deploy and run stateless, serverless apps. It can scale up and down (to zero, if required) based on traffic.

## OSP Forms

It would be best to "templatize" the OSP screens. To that end we need a comprehensive set of questions and their posible responses, including validation conditions, if any. Armed with that information we'll create a generic template which can consume any (known) question type and render it on the screen.

Alternatively, we could hardcode all questions in the frontend. Not the most flexible approach.

### Open Questions

- exactly how does one navigate back and forth between questions?
- it is unclear what happens when the user reaches the end of the flow; going by the Figma it does appear as if the user is emailed a copy of their responses. What else needs to happen?

## Document Repository

- Frontend: React Dropzone
- Documents will be uploaded to Google Cloud Storage
- Each uploaded file will be backed with an entry in our database
- Renaming and deleting files will be supported

## Schema design

- Boilerplate stuff like Users, Documents
- OSP questions and responses: this will probably be the most complex part

## Emails

Building HTML emails requires setting up a style system for compatibility across as many email clients and devices as possible.

### Generating PDF Files

There is at least one flow which involves generating and emailing a PDF file on the fly. This would require one of these:

1. setting up another microservice for PDF generation
2. using a third-party service like [PDF Monkey](https://www.pdfmonkey.io)

## Major Risk: Browser Support

Supporting Internet Explorer < v11 will be a challenge. Some features may not work while other could be plagued with "broken" UI layout issues.

Possible solutions (in decreasing order of preference):

- lead with a mobile-first webapp and force desktop users to use Edge/Chrome/Firefox
- polyfill for IE 9, 10, 11
- server-render everything (would be bad UX for those who are on modern browsers)

A baseline needs to be set for the lowest browser version we need to support. Our recommendation is: IE 11, MS Edge (any), Safari 10+, Chrome 60+, FF 60+

**Note:** Cross-browser testing is a potential risk both in terms of cost (we may need to rely on [BrowserStack](https://www.browserstack.com/)) and effort

## Dealing with users on ancient browsers

IE8 is the minimum browser version we might have to support

We'll need to build:
1. APIs (django rest framework)
2. Django server-rendered views (served to IE users only; these would consume the rest APIs)
3. React SPA (served to non IE users; would consume rest APIs)

[2] is additional scope that we hadn't previously anticipated

**The MVP could be: 1 + 2 or 1 + 3 (preferred)**

Another option is to force users to download Chrome v49 - the last version of Chrome to support Windows XP