1. The library itself is stateless, so it scales along with backend services.
2. The size is limited by backend service, such as the size of your cache cluster.
3. Because all operations go through the backend service, the existing telemetry, logging and monitor tools are still applicable. However it cold be a good idea to include more metrics counters to provide fine-tuned perf info.
4. There will be more blog articles and video introductions coming out. Keep tuned!
Thank you for your interests in WACEL! WACEL is designed to make common scenarios easier. If you have any scenarios that you think that WACEL could be helpful, please feel free to reach out to us by sending a mail to firstname.lastname@example.org.
Hi PeterNL: Thank you for comment. We have a couple of episodes being edited at the moment and we are recording more. This is a new series and there are still some details we need to work out. So we might be slow in releasing the first few episodes.Thank you for your patience, and please keep tuned! And if you and anyone else in the community want to share your experiences you are welcome to contact me at any time.
An e-commerce transaction is not completed until the actual merchandise has been shipped. However to get the goods to be shipped people are forced to disclose their real addresses to online venders. Here’s my two cents – an anonymous shipping system. Basically
a user will pick one trusted carrier such as UPS and get a token that represents her address. Then when she’s purchasing online, she’ll give the token to the vender instead of a real shipping address. The vender can call to UPS service to validate the token
and get shipping cost estimation (or the token can have zip code in it for cost estimation), but the vender never knows where the product is shipped to. The token can be static or dynamic – user can apply new tokens any time. I’m not sure if U-Prove consider
the scenario like this?