Fix and normalize the Javascript HTTP and SDK styles of State Management

[mattmazzola]

Description

Both the HTTP and SDK tutorials demonstrating State Management using JavaScript had many mistakes and inconsistencies making them poor quality.

As mentioned in those issues there were numerous problems:

• Not using async await
• Not awaiting the sleep
• Using function called start that didn't actually start anything
• Creating a DaprClient every iteration of the loop instead of once and re-using
• Attempting to use the return value of HTTP save request, but this returns void
• Inconsistency in how data was access from axios response
• Inconsistency in setup of DAPR_HOST and other variables

You can see both tutorials now function with the same output:

Normalization of HTTP and SDK

The purpose of having the HTTP and SDK folders was to show them doing the same thing and how a developer may choose to use the SDK or may user HTTP directly.
The inconsistencies between the two code samples meant that there were many other changes besides merely using the SDK or not which distracts the user from recognizing this.

By removing all the inconsistencies, or normalizing the code it can be seen much more clearly that the ONLY change is the swapping of SDK calls for HTTP requests.

Issue reference

We strive to have all PRs being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close:
Closes #2495
Closes #2494
Closes #693

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• The quickstart code compiles correctly
• You've tested new builds of the quickstart if you changed quickstart code
• You've updated the quickstart's README if necessary
• If you have changed the steps for a quickstart be sure that you have updated the automated validation accordingly. All of our quickstarts have annotations that allow them to be executed automatically as code. For more information see mechanical-markdown. For user guide with examples see Examples.

[paulyuk]

LGTM. Really nice contribution and improvement, @mattmazzola Thank you!. I'd love to make a little style guide with things like use Await instead of and not including .then, etc, removing last ; etc.

[paulyuk]

I would love @XavierGeerinck (js maintainer) and @amulyavarote (author) to review too.

[XavierGeerinck]

I would love @XavierGeerinck (js maintainer) and @amulyavarote (author) to review too.

Added my review on it, thanks for flagging me in it! :) really nice PR

[amulyavarote]

I would love @XavierGeerinck (js maintainer) and @amulyavarote (author) to review too.

Review looks good to me!

[XavierGeerinck]

You don't need to use the host here as we will automatically do this for you (https://github.com/dapr/js-sdk/blob/master/src/implementation/Client/HTTPClient/HTTPClient.ts#L47) so you can drop the url creation here and just pass localhost.

As for which protocol to use, maybe you can just use:

import { DaprClient, CommunicationProtocol } from "@dapr/dapr";

const protocol = (DAPR_PROTOCOL === "http") ? CommunicationProtocol.HTTP : CommunicationProtocol.GRPC;
const client = new DaprClient(host, PORT, protocol); 

[mattmazzola]

Ok, I updated to use something similar to your suggestion

• Use CommunicationProtocolEnum instead of 'http' string
• Remove protocol from url construction and instead pass protocol to DaprClient constructor
• use lowercase version of variables (port, host, etc) since they were not constants
• Remove orderId to avoid confusion about why it wasn't used

Given DAPR_PROTOCOL is non standard and is NOT set automatically by the Dapr CLI like the other env vars we have to assume it will not be set and in that case default both to "http"

Ideas for Dapr / CLI improvement

Given this determining of which port / env var to use based on protocol is going to be common across all Dapr apps. I think there should be first-class support for this in the Dapr SDK and the Dapr CLI should make DAPR_PROTOCOL standard and set it just like DAPR_GRPC_PORT and DAPR_HTTP_PORT

option	var
--app-protocol http	? (why is nothing set for this?)
--dapr-http-port 3500	DAPR_HTTP_PORT
--dapr-grpc-port 6001	DAPR_GRPC_PORT

[amulyavarote]

@mattmazzola Hi! Thanks for this contribution. Can you please take the latest changes, rebase and push the changes? We actually pushed few changes recently to fix the build issues. Pulling and rebasing the latest changes should fix your PR's build issues. Thanks!

[amulyavarote]

Other changes look good to me!

[amulyavarote]

Hi! Can you please fix state management workflows and also DCO?

[mattmazzola]

Hi! Can you please fix state management workflows and also DCO?

No, I don't know what those terms mean. I thought this would be a simple PR, but this ridiculous. I give up

[msfussell]

@mattmazzola - @amulyavarote will work with you to resolve the above. This PR is too good to drop. We really welcome your contribution here and apologize if this is unclear. We will work to make the testing need to be simpler.

[msfussell]

LGTM