Learning: Before Auth, Scarcom project
Documenting my learnings. Intro to project. I refactored the codebase to a large extent, its reasons.
In this blog, I document my learnings from the pre-authentication implementation phase of the Scarcom project. This also includes an introduction to the project, the key insights gained, and an in-depth look at why I refactored the codebase to a large extent along with references.
To view the github repo, click here. To view the website, click here
Introduction
The aim is to develop a responsive chat system while keeping in mind the user interaction and application access. The system is developed to be a functional and user-friendly chat platform, showcasing my technical capabilities and attention to detail. The implementation will use Nextjs 14, Pusher for real-time functionalities and Neon PostgreSQL for database management.
The intention behind this project is to demonstrate my technical skills and provide a tangible proof of work.
why nextjs 14, why pusher, why neon postgres
Next.js 14 was chosen because, at the time of development, Next.js 15 was considered unstable. However, this no longer seems to be the case. Additionally, Next.js 14, combined with Vercel, allows for free deployment, making it a cost-effective solution. It also enables the implementation of authentication with NextAuth along with middleware enhancing security. Furthermore, I chose Next.js to demonstrate my proficiency with the framework, having previously worked on a React project.
To ensure application accessibility, Next.js application is run on Vercel, which offers a free tier making it a cost-effective solution. Next.js based application, being run on Vercel, a serverless platform, cannot directly make use of WebSockets. Pusher solves this problem. Pusher primarily utilizing WebSockets with a robust fallback system and offering a free tier, presents a cost-effective, reliable, and low-latency solution that aligns perfectly with the needs of a real-time chat application.
PostgreSQL offers simple and effective database management, making it a suitable option. It is widely recommended by individuals on platforms like Reddit and also features prominently in Stack Overflow surveys as a popular and top-used database, ensuring it is a valuable skill. Coupled with Neon's free tier, this provides a cost-effective solution.
Why I decided to refactor
I decided to start the project over from scratch when I was on the verge of finishing the auth phase of the project. There are a few reasons for this. Both the codebase and commit log lacked structure with time.
stick with one collection of ui components
My initial approach involved using both Shadcn and NextUI. While I appreciated Shadcn for its vast collection of components, particularly the sidebar and sonner toast, I found NextUI's user feedback to be more appealing, for example when user clicks on a button.
However, as the project progressed, these two together proved to be less than cohesive, leading to some added complexity. Though I was already aware that shadcn offered a greater degree of ease in terms of configuration, this experience further solidified that belief. This led me to use only Shadcn for the UI.
I now believe that a crucial aspect of effective software development lies in prioritizing simplicity, and I've learned that having more choices is not always advantageous.
follow git conventions
The commit log had become disorganized as the project progressed, and I began to doubt its support in the project's maintenance and development. This led me to explore and determine if there were any standards or guidelines that I could try to follow. Eventually, I found a website outlining Git conventions. I briefly reviewed it .
My subsequent thought was realising that I could leverage AI to assist me with this task of writing proper commit messages, and I did exactly that for most of the commit messages.
The workflow with AI: Initially, I provided a brief overview of the project. Then, for each commit, I explained the changes done, including the reasons behind them. I explicitly instruct the AI to follow git conventions before asking it to provide a list of suggestions for a clear, concise commit message.
rename your icons
Auto-suggestions are beneficial; they reduce development time. However, on some occasions, it almost took me an hour or so to debug an issue caused by importing from an incorrect library. For instance, the Link component exists in both lucide-icons and next/link. This same issue would likely arise with other similarly named components, such as a user component created by a developer or a user icon present in an icon library. There is a chance of this happening the other way around as well. I removed the chance of this happening at all by making sure that whenever I use icons, I rename them appropriately. Such as the following
import {User as UserIcon, Loader2 as LoadingIcon} from "lucide-react";this is how i handle errors for now
I find the use of try-catch blocks to be undesirable due to the excessive nesting. It hinders both the readability and writability of code. I am inclined to use catch method, assigning it a function reference that is specifically designed to handle errors. However, I am also inclined to use other ways, if there is a set standard on how to handle errors properly.
miscellaneous
Additionally, there are several other practices I intend to consistently follow during development, as detailed below:
To ensure a clear separation of concerns, I make sure to split logic and design effectively. I utilize hooks to encapsulate logic and maintain a clean separation from the presentation layer. If there are subcomponents involved, I intend to pass the necessary data to them from the hooks within the main page, whenever appropriate.
I make sure to minimize nesting as much as possible to improve code readability and maintainability.
I make it a preference to use function references whenever feasible, rather than defining functions directly within parameters.
References
Pusher is a hosted websockets solution. Pusher has a fallback mechanism.
PostgreSQL: 2024 Stack Overflow Survey. 2023 Stack Overflow Survey.
Any suggestions and corrections that may push me towards becoming a better software engineer are always welcome