Spiking on the API using Next.js #17

QuincyLarson · 2019-10-15T06:03:12Z

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 · 2019-10-15T06:20:07Z

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 · 2019-10-15T06:21:06Z

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 · 2019-10-15T09:19:50Z

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 · 2019-10-15T09:21:24Z

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 · 2019-10-15T09:40:48Z

Yeah we were just talking about that in the discord

nezdemkovski · 2019-10-15T10:17:04Z

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

francocorreasosa · 2019-10-15T12:40:58Z

This is definitely a good option to go with.

nik-john · 2019-10-15T18:57:15Z

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 · 2019-10-15T19:03:48Z

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 · 2019-10-15T19:16:09Z

@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 · 2019-10-15T19:38:01Z

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 · 2019-10-15T19:41:09Z

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 · 2019-10-15T19:42:37Z

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 · 2019-10-15T19:51:02Z

@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 · 2019-10-15T20:04:17Z

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

bernhard-hofmann · 2019-10-15T20:23:00Z

I'll add my thoughts for what they're worth.

The end points should be designed to fit the needs of the application. The underlying tables shouldn't be the basis of the API.

nik-john · 2019-10-15T20:26:19Z

@bernhard-hofmann Agreed. Like I mentioned

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.

Could you provide your thoughts on what the routes should be?

bernhard-hofmann · 2019-10-15T20:31:21Z

The problem with starting with this long list is that we have to remove what's not needed. It's easy to miss something and leave endpoints we don't need. (YAGNI)

Let's review what the app needs and create (or keep) only the endpoints needed to satisfy each requirement.

typeofweb · 2019-10-15T20:37:28Z

There are a few scenarios written. We could start from them, analyze the use cases and then design the API routes.

nik-john · 2019-10-15T21:17:27Z

Here's a first stab at the APIs as per the use cases in README.md

As a future participant

I can use a search box on the landing page to input a city, state, or country name and it will autocomplete. I can click one of those locations.

GET api/v1/locations?city=sfo&country=usa

When I click one of those locations, I can see the "show view" for that event's group, with details about the upcoming event, along with a button to RSVP.

GET api/v1/locations/:locationId

I can click the "RSVP" button. When I do, I will be prompted to sign in. Then I will receive an email with a ticket and add me to the public list of event attendees.

POST api/v1/groups/:groupId/events/:eventId/rsvp
{
	"userId": "foobar",
	"guests": 3
}

I will receive a second email the day before the event to remind me.
This will need to be a job I guess
After the event, I will automatically get emails notifying me of subsequent events.
This will need to be a job I guess

As an organizer

I can create a group.

POST api/v1/groups
{
	"name": "foobar",
	"description": "lorem ipsum",
        "locationId": "baz",
        "creatorId": "foofoo"
}

I can edit details about the group, including a Slack/Discord/Facebook/WeChat/WhatsApp link participants can join to discuss and coordinate events.

{
	"name": "new name",
}

I can create events, and set their location and capacity.

@QuincyLarson Looks like the Event table will need 'capacity' to be added

{
	"name": "foobar",
	"groupId": "bar",
        "venueId": "zzz",
        "canceled": false
}

PATCH api/v1/groups/:groupId/events/:eventId
{
	"venueId": "newVenueId",
}

PATCH api/v1/venues/:venueId
{
	"capacity": 5000
}

I can cancel events.

DELETE api/v1/groups/:groupId/events/:eventId

I can email the entire list of participants.

{
	"subject": "Foo bar",
	"body": "Foo bar baz"    
}

I can ban a participant whom I believe is toxic or who has previously broken my organization's code of conduct.

PATCH api/v1/users/:userId/ban

I can add a venue sponsor to the event with a link to their website as a way of thanking them for hosting."

{
	"name": "foobar",
        "website": "www.website.com",
        "type": "VENUE
}

I can add a food sponsor to the event with a link to their website as a way of thanking them for food.

{
	"name": "foobar",
        "website": "www.website.com",
        "type": "FOOD"
}

PS: I'm in the process of creating an open API spec so we can have official docs

