My developer journal: Sprint I — Project Planning
Building a web chat app
For the next five weeks I’ll be working in a remote team of 5 to build a web chat app as a part of Lambda Schools Labs curriculum. Lambda Labs is build to look and feel like a job at a real world dev shop. As a part of the experience I have to keep a Developer Journal to document what I’ve done in the project.
To setup the project, I’ve setup a GitHub project Kan-ban board (think Trello on GitHub). Prepared labels to categorize tickets/issues in every repo in our GitHub organization. Created tickets (GitHub Issues) for everyone to update their part of the documentation. I’ve also setup Milestones for each repo (Back End, Front End, Documentation) based on evaluation rubric we have to complete each week. Together with the team we created first draft of Technical Design Document (TDD).
With my teammate Mark, we proposed a new angle on the app to target specific market/service, so we can find some edge against current enterprise solutions which cover the customer support chat needs very well. The idea was to target Hotels with service chat app.
Together with the team, we decided to move on with our proposal to create a Hotel Service Chat app for guest. We had to rework some parts of TDD concerned about the apps: Idea, User Journey, Solutions, Why build this?, Key Features, Competitive Landscape and Monetization.
I’ve researched some public APIs for one of our features — Guests can scan a QR code that takes them to the chat application where they can talk with hotel staff. — this will require third party API to generate QR code, that when read will redirect hotel guest to our apps chat URL. There is an feature option to create custom QR codes for every guest, which when they scan, will 🎆 auto-magically 🎆 logs them in. However, from my quick research, most public APIs to generate QR codes do it from a [GET] request, where the data to be encoded in the QR code is sent via URLs query string. This is not wanted behavior, as we want the guests login to be private information. We will have to investigate further options if we want to move forward with this feature.
After 2 days of planning and preparing TDD, it’s finally time to write some code 💻 🎉. I was researching how to create Users models in MongoDB. I’ve setup new cluster, which is a deployed database on a server. To do this I’ve used MongoDB Atlas, which is an automated cloud service by MongoDB to host databases.
Once the cluster was live, I had to figure out how to connect to it from our Node server build by my team mate. To do that I used Mongoose, which is an object data modeling (ODM) library that provides a modeling environment for MongoDB and Node.js.
First thing I did was to create very simple Users schema with username and id and then I compiled the schema to a Users model. A model is a class that's your primary tool for interacting with MongoDB. An instance of a Model is called a Document.
Then I connected to the cluster with mongoose.connect() method, which takes the URI to the cluster as first parameter and options object as second.
We wanted to seed our DB with some fake user data, so I created a simple function to do this. I’ve used Faker.js to generate fake usernames.
Finally I created simple queries to fetch data from the database. For now User.find() which returns an array of users and User.where({ id })which returns a user based on his ID. These queries are used in our [GET] requests for Users and send the data to the front end of our app.
For next week we’re planning to build out most of the API endpoints, Authentication, Data Models, start building React Components, start working with Socket.io to build the chat and make sure everything works together. It’ll be an intense week, but I’m very confident we’ll be able to complete all milestones in time and quality, as we have a really awesome team!😎
