My developer journal: Sprint II— Working with other Developers
Building a web chat app
This is the second entry to my Developer Journal for Lambda Labs project, where we build a service chat app for hotels and its guests.
After publishing my Developer Journal, submitting Sprint Review Form and having one-on-one with my PM, together with my team we’ve prepared a mind map of how our front end component architecture will look like.
This helps us visualize all the reusable components, functionalities and routes we’ll need to build out in React.
Express logger
Next I worked on integrating winston and express-winston into our server as per Express.js recommendation to log app activity and any errors that might occur.
I’ve setup the Transports to be stored locally for the moment and will setup data persistence in a remote location — database — for future release. Both logger and errorLogger middlewares were connected to the Express pipeline.
Week preparation & planning
I took the milestones we had to hit during next week and split them down into smaller tickets. We have divided these in our team and worked on them throughout the week.
Authentication
Monday started with morning Stand-up meeting, where we discussed who will work on which ticket. We’ve also reviewed database schema prepared by Connor and suggested small changes to it. I was working on implementing authentication for users and user signup/login endpoints. The requirement for this Sprint regarding authentication was to use OAuth, however OAuth is used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. But we do not see any reason, why should we allow Hotel Staff to log in to our app with third party apps (Google/Facebook/…). They will login with credentials created for them by Super Admin (owner of the app/hotel). Also guests will not need to login with third party apps either, as their login will be handled by creating a one time unique code which they’ll use during they stay in the hotel. I researched, if we could use one of passport.js strategies, however with no good result. Based on my research I came to the conclusion, that using the JWT standard will be the best solution for our use case.
To create the token, I build a simple utility function, that will create the token with payload we will need in the future. The secret to sign this token will be stored in an environment variable. To authenticate users, I created a middleware which will check for Authorization header in the requests headers and verifies the correctness of the token. If these checks pass, the payload is decoded and added to the body of the request for further use in Express app. I added error handlers for when the header is missing or if the token was tempered with.
For user signup and login endpoints, I created mock tests with Jest and supertest . The signup endpoint first checks if a user with provided username already exists in our DB. If it passes, then it hashes users password and stores the user data (with hashed password) in the database. The response to the request is an object with authentication token and new user information (without the password).
Login endpoint also checks for username in the DB and then compares the hashes of provided password with password stored in our DB. If these checks pass, JWT is created and send back to the user. Both endpoints have error handlers for invalid credentials, server errors or duplicate users.
Next I reviewed another 2 pull requests from my team mates, where I suggested changes to the code base related to security checks and password hashing.
Validation
When I started to work on data validation for our endpoints, I thought it will take me an hour or two at max, turned out I was very… very wrong.
As I added validation to more endpoints, some tests started to fail and I could not figured out why. Everything seemed to be alright. After reviewing the code couple more times I was left with this one test failing. It was supposed to return 404status code, but it returned 400 every time.
I looked online on how to setup VSCode’s debugger for Jest testing. After some research and couple of unsuccessful tries, I've setup new configuration in my launch.json so it would work with Jest.
As I was debugging it, I found out I never hit my endpoint logic, where it checks if the user exists in our database or not. But what could be the reason? I reviewed the ID validator one more time and that’s when it hit me. We’ve had a length constrain on the validator, that would check for the number of characters in the ID. I knew this because of the code review I did with my team mate Mark the day before, where I asked him about this RegExp pattern which I didn’t know at the time. So I looked closely on the ID length, that we were passing to the PUT request. And viola… it was couple of characters shorter! That’s why it never hit our logic inside the PUT request and immediately fired a 400 status code. The learning point from all of this - detailed code reviews are very important. I finished the day finally submitting my PR.
Guest login codes
Next I started to work on a new feature — Ability to generate unique guest login codes on check in and deactivate on check out. The guest login code will be generated based on guests name, room number and a secret string of characters. These will be “randomly ”mixed up to generate guests code to login into the chat with receptionist.
I’ve updated our endpoints for Guests to include a function to generate new login code for guests. This will then be hashed and stored in the DB with other guest information.
While testing this feature, I’ve noticed a bug with our email validation. Email is a required field in our DB for all hotel staff, but is not required (or null ) for guests, if the opt out from providing their email. The bug consisted of two conflicting properties in our validation function — RegExp that would check for valid email and a statement that would allow null in the email field. But if null was passed as email, it would fail the RegExp condition. So I changed the validation function to work with both conditions.
This week was more of a fix and update stuff for me, while my team mates worked on chat feature with Socket.IO or researched the integration of Stripe API, build documentation and started with React/Redux setup on Front End. I’ll be diving into new features in next couple of days. Next week we should be finishing up with features and start moving towards the Front End. 👋
