Event Planner API

The problem

Events, venues, users and RSVPs look like four independent collections until you try to write them. An event without a venue is incomplete, an RSVP pointing at a deleted event is corrupt, and a guest count attached to nobody is meaningless. So the real work is not the CRUD, it is the relationships between records and the validation that keeps them coherent, plus letting a third party sign in without the API ever storing a password.

Approach

• Sixteen endpoints cover events, venues, users and RSVPs, with the related records referenced by identifier so an RSVP resolves to a real event and an event to a real venue.
• Authentication is delegated to Google via OAuth2, so the API never stores or verifies passwords itself.
• Every write path validates its payload before touching the database, and errors return a consistent shape rather than leaking raw exceptions.
• RSVPs carry their own state (going, interested, not going) plus guest count and an optional note, so attendance is a record with meaning rather than a boolean flag.
• A Jest test suite covers the routes, and the OpenAPI specification is generated from the route definitions instead of written separately.
• The generated reference is published as a static page, so the documented contract stays readable whether or not a server is running behind it.

What it proves

• Sixteen documented endpoints across four related resources.
• Google OAuth2 sign-in, with no password storage in the API.
• OpenAPI specification generated from the routes, published as an always-available static reference.
• Covered by a Jest test suite.