Zeko369 · 2019-10-15T21:22:39Z

"I can email the entire list of participants."
POST api/v1/events/:eventId/email

Also I would namespace all event routes with group
api/v1/group/:groupId/event...

nik-john · 2019-10-15T21:59:27Z

@Zeko369 Agreed with both

nik-john · 2019-10-16T00:09:45Z

I have created a PR with the open API specification for the mentioned end points here: https://github.com/freeCodeCamp/chapter/pull/46/files Please feel free to add to the PR/comment and critique (Additions are preferred to comments as most of us are working on this on top of regular full time jobs 😉 )

cc: @QuincyLarson @Zeko369 @mmiszy

jp-sauve · 2019-10-16T02:41:17Z

If MVP is for a single server, hosted by a group, not all of those endpoints (user stories?) seem necessary. If I'm hosting for my local FCC chapter, who is going to come to my group's site and search for a city when my group is geographic by nature? Emails will have to be carefully considered too, as self-hosting email that doesn't get immediately marked as spam takes more than a server being willing to send out.
I'm all for user stories, but I don't know why they would be linked directly to api endpoints either.

valishah · 2019-10-16T14:43:50Z

@nik-john , I agree with @Zeko369 comment of using nested paths. We could use something like

GET/PUT/PATCH/DELETE  api/v1/event/:eventId/sponsors
GET/PUT/PATCH/DELETE api/v1/event/:eventId/sponsors/:sponsorId

allella · 2019-10-16T17:18:10Z

@kognise also has a proposed "terminology" update to the readme to call a "chapter" effectively what a "group" is in the schema. Group is pretty vague and it would be nice to have some parity between the core item in the schema and what we're referring to in the business logic terminology.

So, can we change "group(s)" to "chapter(s)"?

nik-john · 2019-10-16T17:43:29Z

@allella For sure. I'll update the swagger doc

nik-john · 2019-10-16T17:47:31Z

@valishah Agreed - I'll update the PR with the changes. Please keep an eye on #46

jimthedev · 2019-10-17T20:49:47Z

Not sure how any of what you are doing relates to Next.js. We are playing with a Next.js based ui here. If there's a place you'd rather have this let me know. We're not really focusing on the styling. Keeping it raw and just hoping to get the right things on a page for now.

Dhara159 · 2019-10-17T21:07:43Z

As API endpoints are ready and we are almost clear about the database schema, should we start the backend development? If that is the case, I would like to contribute from the backend side also! If there is anyone up for team up, please ping me or CC me and let's start working on it!

QuincyLarson · 2019-10-17T22:02:44Z

If MVP is for a single server, hosted by a group, not all of those endpoints (user stories?) seem necessary. If I'm hosting for my local FCC chapter, who is going to come to my group's site and search for a city when my group is geographic by nature? Emails will have to be carefully considered too, as self-hosting email that doesn't get immediately marked as spam takes more than a server being willing to send out.
I'm all for user stories, but I don't know why they would be linked directly to api endpoints either.

Just to be clear, freeCodeCamp will host a single Chapter instance that all of the official freeCodeCamp chapters can be on. This way, a whole lot more people will discover your chapter. This is why we will want search functionality.

I just published this last night that goes a bit more into detail on this: #47 (comment)

QuincyLarson · 2019-10-28T05:12:16Z

We have all decided to use Next.js, and this issue hasn't been updated for a while, so I am closing this issue.

nik-john · 2019-11-16T07:35:34Z

@all-contributors please add @QuincyLarson for code doc ideas

allcontributors · 2019-11-16T07:35:45Z

@nik-john

I've put up a pull request to add @QuincyLarson! 🎉

kognise mentioned this issue Oct 16, 2019

Our Roadmap #47

Closed

7 tasks

MirzaChilman mentioned this issue Oct 16, 2019

Frontend libs #34

Closed

nik-john mentioned this issue Oct 16, 2019

Nik john/add venue capacity #62

Closed

nik-john mentioned this issue Oct 16, 2019

Add swagger json #46

Merged

allella mentioned this issue Oct 16, 2019

Schema image / ER Diagram is out of date #54

