Hi there,
We are exploring Temporal as a solution. Is a Node/Typescript SDK on the roadmap?
Thanks,
Jeremy
Hi there,
We are exploring Temporal as a solution. Is a Node/Typescript SDK on the roadmap?
Thanks,
Jeremy
Yes, it is on the roadmap and it is a pretty high priority. But we don’t have any specific dates yet.
Great, thanks for the response.
Do we have Node/JavaScript available (NOT Typescript)?
@maxim Any update to report? I see the proposal for a Node client in the repo. I’m also interested in the managed offering, is it possible to find more information about it?
We are planning to open the repo later this week.
Contact @ryland about the cloud offering.
Temporal definitely should be developed in typescript for type safeness, reliability but don’t worry, that’s going to be compatible with JavaScript. Typescript is just superset of JavaScript, during compilation it is bundled to plain JS.
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?
We already released sdk-core that NodeJS uses internally. We are planning to release the sdk-node later this week.
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!
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.
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.