quickstarts
quickstarts copied to clipboard
Cleaning up Coming Soon placeholders
I'd like to get opinions from the community and maintainers @msfussell @amulyavarote here.
Right now we have have a coming soon
in the table for quickstarts for every API in Dapr. I think now that we have critical mass with APIs, this looks silly to have these coming soons, and I propose we track work here vs have Coming Soon on the website/docs.
I also think given cost to write and maintain these, and really support well, I'm not sure we want a quickstart for every single API forever. It would help to know where this is most useful to the community.
More specifically:
- Configuration - I believe we SHOULD do this based on high relevance to most apps and users. It is also a good API for this format.
- Observability - i believe we SHOULD NOT do this. I could be convinced however to configure the observability component to work well for all other quickstarts, and have a step that guides users to look at the Zipkin dashboard.
- Actors - I'm on the fence but currently believe we SHOULD do this since we see interest in actors and it may be harder to get going in a practical use case.
- Distributed Lock - right now this feels very narrow and not widely applicable, so I think we SHOULD NOT do a quickstart until we hear more interest. Dapr Docs? certainly.
Thoughts?
BTW, this is the symptom I'm talking about on https://docs.dapr.io/getting-started/quickstarts/
@paulyuk I also think the priority should be given to configuration API. We can take out Observability from the list as an example is already included in the tutorials section.
should we PR a change then, only leaving Configuration for now?
#keepalive to @msfussell @amulyavarote so we can move forward!
Actors and configuration for certain. None of the quickstarts are practical, so actors does not need to be. However there is a large gap in having actor samples currently.
All the APIs should have examples in my opinion including lock.
The observability tutorial needs updating to include OTEL, although what OTEL observer can be used locally is an open issue and the ZipKin containers can remaining.
Hi @paulyuk and @msfussell, Sarthak from IDC has picked up the configuration one. Waiting for the update or waiting for the PR to review.
Issue resolved