Hide external dependencies behind local interfaces/implementations

[raveclassic]

Hi all.

Recent update to platform show that we have too much external dependencies in the code. Refactoring gets too complicated and requires lot of unnecessary changes. For example, if we need to migrate from rxjs to mostjs we need to rewrite the whole codebase. However if we had a proxy/wrapper in utils (e.g. Stream) we could only change its implementation and don't touch the code. The same applies to libraries such as fp-ts. We could have local interfaces and implementations just forwarding calls to fp-ts and the rest of the code would be library agnostic.

So this ticket is going to track the upcoming migration.

[sutarmin]

I like the idea of being a stream library agnostic. Stream interface with bridges to rxjs and mostjs seems to be the appropriate way of doing it.

At the same time, it doesn't make sense to me to be fp-ts-like library agnostic, because we are too heavily dependant on fp-ts and this will result to a copy-pasting all the fp-ts interfaces to our repo and updating them along with fp-ts updates (to be compatible at least with fp-ts). A lot of stuff to maintain without the strong need of doing it because it doesn't look like there are a lot of fp-ts-like libraries existing and we want to easily switch between them.

I suggest moving the stream library abstracting to a separate issue and continue discussion of what we want to be abstracted beside it in this issue.

[raveclassic]

One of the ideas behind hiding fp-ts is to be fully static-land compatible which found no support in fp-ts in the recent PR. Moving to static-land means replicating fp-ts typeclasses in a curried data-last manner which is more suitable for pipe without messing with pipeable. I'm open to discussion though.

[sutarmin]

Hm, got it, but that's quite unexpected for me, let me think about it for the weekend. In the meantime, shall I create a separate task for abstracting over stream libraries? We can start discussing the details of Stream interface there

[raveclassic]

Yeah, let's split. Abstracting over observable implementation seems a good start.