Relevant Implications

Relevant Implications

The 2 Relevant Implications I chose for this project were Future Proofing and Privacy.
The implications im writing here are mainly for the chat app's backend API because that is where most of the logical and important code happens.

FUTURE PROOFING

While coding this app I took several steps to ensure that it would be easy to update and maintain.

I decided to use Python and the FastAPI framework to make the chats Backend. I did this because FastAPI is fast and great for api development and it supports many features. I also decided to use the javascript framework Electron for the frontend app. I did this so that the app could be run on all computers and has its own desktop app.

For the database I chose to use PostgreSQL because it is an open-source relational database which suits my use case of storing user data. Postgresql supports many complex datatypes and is highly stable so it is easy to update the data and make sure that it stays stable in the future. It also has many performance optimizations which is another reason for using it. This is crutual for the users who wouldnt want to wait ages for each message to be sent and synced on the server.

In the API i used Object Orienteed programming techniques to make sure that the code would be easy to update. I store all my data in dataclass model classes over just normal variables or json dicts. This is done so that my methods and attributes are not only orginized but can also be really easily updated in the future.
An example of this is seen here: https://github.com/Untitled-Chat-App/Backend/blob/main/src/core/models/room.py#L63-L129 Instead of indivisual functions and variables I chose to use strong oop code. This is done so my code is easy to update and easy to read for users. In the class example i use inheritance and polymorhism which makes my code even easier to update. I also use many class methods and attributes throught the api.

Another step i took while programming was by making a lot of reuseable code such as classes, models and utility function. I did this so that if in the future i needed to update a feature i can do it only in one place instead of everywhere. This makes sure that they will be minimal bugs which will make it easier to update and easier for the end users.

PRIVACY

In my chat app I am handling a lot of sensitive user data like users passwords and emails. Since im handling this type of data I ensured that all of this data was stored securely.

Authentication & Authorization:
Another way I made my API more secure and private was with authentication and authorization. I decided to use an OAuth type model to make it more secure.
To use most endpoints on the API I made it so that you need an access token. This can be obtained by authenticating your self with a username and password. The reason i chose to use this 2 step way of access tokens over a straight way of usernames and passwords was because it provides an extra layer of privacy and security to access the api. The users of the api only use their password for one request (to get the token) and then use the token from then on. The tokens are JWT access tokens with a 24h expiry. This is done so that if a users token is leaked it will be invalid after a couple hours which will greatly reduce the impact of any cyber attacks.
I also used scopes so each token only has the permissions that it has the scope for. This makes sure that eg if you are tying to just send a message you dont have access to delete rooms.

Zero Trust:
The API also runs on a Zero Trust model which requires every request to be authenticated and authorized. This ensures that no unauthorized requests are made to the API and that all user data is kept secure.

Storage:
The data is stored in a remote postgresql server protected with encryptions along with passwords. (See why i used postgresql in the future proofing relevant implication)

Password Hashing:
I also stored passwords hashed using a slow and secure hashing algorithm with randomized salts. This is done so that if there is a database leak, the users sensitive data will not be thrown out in plain text it will be hashed which is almost impossible to crack.

End to end Encryption:
In the app I also implemented the code for end to end encryption. (However I did not add it to the finished app). I decided to use end to end encryption to make sure users messages cannot be accessed by hackers, other users, or even me or the server. The only people who can read the messages are the sender and the reciever. This works by giving each user a public and private key. Messages are encrypted by the senders public key and decrypted by the recievers private key.