Introduce UrlRepository abstraction layer #165
Merged
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.
Problem
According to #156, the back-end directory structure beginning to look incoherent and is showing signs of unbridled growth. It is currently a good time for refactoring given the recent expansion of file upload feature.
This process will start with refactoring and introducing an abstraction barrier between the data store and other parts of the code.
Solution
Refactor API endpoints to use UrlRepository when accessing data store.
Improvements:
Alternatives Considered:
I have considered sharing more methods in the BaseRepository interface but found that we have few repositories and they have unique requirements. e.g UrlRepository needs to handle files/cache/db, Otp needs cache only, User needs db only.
For the same reason, I also decided against having a BaseCache/SequelizeRepository and it is difficult to share code and method signatures.
As transactions in URL involve both S3 and Sequelize, it is difficult to abstract them into different files while keeping code readable, hence the relatively large size of UrlRepository.
Tests
I have run through the following on staging: