Spiking on the API using Next.js

[QuincyLarson]

Would anyone be interested in attempting to use Next.js to build a rough prototype of this application? I've read a lot of good things about Next.js, but ultimately we will see whether it's a good fit when someone digs into it and builds out some of the core routes.

[JKHarley]

I would be interested in building a prototype with Next.js. I think it would be a good fit with the SSR, routing and code splitting.

[psyked]

This aligns with my immediate thoughts about the tech stack so I’d be happy to give it a go. Do you have any high level route / visuals planned?

[Zeko369]

What do you guys think about using Next.js embeded API routes for backend? For a simple prototyping app that seems like a good idea.

[MirzaChilman]

What do you guys think about using Next.js embeded API routes for backend? For a simple prototyping app that seems like a good idea.

You guys can refer to this docs https://nextjs.org/docs#api-routes

[Zeko369]

Yeah we were just talking about that in the discord

[nezdemkovski]

Hey, work with next.js from the very first release, glad to help with it. Using new api routes is a great idea!

[francocorreasosa]

This is definitely a good option to go with.

[nik-john]

So I just created an app with sample API routes on Next for a project I'm working on - I can provide a sample repo for anyone who wants to take a look - is there a Discord channel for frontend where I can post the repo deets?

[nik-john]

Is anyone else currently working to create the spike? I can spin it up in a few hours if no one else is - will fork the repo and drop a note here when done

[nik-john]

@QuincyLarson Would this be the API structure we will be looking at more or less?

 GET api/v1/users
 GET api/v1/users/:userId
 POST api/v1/users
 PUT api/v1/users/:userId
 PATCH api/v1/users/:userId
 DELETE api/v1/users/:userId
 
 GET api/v1/locations
 GET api/v1/locations/:locationId
 POST api/v1/locations
 PUT api/v1/locations/:locationId
 PATCH api/v1/locations/:locationId
 DELETE api/v1/locations/:locationId
 
 GET api/v1/groups
 GET api/v1/groups/:groupId
 POST api/v1/groups
 PUT api/v1/groups/:groupId
 PATCH api/v1/groups/:groupId
 DELETE api/v1/groups/:groupId

GET api/v1/user_bans
GET api/v1/user_bans/:user_banId
POST api/v1/user_bans
PUT api/v1/user_bans/:user_banId
PATCH api/v1/user_bans/:user_banId
DELETE api/v1/user_bans/:user_banId

GET api/v1/user_groups
GET api/v1/user_groups/:user_groupId
POST api/v1/user_groups
PUT api/v1/user_groups/:user_groupId
PATCH api/v1/user_groups/:user_groupId
DELETE api/v1/user_groups/:user_groupId

 GET api/v1/venues
 GET api/v1/venues/:venueId
 POST api/v1/venues
 PUT api/v1/venues/:venueId
 PATCH api/v1/venues/:venueIdv
 DELETE api/v1/venues/:venueId

 GET api/v1/events
 GET api/v1/events/:eventId
 POST api/v1/events
 PUT api/v1/events/:eventId
 PATCH api/v1/events/:eventId
 DELETE api/v1/events/:eventId
 
 GET api/v1/sponsors
 GET api/v1/sponsors/:sponsorId
 POST api/v1/sponsors
 PUT api/v1/sponsors/:sponsorId
 PATCH api/v1/sponsors/:sponsorId
 DELETE api/v1/sponsors/:sponsorId

GET api/v1/rsvps
GET api/v1/rsvps/:rsvpId
POST api/v1/rsvps
PUT api/v1/rsvps/:rsvpId
PATCH api/v1/rsvps/:rsvpId
DELETE api/v1/rsvps/:rsvpId

GET api/v1/event_sponsors
GET api/v1/event_sponsors/:event_sponsorId
POST api/v1/event_sponsors
PUT api/v1/event_sponsors/:event_sponsorId
PATCH api/v1/event_sponsors/:event_sponsorId
DELETE api/v1/event_sponsors/:event_sponsorId

[typeofweb]

Looks good to me.
Just one question: In which scenario would we use user_groups endpoint?

About Next.js in general: I've been using it for over a year now with TypeScript and Redux and it seems like the best choice for this kind of application.

[Zeko369]

Why did you just create CRUD rest endpoints for everyying?
user_groups and event_sponsors are many to many relations (so just dummy tables), we don't need to manually create those

[Zeko369]

Also IMO we should use something similar to how rails handles nested routes and not to have a lot of top level routes.
For example nest RSVPS into events api/v1/events/:eventID/rsvps

[nik-john]

@Zeko369 I just took the existing tables and created CRUD end points for everything so that we would have a first draft to start working off of. I am hoping to make this a working document so we can keep editing this.

We can rip out/add as many end points as we want, as per group consensus. please do provide a consolidated list of edits you want and I'll make the changes.

@mmiszy (I'm somehow not able to tag you) -

just one question: In which scenario would we use user_groups endpoint?

We wouldn't. I'll remove it

PS: I'm open to suggestions regarding any other approaches you guys might have to come to a consensus about the API structure

[kognise]

Routes look awesome! Although we might want to switch around the auth-related ones, see #40