Skip to content

Conversation

@Jaden51
Copy link
Contributor

@Jaden51 Jaden51 commented Oct 17, 2025

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.
Screenshot 2025-10-17 at 11 32 16 AM

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 actual AuthRepository struct is an implementation of the services/auth/repository.go interface. 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 in services/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.

Copy link
Member

@bjzsh bjzsh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Jaden51 Jaden51 merged commit c842756 into main Oct 17, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants