Abstract image file access

[matheusgomes28]

Make the access to the image files happen through an interface. This would make testing the actual business logic of the image endpoints a little easier, so we don't rely on the file system.

For e2e tests, we can still use the filesystem!

This is similar to the Database interface we have, but for the images.

[rafiramadhana]

Hi @matheusgomes28 , this issue seems interesting to work

However, I have some questions here:

• Does this issue depends on #64? Or we can start to work by abstracting existing image file access implementation
• I've read the codebase, it looks like existing image file access implementation is located in ./admin-app/image.go. Which is only in postImageHandler (as in the main branch), is this correct?

[matheusgomes28]

Hey @rafiramadhana , thanks for your interest in this task !

Yes, it does depend on that task as the get endpoint for the images need to be merged in for us to abstract it. It should be merged as soon as the suggestions in the PR are fixed 😄

[rafiramadhana]

Yes, it does depend on that task as the get endpoint for the images need to be merged in for us to abstract it. It should be merged as soon as the suggestions in the PR are fixed 😄

Got it. So, let's wait until #64 get merged.

[matheusgomes28]

64 is now merged FYI

[rafiramadhana]

@matheusgomes28 Hi, I've just skimmed through the codebase, let's assume we will name our interface as MediaVault (as mentioned here)

MediaVault will have 3 methods (this is very open to discussions and suggestions)

type MediaVault interface {
    Add(string) error
    Get(string) ([]byte, error)
    Remove(string) error
}

// Example
err := mv.Add("/file.txt")

b, err := mv.Get("/file.txt")

err := mv.Delete("/file.txt")

MediaVault will be implemented in given endpoints:

ADMIN

• GET /images/:id -> not needed. no filesystem op
• POST /images -> .Add
• DELETE /images/:id -> .Delete

NON-ADMIN

• GET /data/images/:id -> .Get

Wdyt?