Comments (34)
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.
from chapter.
Hey, work with next.js from the very first release, glad to help with it. Using new api routes is a great idea!
from chapter.
@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
from chapter.
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
from chapter.
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
from chapter.
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?
from chapter.
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.
from chapter.
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?
from chapter.
There are a few scenarios written. We could start from them, analyze the use cases and then design the API routes.
from chapter.
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
from chapter.
@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
from chapter.
@valishah Agreed - I'll update the PR with the changes. Please keep an eye on #46
from chapter.
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
from chapter.
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.
from chapter.
"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...
from chapter.
@Zeko369 Agreed with both
from chapter.
@allella For sure. I'll update the swagger doc
from chapter.
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.
from chapter.
Yeah we were just talking about that in the discord
from chapter.
This is definitely a good option to go with.
from chapter.
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
from chapter.
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.
from chapter.
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
from chapter.
@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
from chapter.
Routes look awesome! Although we might want to switch around the auth-related ones, see #40
from chapter.
@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?
from chapter.
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.
from chapter.
@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)"?
from chapter.
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.
from chapter.
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!
from chapter.
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)
from chapter.
We have all decided to use Next.js, and this issue hasn't been updated for a while, so I am closing this issue.
from chapter.
@all-contributors please add @QuincyLarson for code doc ideas
from chapter.
I've put up a pull request to add @QuincyLarson! š
from chapter.
Related Issues (20)
- Putting chapter.name on event cards is not necessary on the chapter's page HOT 1
- When I close login window, login button hangs
- Modifying the capacity of an event does not affect existing attendees HOT 5
- Banned admin still sees list of admined chapters in dashboard
- Redirect to venue creation after chapter creation HOT 6
- Google Calendar rate limits HOT 11
- Calendar API error handling HOT 1
- Remove GraphQL Playground broken link HOT 1
- Waitlist when event is full
- Add capacity indication on event page HOT 5
- Can't zoom when the layout isn't desktop HOT 2
- Add warning when canceling the events about the waitlist HOT 6
- Self-hosted privacy policy, terms of service and code of conduct HOT 1
- Site description should be configurable HOT 3
- Deployment for self-hosting HOT 17
- Past events displayed in chapter card after chapter page visit
- Event url HOT 2
- The unsubscribe page state HOT 2
- Chapter page doesn't update after login
- Space between event image and header HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chapter.