[Tommy Collison] RDBMS-API-Full

[tommycollison]

@johnoro ✏️ 📅 🦁

[tommycollison]

next steps:

• flesh out other endpoints
• make sure cohorts and students are successfully talking to one another

[johnoro]

You could potentially reduce the repetition of having nearly identical post callbacks for students and cohorts here. For example, let's make one function for both:

const post = table => ({ body }, res) => {
  db(table).insert(body)
    .then(ids => res.status(201).json(ids))
    .catch(() => {
      res.status(500).json({
        err: `Failed to insert into ${table}`
      });
    });
};

and then, the usage, in an iterative way so as to avoid repetition:

[ 'cohorts', 'students' ].forEach(table => {
  server.post(`api/${table}`, post(table));
});

[johnoro]

Looking good so far!

[johnoro]

You can optionally pass in an object to where:

db('cohorts').where({ id: id }).update(cohort)

or, using the shorthand syntax for a key that has the same name as a variable being used for the value:

db('cohorts').where({ id }).update(cohort)

[johnoro]

This delete looks very similar to your put. I'm wondering if we could make this do the same thing with a helper function for both. I think with just these two alone, it wouldn't quite be worth it, but when considering the other endpoints that we have (and possible future ones), it'd probably be beneficial to build out something to make them all more modular.

[johnoro]

Another option for routing is using the route method and then chaining the specific CRUD actions on it, like this:

server.route('/api/cohorts/:id')
  .put((req, res) => { /* PUT logic here */ })
  .delete((req, res) => { /* DELETE logic here */ });

[johnoro]

A lot of people will then break out the callbacks into helper functions (typically in another file):

const putCohorts = (req, res) => { /* PUT logic for cohorts here */ };
const deleteCohorts = (req, res) => { /* DELETE logic for cohorts here */ };

server.route('/api/cohorts/:id')
  .put(putCohorts)
  .delete(deleteCohorts);

This lends well for the organizational side of making your APIs modular.

[tommycollison]

MVP

• [POST] /api/cohorts This route should save a new cohort to the database.
• [GET] /api/cohorts This route will return an array of all cohorts.
• [GET] /api/cohorts/:id This route will return the cohort with the matching id.
• [GET] /api/cohorts/:id/students returns all students for the cohort with the specified id.
• [PUT] /api/cohorts/:id This route will update the cohort with the matching id using information sent in the body of the request.
• [DELETE] /api/cohorts/:id This route should delete the specified cohort.

Stretch

• [POST] /students This route should save a new student to the database.
• [GET] /students This route will return an array of all students.
• [GET] /students/:id This route will return the student with the matching id.
• [PUT] /students/:id This route will update the student with the matching id using information sent in the body of the request.
• [DELETE] /students/:id This route should delete the specified student.

[johnoro]

Since you're already a bit ahead, here's one more thing that you could do as stretch:

• [GET] /api/cohorts/:id This route will return the cohort with the matching id, AND will contain its corresponding students in this format:

{
  id: 4,
  name: 'WebPT2',
  students: [
    {
      id: 12,
      name: 'Tommy'
    },
    {
      id: 13,
      name: 'John' // not exactly a student
    }
  ]
}

[tommycollison]

I was going to refactor based on your feedback above, but I'm all ears!