What are limitation of temporal Nodejs sdk compared to Golang or Java

Community Support
1

We are planning to use temporal & most of our code is in typescript. We would like to know the limitation of node sdk or implications of using it as its in alpha phase.
#nodejs-sdk

1 Like
2

Hi,

We’re preparing to release the beta version of the Node.js SDK, this version should have a fairly stable API and should be ready for production, it will be missing these major features:

  • Workflow testing framework
  • Side effect and mutable side effect
  • Local activities
3

By when do you expect the beta version to be available? And is there some project/PR/issue on GitHub or elsewhere that we could monitor for progress?

4

We’re getting really close, I would estimate a matter of few weeks, you can follow the progress here: https://github.com/temporalio/sdk-node/issues?q=is%3Aopen+is%3Aissue+milestone%3Abeta

5

Are these features not possible (easily done) in Typescript or you just haven’t got around to implementing them as yet? Could we expect them in the future some time?

Thanks,
Ashley.

6

We’ve already started working on local activities and the other features are coming up.
We’re quite certain that our next pre beta release will include the bulk of the api changes based on user feedback.
We are planning an official launch next month in our online community meetup.
Will be happy to see you there.
Details will be published on our community slack.

1 Like
7

Thanks @bergundy

I’m attracted to Typescript because it looks simpler to write than Go, or any of the other languages supported, at least from the snippets of code that I have seen.

What would you suggest is the best language / SDK to make development as quick and simple as possible (e.g. clear code)? Assuming Typescript SDK fully functional…

I am a developer who is not tied to any particular programming language and for this project I need speed and simplicity (e.g. clarity of business processes in code).

8

Hi, I’m thinking about not relying on the SDK for targetting language but in general, a way to do IPC with other services. So what I mean is the wrapper for activities, workflows can be implemented using Go SDK, but then within the methods are some calls to internal services. Is it possible to do so? Is there any risk for this (I’m quite new to the engine)?

In other perspectives, are there any pros to use the SDK in a specific language? I can see some on maintainability or reusing skillset in team. However imo, the workflow engine would mean to be abstract/general enough to integrate into the system.

9

IPC route is fine for activities. Workflows should not make any external calls directly.

In other perspectives, are there any pros to use the SDK in a specific language? I can see some on maintainability or reusing skillset in team. However imo, the workflow engine would mean to be abstract/general enough to integrate into the system.

It is mostly about skillset of the team and the existing libraries activities call into.

1 Like
10

As Maxim noted, it’s very dependent on the team that is meant to maintain the Workflows.
Some orgs use multiple languages while others use only a single language.
I’ve also heard from a user in Slack that they plan to let frontend engineers prototype workflows in TypeScript which would later be ported to Golang and maintained by data / backend engineers.