-
Notifications
You must be signed in to change notification settings - Fork 17
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
Implement api schema and docs #250
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- `GET /user/v2-qr/` -> `GET /user/qr/` - `GET /user/following/` properly returns followed events as `{ userId: "123", following: ["event1",...] }` instead of `{ userId: "123", events: ["event1",...] }` - `PUT /user/follow/` with `{ eventId: "event1"}` to `PUT /user/follow/event1/` - `PUT /user/unfollow/` with `{ eventId: "event1"}` to `DELETE /user/unfollow/event1/` - Improve checkin to not use RouterError
Instead of /notification/batch -> /notification/send just do /notification/send since we are moving from serverless Also changes `GET /notifications/`` response type from `[{..notif1}]` to `{ notifications: [{..notif1}] }` to be consistent
Not just objects, as an array can be a return type
Arrays now work
We did it!
Also reverted v2 change: `GET /shop/v2/` -> `GET /shop/` Cleaned up `POST /shop/item/buy/` with `{ itemName: "Jacket" }` to `{ name: "Jacket", ..all additional item properties }`
Changes parameters, query, and body to have empty/unknown default types. This means using them when not defined in spec will result in an error instead of being typed as unknown. As such, this also fixes two missed cases in users and notifications that were caught by this change.
We need to allow both auth with no required roles and no auth so that swagger always sends auth header if it exists, even if not required. Mainly for endpoints like `GET /event/` which change based on roles but are still public.
Useful when JWT not required but nice
This moves events following from the attendee database to the user database, since we already treat it that way anyways. All users should be able to follow events, there's no problem with that.
Mainly doing this for the automatic promise error handling: https://expressjs.com/en/guide/error-handling.html ``` Starting with Express 5, route handlers and middleware that return a Promise will call next(value) automatically when they reject or throw an error ```
The trifecta
HUGE PR! I dug through specification.ts, specification-validator.ts, and model.ts in depth and skimmed through the rest. The code really is a ton cleaner and intuitive which will make future changes easier. Appreciate the work to make everything consistent, especially for the req/res validation and documentation! LGTM :) |
aletya
approved these changes
Oct 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #218
Resolves #219
Resolves #222
This is a massive pr, and massive is an understatement. In essense, every endpoint now uses a special
specification
middleware.This middleware takes in zod schemas and other metadata in order to both validate incoming requests, type the req and res express objects, and generate documentation with openapi + swagger.
Here's an example:
There are several breaking changes from this:
changes:
GET /user/v2-qr/
->GET /user/qr/
GET /shop/v2/
->GET /shop/
GET /user/following/
properly returns followed events as{ userId: "123", following: ["event1",...] }
instead of{ userId: "123", events: ["event1",...] }
PUT /user/follow/
with{ eventId: "event1"}
toPUT /user/follow/event1/
PUT /user/unfollow/
with{ eventId: "event1"}
toDELETE /user/unfollow/event1/
POST /shop/item/buy/ with { itemName: "Jacket" }
to{ name: "Jacket", ..all additional item properties }
GET /admission/rsvp/
no longer returns all rsvps just for staff and only current user for non-staff (why in the first place...) - admin site will need to use newGET /admission/rsvp/staff/
endpoint to get all rsvpsThere's still a lot to clean up, but at least now we're consistent. The biggest move going forward is adding more tests, as it was much harder to do these changes without them.