feat: add keyValueStore.getRecordPublicUrl

[danpoletaev]

This PR adds new method to KV store client:

• getRecordPublicUrl(key: string)

Note: We already have this same method (KeyValueStore.getPublicUrl) in SDK.

[janbuchar]

Pardon me being blunt, but what's the endgame here? Are users expected to stop using KeyValueStore.getPublicUrl and use this instead? Should both co-exist in harmony?

[danpoletaev]

Pardon me being blunt, but what's the endgame here? Are users expected to stop using KeyValueStore.getPublicUrl and use this instead? Should both co-exist in harmony?

KeyValueStore.getPublicUrl is SDK method, now I've added same logic to the client. While creating new Actors, people would use mainly SDK, but there would be other cases when you'd want to use it without SDK 🙃

[janbuchar]

Pardon me being blunt, but what's the endgame here? Are users expected to stop using KeyValueStore.getPublicUrl and use this instead? Should both co-exist in harmony?

KeyValueStore.getPublicUrl is SDK method, now I've added same logic to the client. While creating new Actors, people would use mainly SDK, but there would be other cases when you'd want to use it without SDK 🙃

Huh, okay, what would those cases be? From the perspective of an Actor developer (or anyone primarily using the SDK), having two slightly different (or are they?) ways to achieve the same thing is very confusing.

[danpoletaev]

Pardon me being blunt, but what's the endgame here? Are users expected to stop using KeyValueStore.getPublicUrl and use this instead? Should both co-exist in harmony?

KeyValueStore.getPublicUrl is SDK method, now I've added same logic to the client. While creating new Actors, people would use mainly SDK, but there would be other cases when you'd want to use it without SDK 🙃

Huh, okay, what would those cases be? From the perspective of an Actor developer (or anyone primarily using the SDK), having two slightly different (or are they?) ways to achieve the same thing is very confusing.

For example you just want to use our API, why would you download whole Apify SDK with Crawlee for that?
I suppose our integration team will mostly use client instead of SDK.

Also, in apify-cli I need this method to sign a tarball ZIP of the build.

Methods are nearly identical in SDK and client

[janbuchar]

Pardon me being blunt, but what's the endgame here? Are users expected to stop using KeyValueStore.getPublicUrl and use this instead? Should both co-exist in harmony?

KeyValueStore.getPublicUrl is SDK method, now I've added same logic to the client. While creating new Actors, people would use mainly SDK, but there would be other cases when you'd want to use it without SDK 🙃

Huh, okay, what would those cases be? From the perspective of an Actor developer (or anyone primarily using the SDK), having two slightly different (or are they?) ways to achieve the same thing is very confusing.

For example you just want to use our API, why would you download whole Apify SDK with Crawlee for that? I suppose our integration team will mostly use client instead of SDK.

Also, in apify-cli I need this method to sign a tarball ZIP of the build.

Yeah, I get that sometimes you want to use the client without pulling in the SDK along with crawlee as a dependency.

Methods are nearly identical in SDK and client

And that's probably my main issue. If we make the KeyValueStore.getPublicUrl async in crawlee v4, I guess we should be able to make it simply delegate to the client?

[tobice]

Approving. Agreed with the points here... the end game should be that we can just proxy the client implementation from SDK.

And perhaps the naming should be unified 😄

[tobice]

Suggested change

	* the URL will include a signature to verify its authenticity.
	* the URL will include a signature which will allow the link to work even without authentication.

[janbuchar]

And perhaps the naming should be unified 😄

Yes please!