iasql
iasql copied to clipboard
alantech
Multi-Cloud Support RFC
I was thinking that we could have some kind of inheritance, where there can be a parent
providersclass/interfaces with basic functions for creating/removing the provider, creating credentials, etc... then we can have the provider classes that implement/override those methods and have specific functions depending on the logic of the provider. Is that how we will be approaching the code?
So Javascript doesn't have explicit multiple inheritance. There are mixins that could be used, but I was thinking (for the two Provider-like options) of using Typescript's implements functionality, since both of those proposals just need some extra methods and static properties defined, and don't have the weird backwards-compatibility needs that the base classes with their init functions bolt on (that I am looking forward to excising soon).
Also other thing that was not covered will be the organization of modules inside code. Howe are we going to group them? Will it make sense at this point to change about mono-repo vs multi-repo?
Also other thing that was not covered will be the organization of modules inside code. Howe are we going to group them? Will it make sense at this point to change about mono-repo vs multi-repo?
Well, I would consider this RFC part of the "pre-requisites" to that sort of change. To pull the modules out of the repo and version them independently of the engine code we need to address a lot of concerns, but part of that would require a very stable module interface. This is because future changes to the interface will break existing modules hard and require all external repos to get updated with no centralized test suite to help you spot a missing update.
None of the four options I put in this RFC so far really change the code organization, just various approaches on how to better handle the modules that iasql_sync doesn't work for.
Only adding a typo comment for now. I think I need some time to think about the proposed options.
If we adopt one of these four as-is, I would personally go with the second option, the Provider-Module approach.
I am hoping during a critique of these options we can come up with something better than them all, though.