refactor: changing code infrastructure for better practices #22
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is part 1 of the backend refractor to use modern best practices. I will go over the changes and the reason for them below.
Here is the general overview of how I believe the backend should be structured. Let's go over it part by part and then I'll explain how it all fits together.

Database Directory
This is where all the core database logic will live. This is where we implement the functions that will call our database. This should not have any other dependencies besides our actual database implementation.
Services Directory
This is where all the business logic will live, abstracted away from everything else. I will explain the abstraction below.
Application Directory
This is where our application services functions will go which is the abstraction between our handlers and our services. The goal of this is to make sure that when we edit our handlers, we don't need to edit our services. We want to develop in isolation.
Handlers
This is where our endpoints will live.
How it all comes together
Starting with the database directory, we have a file called
auth_repository.go. As mentioned, this where all the database logic lives without knowledge of anything else in the system. The important thing to note is that the actualAuthRepositorystruct is an implementation of theservices/auth/repository.gointerface. The main reason for doing this is that our domain and business logic does not depend on the actual database implementation. As long as the repository that we are passing into our service has the functions defined inservices/auth/repository.go, our business logic doesn't actually care about what the database looks like. We could change it to Mongo, use redis etc. without actually modifying our business logic. It also services as a contract between our business layer and database infrastructure on what our services actually need. It also creates a clear boundary between our layers.The service and business logic is called by the application services which is just another layer to isolate the business logic. I haven't implemented this yet but hopefully you can kind of get the picture.
I haven't implemented any of the code yet just boilerplate functions for now so hopefully you can get the picture without all the messy implementation details.
Upcoming changes
In further parts, I am going to finish up refactoring the auth functions and the handlers as well as the application services.