Node/Typescript SDK

By definition any TypeScript SDK can be used as a JS SDK once compiled, but not the other way around of course. Now, if your mention to node vs JavaScript is to suggest it be browser friendly I also think with modern webpack/Babel it ought to be browser capable insofar as it isn’t a thing wrapper around some native libraries that just exposes those to the node/js runtime which I don’t think is the case but I have no insider info.

But, nothing is really TS specific without also having Js compatibility as TS just gets turned into Js anyway. It may not be as debug friendly but it actually isn’t that bad unless it’s been minified…

Sorry to keep poking. Was this delayed?

1 Like

We already released sdk-core that NodeJS uses internally. We are planning to release the sdk-node later this week.

1 Like

Sounds good, thanks for the update.

Thanks for the update, Maxim. I know we can/should just wait for the release, but could you share some high-level info on how the sdk-node will be in terms of feature completeness esp in relation to the Go SDK? We have some decisions we’ve been waiting to make and were hoping to have seen that by now and I’m actually pausing on hiring a few folks so even a “it’ll be close” or “tons left to do” (not in terms of production-ready, but in terms of feature-completeness), so this would be helpful.

Thanks!

1 Like

We expect it to be fully feature complete. But it is a process that is going to take some time.

It is actually going to be much better than the Go SDK. The reason is the power of V8 isolates. Each workflow will be fully isolated in a deterministic container. So developer will not need think about determinism as it would be able to use global variables and any available APIs for time and random without any problem.

2 Likes

This is awesome! NodeJS with WebAssembly is a really powerful platform and rust is a perfect match.

That’s excellent news, @maxim! Looking forward to seeing the repo and getting started with it!

Thanks for the info!

Note that we are going to open it well before it is ready for any production use.

That is great, giving us time to work with it, on it, and plan is critical for a smooth transition into eventual production.

For us, having access to such an SDK is critical for product planning, staffing, and design/arch well before it is production ready. And vastly increases the likelihood that we will be able to contribute meaningfully to the development and testing.

Hey, I know you guys are busy and going in a lot of different directions, and don’t mean to be a pain, just want to be able to plan development & resources, the initial repo was supposed to open last week, then this week, and it’s not out yet, which is fine, I understand things like this happen at this phase, but what is a realistic date we can plan to have resources ready to up into this (knowing it is not production, but examining what exists and how we can integrate it and contribute to it, etc). Some larger plans around how we integrate temporal hinge on which SDK we choose and this directly impacts that as we assess which option will be the right one going forward.

We don’t expect NodeJs SDK to get to the production state in the near term. It can take quite a while to get that state. I wouldn’t recommend making concrete plans around that repository at least for quarter or two.

Sounds good. I wasn’t expecting a production build or even using it in production, but planning around just the development version being available, even having access to the repo in advance of any production work or planning can be helpful and we got a bit excited to even just see the work-in-progress as we architect prototypes, etc.

We’ll happily wait for whenever the time is right.

Hey @maxim ,

Is sdk-core production ready? Would it be reasonable to use that lib (and Rust in general) for my workers while I’m waiting for the typescript SDK? Or would you recommend the golang SDK?

1 Like

sdk-core is not production-ready and is under active development. sdk-core is intended as a core underlying library for language-specific SDK development. So it is not expected ever to be used directly by any application code. Rust SDK might be provided one day on top of sdk-core, but it will come after NodeJS and Python.

I would recommend using Go or Java SDK while waiting for TS.

Great, thanks for explaining that.

I’ve tried to find a cogent discussion of the differences between Go and Java SDKs and posed this question in a separate thread as we wait for the TS SDK, but assuming I had equal existing investment in Go and Java infrastructure, engineers, etc - what are the decision points between these two SDKs or are they largely the same (again, assuming engineers/infra within our company that is equally familiar with/invested in both platforms)?

Go SDK potentially scales better than Java one as it uses goroutines vs Java threads. But unless you need to cache very large number of workflows it doesn’t matter. So I would recommend choosing based on your language familiarity.

1 Like

BTW PHP SDK is another option.

1 Like

Also looking forward to this one!