[#16] Multiple backends support

[DK318]

Problem: at this point we can store secrets only in one backend. Solution: added optional argument [-b|--backend] which specifies the backend that we are working with. Fixed: #16

[Heimdell]

(approve if @dcastro's issues with PR are fixed)

[dcastro]

Don't forget to:

1. Add some tests after rebasing
2. Add Fixed: <issue number> to the PR's description

[MagicRB]

Im necroing this, but doesn't moving the effect functions into the Backend a kind of beat the point of using polysemy? I don't think this is a very elegant solution

[dcastro]

doesn't moving the effect functions into the Backend a kind of beat the point of using polysemy?

Do you mean the ability to have multiple interpreters for the same effect?

We can still have different interpreters:

logBackend :: Member (Embed IO) r => Sem (BackendEffect ': r) a -> Sem r a
logBackend = interpret \case
  WriteSecret _ entry -> embed do
    putStrLn "writing secret"
    print entry

Though we don't have the ability to have an interpreter that discriminates between different types of backends (e.g. an interpreter that behaves one way for vault and another way for pass).

I don't think this is a very elegant solution

I agree something feels odd but I can't quite put my finger on it. Do you have an alternative solution?

[MagicRB]

We could maybe add an effect, which temporarily switches the interpreter

do
  readSecret
  res <- tempSwitch _runBackendPass $ do
    readSecret
    writeSecret

Essentially tempSwitch is just embed actually not essentially but yes it is. What API would we want? Im having a hard time to even imagining a good api