eahefnawy
commented
5 years ago @shaunc thanks for sharing your feedback. It's a bit hard for me to follow along though. Could you give an example of how such an API could look like?
Regarding roadmap, we're now in a "semi-stable" state. We still make breaking changes, but we now how complete docs coverage, and have almost 20 components written (all documented) against the core API (they serve as great examples!). Those components depend on each other, so using higher level components makes sure the lower level ones are also working. We are also published Github releases very frequently and add one line updates to the README.
Here are some resources:
Sorry for the late reply here 😊
I'm still waiting for some release notes or a more stable state before I try to figure out what you are doing.
While I'm waiting ... let me express a wish: I'd love serverless/components to be an IOC/DI framework for serverless. Components should be able to describe what they provide; other consuming components should be able to describe what they need. The library should figure out how to bind (and/or rebind), as components are updated.
From what I can figure out you aren't there yet. Conceptually, you would want to separate component interfaces (name;version->inputs and output) from actual component (implements interfaces, also has version, tags). Then the user could create a "deployment" which is a graph of component interfaces, together with tags for selection (including stage - dev staging prod). There would be a special component which puts together the graph and actually deploys. (You could sell a souped up enterprise version of this component -- tests are also tagged; we automatically try out components which pass their own tests in the "staging" deployment, and then define workflow to deploy to production....)