You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello @orefalo, tbh the K8s adapters from v1 were more a PoC than an actual production-ready implementation. We used Microsoft Dapr back then, and the implementation was very similar to the local provider one, with the difference that we stored everything in a single Redis store where concepts were separated via key (e.g. an entity would have a key entity:entity-name:...)
Still, creating a custom provider is not something extremely hard (as long as you know your way in the underlying tech for the provider, in this case K8s), as Booster tries to abstract everything into the core package of the framework.
Some Discord members have reported creating their own custom provider successfully starting with a copy of the local provider and then looking at the others (e.g. AWS provider) in order to implement it.
The overview of it is:
Create the implementation for the *-infrastructure package of your new provider, which will be in charge of creating and destroying the resources for the project
Then create the implementation for the provider itself (we call it provider library package) that will convert the data types that the infrastructure gives you into the Booster ones and viceversa (e.g. AWS Lambda event types into the Booster data types).
Mostly for every task like this there's a method specified in the interfaces that define how the providers get called, so it shouldn't be very hard.
Considering that v2 is different than the v1 branch,
How difficult would it be to bring back the k8s adapters?
In terms of effort, no who does it...
thank you
The text was updated successfully, but these errors were encountered: