This issue is for collecting ideas and opinions about what our 1.0 API should look like. The primary focus is on the user-facing API. Though some decisions may have consequences for the internal APIs. We need to choose this direction and get out a beta in the coming months. From there we can iterate until we feel ready to public a 1.0. Once we can publish a stable API, we can start building some of the nicer layers on top and we can better support people in production.
This issue will have both a goals and a tasks section. I'll add items to both as we discuss in the team meetings and get a consensus on the ideas. Please issue your ideas and proposals as comments.
Goals
Security
Are we doing our best to make it clear how to use Chicory securely?
Are there any footguns that might make it easy to apply an insecure pattern?
Stability
Are we ensuring that our API allows all the things users may need to do?
Are we ensuring that our API can support future specs without breaking it?
Familiarity and Compatibility
Are we borrowing from other runtimes as much as possible?
Will the API be familiar to someone who has used a Wasm runtime in anger before?
Performance
We don't need the most performant interface
But does what we choose lock us into performance we cannot upgrade?
How can we bring performance improvements without interrupting users?
This issue is for collecting ideas and opinions about what our 1.0 API should look like. The primary focus is on the user-facing API. Though some decisions may have consequences for the internal APIs. We need to choose this direction and get out a beta in the coming months. From there we can iterate until we feel ready to public a 1.0. Once we can publish a stable API, we can start building some of the nicer layers on top and we can better support people in production.
This issue will have both a goals and a tasks section. I'll add items to both as we discuss in the team meetings and get a consensus on the ideas. Please issue your ideas and proposals as comments.
Goals
Tasks
TODO