# ✅ 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).