ragofjoes/mood-calendar

https://ragofjoes.dev/userauth

Mood-Calendar (Source Code: Private)

This web application is my first real attempt at creating a full stack web application. Which essentially just means that a lot of sleepless nights researching and head scratching occured. This being my first full stack web application also meant that a lot of lessons were learned along with some new found technologies(for me at least). Below some of the main obstacles that I faced whilst creating this web application are listed.

Obstacle One

The first real formidable obstacle that I came across was balancing my user authentication's security with user ease of use. This proved to be challenging as one of the main selling points of JWTs are that they’re stateless, meaning the token itself contains all the information required to verify a user. This meant that theoretically once a token has been created and stored inside the client, providing further credentials is unnecessary, however, as most developers know trusting the client is a big security hazard. One of the main reasons the client should never be trusted is that some users can be careless with their devices. This leaves the user vulnerable to all kinds of security risks such as session hijacking, and in turn leaves us vulnerable to all types of attacks such as XSS attacks. So, to cover the best of both worlds, I decided to rid of the statelessness of JWTs and created a whitelist schema in my DB with a TTL of 24 hours to provide a sort of 2 step verification with JWTs built in verify method and a query to search for the token in my DB. Creating a whitelist of tokens also allowed me to easily invalidate tokens, meaning if a user has too many login attempts or a user desires to change his/her password the server can then easily "kick" users that possess invalid/expired tokens.

Obstacle Two

After creating a working prototype of my user authentication I began working on the Mood Calendar's front-end. Not all that deep into it, I began to realize how bloated my components have become as well as how difficult the state management in my application has become. This realization forced me to rethink of ways to manage the states in my application. With a couple of nights researching, I came to two different conclusions, React's Context API and Redux. Both essentially did the same thing however, what put Redux above React's Context API, for me, was the fact that Redux was documented far more than React's Context API. Redux also had the Thunk middleware which made handling API requests extremely easy.

Obstacle Three

The last main obstacle that I faced when creating this web application, and even as of recently, was the lack of peers to collaborate with. The lack of programming buddies is mainly due to the fact that my current college doesn't have a course dedicated to Computer Science. This lack of collaboration and support from my college forced me to self-learn the entirety of the tools and methodologies that I used to create this web application. This isn't to say that it was a bad thing, in fact, because I was able to self-learn my way through a full stack web application I feel more motivated and more confident than ever in further developing and enhancing my coding skills.

Lessons Learned

Looking back on the development process of this web application, the amount of failures that I faced far surpasses the amount of fingers, toes, and even teeth that are in my body. That being said, I'm a person that has this surreal ability to treat failures as more of an encouragement rather than a discouragement which, lead to a number of sleepless nights and an infinite amount of cups of coffees consumed. On a more serious note, the amount of articles and docs that I read to aid in the development of this application has definitely given me enough confidence to tackle any programming project that I ever thought of when I was younger and even towards the beginning of my first year in college.