# ✅ Prisma Integration Tests
~~1. Set up vitest for running integration tests~~
~~2. Set up docker compose to spin up an instance of MongoDB~~
~~3. Have at least one example of Prisma integration test running in this new setup~~
# Isolated Preview Environments
1. Configure Preview Environments to have their own instance of MongoDB so tests can run in isolation
- Where should the Mongo instances live? Atlas? What about pricing?
2. Seed Mongo with testing data. One idea is to use [replibyte](https://www.replibyte.com/docs/introduction) to extract obfuscated data from prod. The following config was used on some initial tests:
```
source:
connection_uri: mongodb+srv://xgrowthuser:CUBaBodIgAdaFOqr@cluster0.7crht.azure.mongodb.net/xGrowth
transformers:
- database: xGrowth
table: users
columns:
- name: UserName
transformer_name: email
- name: email
transformer_name: email
- name: NormalizedEmail
transformer_name: email
- database: xGrowth
table: invitenotifications
columns:
- name: emails.$[]
transformer_name: email
destination:
connection_uri: mongodb://admin:admin@127.0.0.1:27017/xGrowth
datastore:
local_disk:
dir: ./.data/replibyte
```
Some other references:
- https://docs.snaplet.dev/tutorials/prisma-seed/
- https://www.prisma.io/docs/guides/migrate/seed-database
# Prisma Referential Actions
Currently, our Prisma schema does not configure [referential actions](https://www.prisma.io/docs/concepts/components/prisma-schema/relations/referential-actions), which means we may end up with data integrity issues if a record needed by another record is deleted.
Similar to FK in a relational DB, referential actions may help up keep a healthier dataset.
# Workspace Structure
In order to better implement NextJS community standards, the proposal is to organize our workspaces as follows:
```
growinco/
- apps/
- gasp/
- petit/
- platform/
- packages/
- date-utils/
- ui/
- service/
```
Keeping deployable applications within the `apps` scope while sharable packages would live under `packages`.
# Improved TypeScript Setup
It seems that out TS setup is throwing VSCode off when it comes to autocomplete suggestions. The idea is to set up TS per workspace having a common tsconfig file at the root to share configuration.
This may allow us to better target include/exclude statements to the needs of each workspace.
We can use [this vercel turborepo example](https://github.com/vercel/turbo/tree/main/examples/basic) as reference.
# CI/CD
Investigate/Implement [Github Actions integrated with vercel's workflow](https://vercel.com/guides/how-can-i-use-github-actions-with-vercel) so that:
1. Upon pushing to a PR branch;
2. A preview env is initialized with its own MongoDB instance;
3. Unit tests are run;
4. Integration and e2e (Cypress) test are run against that env;
5. Report results directly to the PR (Failed tests, test coverage, linting, etc...);
# DB Data Normalization
There are some models with array of id fields which make it hard to map relationships back in the Prisma schema, making simple queries a bit too complex for their own good.
We should try to tackle these instances one at a time, coverting them to actual relationships backed by Prisma. [Here's one example](https://github.com/orgs/GrowinCo/projects/2/views/15?pane=issue&itemId=27535880).