Closed

This was referenced Oct 16, 2019

Add capacity to events #63

Merged

Add swagger json nik-john/chapter#3

Merged

This was referenced Oct 17, 2019

What are some of your ideas on building an alternative to Meetup.com? #1

Closed

Add category to Chapters Table schema #71

Closed

allella mentioned this issue Oct 21, 2019

Consider using uncle bob's clean architecture for Api #116

Closed

QuincyLarson closed this as completed Oct 28, 2019

allcontributors bot mentioned this issue Nov 16, 2019

docs: add quincylarson as a contributor #234

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Spiking on the API using Next.js #17

Spiking on the API using Next.js #17

QuincyLarson commented Oct 15, 2019

JKHarley commented Oct 15, 2019

psyked commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

MirzaChilman commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

nezdemkovski commented Oct 15, 2019

francocorreasosa commented Oct 15, 2019

nik-john commented Oct 15, 2019

nik-john commented Oct 15, 2019

nik-john commented Oct 15, 2019 •

edited

Loading

typeofweb commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

nik-john commented Oct 15, 2019 •

edited

Loading

kognise commented Oct 15, 2019

bernhard-hofmann commented Oct 15, 2019

nik-john commented Oct 15, 2019

bernhard-hofmann commented Oct 15, 2019

typeofweb commented Oct 15, 2019 •

edited

Loading

nik-john commented Oct 15, 2019 •

edited

Loading

Zeko369 commented Oct 15, 2019

nik-john commented Oct 15, 2019

nik-john commented Oct 16, 2019 •

edited

Loading

jp-sauve commented Oct 16, 2019

valishah commented Oct 16, 2019 •

edited

Loading

allella commented Oct 16, 2019 •

edited

Loading

nik-john commented Oct 16, 2019

nik-john commented Oct 16, 2019

jimthedev commented Oct 17, 2019

Dhara159 commented Oct 17, 2019

QuincyLarson commented Oct 17, 2019

QuincyLarson commented Oct 28, 2019

nik-john commented Nov 16, 2019

allcontributors bot commented Nov 16, 2019

Spiking on the API using Next.js #17

Spiking on the API using Next.js #17

Comments

QuincyLarson commented Oct 15, 2019

JKHarley commented Oct 15, 2019

psyked commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

MirzaChilman commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

nezdemkovski commented Oct 15, 2019

francocorreasosa commented Oct 15, 2019

nik-john commented Oct 15, 2019

nik-john commented Oct 15, 2019

nik-john commented Oct 15, 2019 • edited Loading

typeofweb commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

Zeko369 commented Oct 15, 2019

nik-john commented Oct 15, 2019 • edited Loading

kognise commented Oct 15, 2019

bernhard-hofmann commented Oct 15, 2019

nik-john commented Oct 15, 2019

bernhard-hofmann commented Oct 15, 2019

typeofweb commented Oct 15, 2019 • edited Loading

nik-john commented Oct 15, 2019 • edited Loading

Zeko369 commented Oct 15, 2019

nik-john commented Oct 15, 2019

nik-john commented Oct 16, 2019 • edited Loading

jp-sauve commented Oct 16, 2019

valishah commented Oct 16, 2019 • edited Loading

allella commented Oct 16, 2019 • edited Loading

nik-john commented Oct 16, 2019

nik-john commented Oct 16, 2019

jimthedev commented Oct 17, 2019

Dhara159 commented Oct 17, 2019

QuincyLarson commented Oct 17, 2019

QuincyLarson commented Oct 28, 2019

nik-john commented Nov 16, 2019

allcontributors bot commented Nov 16, 2019

nik-john commented Oct 15, 2019 •

edited

Loading

nik-john commented Oct 15, 2019 •

edited

Loading

typeofweb commented Oct 15, 2019 •

edited

Loading

nik-john commented Oct 15, 2019 •

edited

Loading

nik-john commented Oct 16, 2019 •

edited

Loading

valishah commented Oct 16, 2019 •

edited

Loading

allella commented Oct 16, 2019 •

edited

Loading