DEV Community

loading...

My Lambda Labs Experience

codybrewer profile image CodyBrewer ・3 min read

The Assignment - A Pet Grooming Scheduling App

During the Lambda Labs unit, for 8 weeks I worked in the Lambda Labs Pet Express organization. This organization's goal is to make it easier for pet owners to find and schedule pet grooming services. We picked up this project from where the last team left off. They had built out a heavy back-end and a light frontend. They established me as a backend developer during the third week. It worried me I wouldn't be able to work on the frontend and unfortunately that happened as it seemed we split up into 2 backend developers and 6 frontend developers. Our first task in the backend was to make endpoints for appointments so users can create/reschedule/cancel/get appointments and groomers can get/reschedule/cancel/approve appointments as well.

Challenges with appointment scheduling

With building out the appointments endpoints, we ran into a few technical challenges such as handling the date time of the appointment. Initially, the date and time were two columns in the database and while that worked we realized that the frontend would be needing to handle converting the date and time of the appointment to the user’s time zone. Having to deal with time zones can be a headache and easily overlooked. The solution to this problem was to have one column in the appointments table to handle the appointment_date_time. We would store in this column the Unix timestamp of the date time of the appointment, which is the number of milliseconds since January 1, 1970. This would allow our frontend to convert the Unix time into a user legible date time by converting the unix time into a date object.
Example:

```
const unixTime = 1612397014
const date = new Date(unixTime)
// date returns the date time in the current users Time zone: ‘Date Mon Jan 19 1970 09:53:17 GMT-0600 (Mexican Pacific Standard Time)’```
Enter fullscreen mode Exit fullscreen mode

In addition to this we needed to make sure that user’s were not requesting appointments with groomers when the groomer already has an appointment scheduled during the time requested. This stops groomers from getting double booked and having to request the user reschedule their appointment. We were able to do this by creating a middleware called validateAppontmentTime to run on the post /appointments route getting the time of all of the groomers appointments along with the duration and check if the requested time appears during the duration of the scheduled appointments.

const validateAppointmentTime = async (req, res, next) => {
  try {
    const groomerApps = await appointmentsModel.getAll(req.body.groomer_id);
    groomerApps.forEach((appointment) => {
      const durationSeconds = appointment.duration * 60;
      const appEndTime = appointment.appointment_date_time + durationSeconds;
      if (
        req.body.appointment_date_time >= appointment.appointment_date_time &&
        req.body.appointment_date_time <= appEndTime
      )
        res.status(409).json({
          message: `The groomer already has an appointment schedule at the requested time`,
        });
    });
    next();
  } catch (e) {
    console.error(e.stack);
    res.status(500).json({ error: 'Error validating appointment time' });
  }
};
Enter fullscreen mode Exit fullscreen mode

What we left behind

In the end we shipped the appointments scheduling feature to work and were even able to gain experience with the swagger/openapi standards experience by writing the documentation for the api, found here. This was an unexpected enjoyment for me as I was able to see how a great way to communicate how an api is expected to work. I don't foresee myself writing an api without using swagger to create the documentation.

For the future of the application regarding the backend I see a need to refactor the database schema regarding how locations & services are handled as there are currently 4 tables that affect locations and services simplicity especially as a future feature of the frontend is going to be scheduling services at locations by going to a map point inside of an embed map like mapbox on the frontend.

Regarding what I learned from working on this app about myself and working with teams is that I need to push myself out of my comfort zone more regarding communication, especially as I tend to by shy and try to not rock any boats. This flawed me in working with this application as our frontend had not tested working with the backend until very late. In the future working with teams I am going to be more vocal about working cross functionally so we do not end up finding issues while there are only a few seconds until midnight.

The experience I gained working during labs is going to help me with my professional development career by thinking about putting the communication and team as large of a priority as shipping a new feature.

Discussion (0)

pic
Editor guide