Backend Refactor: Discussion On Issues And Improvements

Hey guys! Let's dive into a crucial discussion about refactoring our backend. This is super important for making our system more efficient, maintainable, and just plain better to work with. So, buckle up and let’s get started!

Description of Backend Issues

Okay, so the current backend setup has a few quirks that we need to address. These issues range from navigation problems to code duplication, and they're making our lives harder than they need to be. Let's break it down:

First off, navigating through definitions is a pain. You'll always get stuck at the repository type, which makes it nearly impossible to find what you're actually looking for. This is like trying to find a specific book in a library where all the shelves are mislabeled – super frustrating!

Secondly, each core service is essentially duplicating its corresponding repository. I mean, come on! This is a huge waste of code and makes maintenance a nightmare. Imagine having to update the same piece of logic in multiple places. No thanks!

Then there's the translation issue. Translations are happening in each service separately, which is totally inefficient. We could be using a single logic for all translations, which might not even be necessary in some cases, like with the ScientificWorksService. It’s like having multiple translators for the same language when one could do the job perfectly well.

Service scoping? Well, it’s not really working. Services are scoped in a container that’s a singleton, so they all have the same lifespan. Plus, the container was designed to be unique per request, which just adds to the confusion. It’s like setting up a VIP room that everyone has access to.

And don’t even get me started on the lack of type assistance after resolving services. For example, artistryService is treated as any, which means no type safety from there on out. This can lead to some nasty surprises down the line. It's like driving without a map or GPS – you might get there, but you'll probably take a few wrong turns.

const artistryService = createRequestContainer().resolve('artistryService');

Verbose Syntax and Unnecessary Complexity

The container syntax is also way too verbose, with unnecessary compositions and decompositions that make the code harder to read and understand. It’s like trying to assemble IKEA furniture with instructions written in hieroglyphics. For instance, look at this:

foundationInfoService: asFunction(({ foundationInfoRepository }) =>
  createFoundationInfoService(foundationInfoRepository)
).scoped()

With a minor argument type change, we could shorten it to:

foundationInfoService: asFunction(createFoundationInfoService)

Awilix supports this out of the box, so why not use it? Check out the Awilix docs for more info.

For composed services, it gets even crazier. Dependencies are decomposed only to be composed again for the call. It's like disassembling a sandwich just to put it back together. Take this example:

headerService: asFunction(({ foundationInfoService, navigationService }) =>
  createHeaderService({ foundationInfoService, navigationService })
).scoped()

Repository Quirks

And let's not forget the repositories. They have their own special quirks, like this:

foundationInfoRepository: asFunction(() => foundationInfoRepository).scoped()

Under normal circumstances, I might let this slide, but considering everything else, it’s time to make some changes. With a few tweaks, everything could look like this:

<awilix registry entry>: asFunction(<constructor>).<lifetime>()

This is much cleaner and easier to understand, right?

Steps for Backend Refactoring

Alright, so how do we tackle this beast? Here’s a suggested plan of attack:

1. Determine what is reasonable to change or add: Let’s figure out what we can realistically accomplish in this refactor. We don’t want to bite off more than we can chew. This involves prioritizing the most impactful changes that address the core issues we've identified. We should consider factors such as the complexity of the changes, the potential for disruption, and the available resources. It's crucial to set clear, achievable goals to ensure the refactor stays on track and delivers tangible improvements.

2. Apply those changes: Once we have a plan, it’s time to get our hands dirty and start refactoring the code. This is where we roll up our sleeves and start implementing the changes we've identified. This might involve rewriting certain parts of the backend, optimizing algorithms, or restructuring the codebase. Attention to detail is key here to avoid introducing new bugs or regressions. Regular testing and code reviews are crucial during this phase to ensure the changes are implemented correctly and maintain the overall stability of the system.

3. Check if everything is still working: After making the changes, we need to make sure everything still works as expected. This means running tests, doing manual checks, and generally making sure we haven’t broken anything. This is a critical step to ensure that the refactoring process hasn't introduced any regressions or unexpected behavior. Comprehensive testing should cover various scenarios and edge cases to identify and address any potential issues early on. It’s also a good idea to involve stakeholders in this phase to gather feedback and ensure the refactored backend meets their needs.

Expected Result: A Better Backend Experience

The ultimate goal here is to have a backend that’s nice and easy to use. If fortune smiles upon us, we’ll end up with a system that’s more efficient, maintainable, and a joy to work with. Imagine a backend where you can easily navigate definitions, avoid code duplication, and have proper type assistance. That’s the dream!

This means:

• Improved Code Readability: A cleaner codebase that’s easier to understand and navigate.
• Reduced Code Duplication: Eliminating redundant code to make maintenance and updates more manageable.
• Better Performance: Optimizing the backend for improved speed and efficiency.
• Enhanced Type Safety: Ensuring type safety to prevent runtime errors and improve code reliability.
• Simplified Dependency Management: Streamlining the way services and dependencies are managed within the application.

Extra Resources and Visual Aids

To give you a better visual understanding of the issues, here’s a little something:

Fig. 1: An illustration of the code duplication issue.

This image highlights the duplication of logic across services, which is one of the core problems we're aiming to address in this refactor. It’s a clear example of how the current structure can lead to inefficiencies and maintenance headaches. Visual aids like this can be super helpful in conveying complex issues and getting everyone on the same page.

So, there you have it! A comprehensive overview of the backend refactor discussion. Let's get this done, guys, and make our backend shine! Remember, this is a team effort, and your input is invaluable. Let’s work together to create a better, more efficient backend system.