How I Built a Command-Line Chat Application: Project Reflections

• Challenges
• Lessons Learned
• Contributions and Future Improvements
• Project References
  • Demo Video
  • NPM Registry Link
  • GitHub Link
• Conclusion

In this article, we will delve into the challenges I encountered while developing the command-line chat application, along with the lessons I learned throughout the process. From the initial stages of structuring the application to tackling authentication issues and creating a user-friendly chat interface, I faced numerous obstacles that tested my problem-solving skills and programming knowledge.

Challenges

I faced several challenges from the idea stage to the deployment of the app. Below I list the major challenges I faced building the app:

• App structure: I started building the app with no structure in mind, as I wanted to build fast and organize it later. Eventually, I struggled to organize the app for modularity. But the experience of structuring other backend projects and some little research on the MVC design pattern came in handy. I still think the app isn't well structured, though.

• Authentication: This was one of the hardest features I had to implement. With vague documentation and few resources to explore the socket.io library authentication, I had to spend several hours making the authentication feature work as expected. I initially wanted to store the token on the user's machine but found it to be buggy. So I changed my mind and used HTTP requests to store and retrieve the token from the server.

• The chat interface's home menu feature: I wanted the user to be able to go back to the home menu from the chat interface. I thought of using the inquirer.js prompts that were being used throughout the application. That was impossible because the readline interface continues to be displayed until it is closed. So I figured out that I could respond to the user's input to go back to the home menu. After that, re-rendering the home menu was also difficult. However, its implementation made the chat message interface code messy, and it also disobeyed the DRY principle.

• Railway Redis: I've used Redis in development before but never in production. This project was my first time setting up Redis in production. Since I was deploying on Railway, it was supposed to be easier. But it took time for me to understand how to set up a Redis database, as their documentation wasn't really clear.

• Publishing to NPM : Publishing my first NPM package was challenging. With little time before the project submission deadline, I learned how to publish on NPM and named the app terminal-chat-app. However, after installing the app from the NPM registry for manual testing, I realized I forgot to add the node shebang line to the app's node script. After correcting the issue, I encountered a version error while attempting to republish. Not knowing what to do, I deleted the package and got another error that I had to wait 24 hours to publish again. To meet the hackathon deadline, I temporarily changed the package name to tarminal-chat-app. However, I couldn't change the package name again because it now has more than 130 weekly downloads on NPM.

Lessons Learned

• It's usually unclear at the beginning: I barely knew command-line and web socket programming before the project, and I was still able to make something out of those unfamiliar tools.

• It takes time to build great stuff: I planned to finish the app in a few days, but it took me 2 weeks of debugging, problem-solving, and building to finish the app. Although, if I had known all or most of the technologies used, I would have finished earlier. But I realized that it's not the normal CRUD API that I'm used to building, so it took more time than expected.

• The definition of a minimum viable product (MVP): A lot of features came to mind while building the app, but I had to settle for the easiest feature to implement and think of building upon that later. So if the app was a business product, I'd say what I built was the MVP.

• Programming Fundamentals help a lot: Knowing some programming fundamentals makes things easier. From recursively calling functions to separating code for modularity, it helped make the project a success.

• Build first, refactor later: I started building the app without having any code best practices in mind. It made building faster as I focused on solving the problem at hand rather than writing clean code. I only started refactoring after the app was ready and in good condition.

Contributions and Future Improvements

The project is open source, and everyone is free to contribute to it. Some of the improvements that can be made are:

• Restructuring the app files for more modularity

• Adding a private chat messaging feature

• Adding a group messaging feature by asking for a code before joining

• Better error handling

• Tests for the client's code

• Real-time notifications

• Restore 10 or more of the previous messages

• and more...

Project References

Demo Video

https://youtu.be/q7R8VUhbzQs

NPM Registry Link

https://www.npmjs.com/package/tarminal-chat-app

GitHub Link

https://github.com/HayatsCodes/terminal-chat-app

Conclusion

It was fun and challenging to build yet another project. From learning new and unfamiliar technologies to implementing several features, it was an enlightening and enriching experience. I look forward to building more and more as I search for my first job.