public-offering
/
cal.pub0.org
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #48 from calcom/fix/update-readme

pull/9078/head
Agusti Fernandez 2022-04-21 01:47:05 +02:00 committed by GitHub
parent f9b7cebe37 b8d452bda0
commit b653276836
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 41 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
README.md
View File

@ -34,46 +34,4 @@ We aim to provide a fully tested API for our peace of mind, this is accomplished
Since this will only support an API, we redirect the requests to root to the /api folder.
We also added a redirect for future-proofing API versioning when we might need it, without having to resort to dirty hacks like a v1/v2 folders with lots of duplicated code, instead we redirect /api/v*/:rest to /api/:rest?version=*
The priority is the booking-related API routes so people can build their own booking flow, then event type management routes, then availability management routes etc
How to add a new model or endpoint
Basically there's three places of the codebase you need to think about for each feature.
/pages/api/
- This is the most important one, and where your endpoint will live. You will leverage nextjs dynamic routes and expose one file for each endpoint you want to support ideally.
## How the codebase is organized.
## The example resource -model- and it's endpoints
### `pages/api/endpoint/`
GET pages/api/endpoint/index.ts - Read All of your resource
POST pages/api/endpoint/new.ts - Create new resource
### `pages/api/endpoint/[id]/`
GET pages/api/endpoint/[id]/index.ts - Read All of your resource
PATCH pages/api/endpoint/[id]/edit.ts - Create new resource
DELETE pages/api/endpoint/[id]/delete.ts - Create new resource
## `/tests/`
This is where all your endpoint's tests live, we mock prisma calls. We aim for at least 50% global coverage. Test each of your endpoints.
### `/tests/endpoint/`
/tests/endpoint/resource.index.test.ts - Test for your pages/api/endpoint/index.ts file
tests/endpoint/resource.new.test.ts - Create new resource
### `/tests/endpoint/[id]/`
`/tests/endpoint/[id]/resource.index.test.ts` - Read All of your resource
`/tests/endpoint/[id]/resource.edit.test.ts` - Create new resource
`/tests/endpoint/[id]/resource.delete.test.ts` - Create new resource
## `/lib/validations/yourEndpoint.ts`
- This is where our model validations, live, we try to make a 1:1 for db models, and also extract out any re-usable code into the /lib/validations/shared/ sub-folder.

41
templates/README.md Normal file
View File

@ -0,0 +1,41 @@
# How to add a new model or endpoint
Basically there's three places of the codebase you need to think about for each feature.
/pages/api/
- This is the most important one, and where your endpoint will live. You will leverage nextjs dynamic routes and expose one file for each endpoint you want to support ideally.
## How the codebase is organized.
## The example resource -model- and it's endpoints
### `pages/api/endpoint/`
GET pages/api/endpoint/index.ts - Read All of your resource
POST pages/api/endpoint/new.ts - Create new resource
### `pages/api/endpoint/[id]/`
GET pages/api/endpoint/[id]/index.ts - Read All of your resource
PATCH pages/api/endpoint/[id]/edit.ts - Create new resource
DELETE pages/api/endpoint/[id]/delete.ts - Create new resource
## `/tests/`
This is where all your endpoint's tests live, we mock prisma calls. We aim for at least 50% global coverage. Test each of your endpoints.
### `/tests/endpoint/`
/tests/endpoint/resource.index.test.ts - Test for your pages/api/endpoint/index.ts file
tests/endpoint/resource.new.test.ts - Create new resource
### `/tests/endpoint/[id]/`
`/tests/endpoint/[id]/resource.index.test.ts` - Read All of your resource
`/tests/endpoint/[id]/resource.edit.test.ts` - Create new resource
`/tests/endpoint/[id]/resource.delete.test.ts` - Create new resource
## `/lib/validations/yourEndpoint.ts`
- This is where our model validations, live, we try to make a 1:1 for db models, and also extract out any re-usable code into the /lib/validations/shared/ sub-folder.