Skip to content

Release v3.0.0
Compare
Choose a tag to compare
@XavierGeerinck XavierGeerinck released this 20 Mar 16:36
· 89 commits to main since this release
v3.0.0
ae34854
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

What's Changed

In this release we focused on cleaning up technical debt and introducing breaking changes. Please read carefully how to migrate your application code for the impacted lines.

Breaking Changes

Deprecation for dapr-client

As discussed in Deprecate dapr-client NPM package, the dapr-client package won't be published anymore from v3.0.0. Please use the newer @dapr/dapr package.

DaprClient's publish method now infers the content-type from data

feat(pubsub): Allow publishing CloudEvents directly by @shubham1172

Introduced by #371, this enhances the publish method to infer the content-type of the data instead of always using application/json. This enables CloudEvents to be published directly. Earlier, CloudEvents were also sent with the content-type application/json which was treated by the Dapr runtime as a JSON value and embedded in another CloudEvent. This means, editing CloudEvent fields (like type) was not possible earlier.

// Publish message to topic as application/cloudevents+json
// You can also use the cloudevent SDK to create cloudevents https://github.com/cloudevents/sdk-javascript
const cloudEvent = {
    specversion: "1.0",
    source: "/some/source",
    type: "example",
    id: "1234",
};
await client.pubsub.publish(pubSubName, topic, cloudEvent);

// Other examples where content-type is automatically inferred correctly.
// Publish message to topic as text/plain
await client.pubsub.publish(pubSubName, topic, "hello, world!");
// Publish message to topic as application/json
await client.pubsub.publish(pubSubName, topic, { hello: "world" });

DaprClient's publish method allows specifying an explicit content-type

feat(pubsub): Allow setting explicit content-type during publish operations by @shubham1172

The content-type used in the publish method can also be explicitly specified instead of inferring from the data itself. This can be useful in scenarios when users want to send a JSON data as plain text, or a CloudEvent as vanilla JSON.

// Publish a JSON message as plain text
const options = { contentType: "text/plain" };
await client.pubsub.publish(pubSubName, topic, { hello: "world" }, options)

Address parity between DaprServer's subscribe method's HTTP and gRPC implementations

fix(pubsub): Fix parity between HTTPs and gRPC pub/sub by @shubham1172

Introduced by #343, this aligns the HTTP and gRPC pubsub systems to return data in the same way for both the normal and rawPayload modes.

The HTTP subscribe callback now returns data after parsing it correctly. Data is either extracted from the body's data field, or the data_base64 field. data_base64 is always expected to be a base64 encoded string, and will be decoded and parsed as JSON if possible. If it is not JSON, it will be returned as a string. If data is not found in either field, the entire body will be returned as-is.

Update DaprClient APIs

chore: Update DaprClient API by @shubham1172

Introduced by #442, this introduces a new API specification for DaprClient. As the Dapr JS SDK grew, so did the the parameters to the different functions. The API has changed to incorporate an options object where it makes sense. More specifically the following APIs are impacted:

  • DaprClient: an options parameter containing details like communication protocols, Dapr sidecar's host and address, etc. is used to instantiate the object. Options can also be empty, which then uses some sane defaults (e.g. new DaprClient()) specified here.
  • IClientState: getBulk method now takes an options parameter to configure the metadata and parallelism.
  • IClientPubSub: publish method now takes an options parameter to configure the metadata and content-type for the data.

Update DaprServer APIs

chore: refactor DaprServer API by @DeepanshuA

Introduced by #444, this is similar to the above change and introduces a new API specification for DaprServer.

DaprServer's instantiation does not need any required parameters now. All the configuration can be passed using an options parameter. Note, logger settings and communication protocol is shared with the underlying DaprClient object unless it has its own such parameters specified.

Features

  • feat(core): Allow payloads larger than 4MB by @XavierGeerinck in #381
  • feat(core): Implement serialization for gRPC and HTTP in a similar way by @XavierGeerinck in #381
  • feat(core): Implement deserialization for gRPC and HTTP in a similary way by @XavierGeerinck in #381
  • feat(core): Support bring your own express instance through the serverHttp option by @XavierGeerinck in #381
  • feat(pubsub): Add bulk publish support by @shubham1172 in #430
  • feat(pubsub): Add retry logic for PubSub and Implement Deserialization generalized by @XavierGeerinck in #453
  • feat(state): Allow passing metadata to client.state.save and return a custom response with error by @shubham1172 in #461

Fixes

  • fix(invoke): Allow invocations for non-string or object data by @XavierGeerinck in #381
  • fix(actors): Error shouldn't cause Client Fail If Actor Non-Existent method called by @DeepanshuA in #422
  • fix(docs): Fix broken link to Setting up a Typescript project by @marcduiker in #450
  • fix(pubsub): Fix metadata setting in gRPC pubsub and bindings by @shubham1172 in #458

Chores

Tests

  • test: Allow writing Dapr logs to file in e2e test shell script by @shubham1172 in #457

New Contributors

Full Changelog: v2.5.0...v3.0.0

Contributors

XavierGeerinck, DarqueWarrior, and 4 other contributors
Assets 2
Loading