1. Home
  2. Docs
  3. Infrastructure
  4. Camunda BPM Platform &#03...
  5. Camunda BPM vs Serverless TypeScript Functions

Camunda BPM vs Serverless TypeScript Functions

Camunda BPM excels in executing processes that require user (human) tasks, there is no question about it. However, for processes that are mostly or fully programmatic (Script Tasks and Service Tasks), you may ask: “Which one is the better approach: Camunda BPM or regular script/program?” Specifically since Lovia Team uses TypeScript as the default programming language, and serverless architecture:

Which one is better: Camunda BPM or Serverless TypeScript Functions?

Hendy Irawan
A fully automated BPMN process diagram.

Pros and Cons

ConcernCamunda BPMServerless JS/TypeScript Functions
Designer perspective
Visualized diagramYes, BPMN 2.0 diagramNo, code only
Integrates with User TasksYes, easilyNo (unless you call the function from Camunda)
PriceStarts from free (open source), up to EnterpriseStarts from free.
Lumigo starts from free, then $119/mo.
Serverless.com Cloud pricing at $20/developer/month.
Hendy’s note: After trying Serverless Cloud, I think Lumigo is better and has more monitoring features.
Passing environment variables and secrets
Pass environment variables by instanceRequires Camunda Docker container reconfigurationCan be done per-function basis
Pass environment variables by instance via AWS Parameter StoreRequires Camunda Docker container reconfigurationCan be done per-function basis
Read AWS Parameter Store directlyAccess AWS SDK using Camunda Script Task.
AWS SDK must be embedded inside Camunda BPM image.
The entire ECS Task for Camunda BPM must be launched with appropriate IAM Role for ECS Tasks.
Function must use AWS SDK.
Function deployed with appropriate AWS Lambda execution role.
Pass variables via HTTP request variablesYes, becomes process instance variablesYes, becomes query parameters or fields in request body
Technical ease-of-use
Scripting language/runtimeES5.1 JavaScript (Nashorn)TypeScript on NodeJS 14
Hendy’s note: AWS Lambda Web UI has good Cloud9-ish IDE support for editing Lambda functions, but only supports JavaScript, not TypeScript. It is similar to MongoDB Realm editor, but with better UI. However, you can’t easily sync with Git.
Ease of calling REST APIsModerate, using Jsoup (need to rebuild Camunda Docker image). Not awesome (no editor hints & autocomplete, no OpenAPI support), but not bad.Good, using Axios.
If needed, good support for OpenAPI code generation.
Ease of calling GraphQL APIsModerate, using Java GraphQL library. No editor hints & autocomplete.Good, using urql.
If needed, can generate type-safe urql client using graphql-code-generator.
Ease of codingUsing Inline Script -> Really bad: ES5.1 syntax is ancient, adding libraries is complex (requires rebuilding Camunda Docker image), accessing variables requires the execution.getVariable(…) syntax, JSON/XML must be parsed using Spin.
Coding in Java or Kotlin might result in better developer experience.
Good: VS Code editor support, serverless tooling (both local/offline and remotely), adding dependencies is straightforward with yarn add
Ease of debugging (developer-friendliness)Bad: even the syntax for logging with SLF4J is cumbersome to write as Inline ScriptGood: remotely with CloudWatch logs, and locally using normal logs
Observability of process variables (manager-friendliness)Good: using Camunda CockpitModerate: CloudWatch Logs is developer-friendly, however it is not meant for managers.
For better experience, send logs to Elasticsearch and viewing them with Kibana.
Middleware FrameworkNoneBase: Serverless Framework (either cloud dashboard or CLI)
Optional (monolithic style): NestJS, Middy
Starting/Triggering process instances
Start process instance by REST APIYes, POST /process-definition/key/{key}/startYes, via AWS HTTP API or REST API
Schedule process instance by timerYes, Timer EventsYes, run Lambda via EventBridge (does not require HTTP/REST API endpoint)
Start process instance by AWS SQSComplex, either:
1. embed Camel, then add AWS SQS Camel component, and route it to start a process instance
2. start a long-running dedicated Camunda process that uses AWS SDK to consume SQS queue, start the proper process, delay a bit, then loop
3. process SQS using AWS EventBridge then route it to as REST API call to Camunda
Yes, Lambda supports SQS natively.
Furthermore, Lambda supports batching, so the function can process multiple SQS messages at once.

Comparing Inline Script in Camunda vs. TypeScript Serverless Function Code

TypeScript gives much better developer experience

Scheduling Processes

The choices are: AWS EventBridge, Camunda, AWS Step Functions, or a combination of them.

AWS Lambda serverless functions can be triggered with AWS EventBridge, and for simple cases this may be sufficient.

For dynamic cases, AWS EventBridge may not be good.

For example, you may want:

  1. To run a “Review time logs” function at specific time on Monday through Friday.
  2. Instead of a single invocation, you want to run the function multiple times, each with different data (team members).

This can be tiring using AWS EventBridge. However, using Camunda, it is pretty straightforward as you can set timer event and have a logic for invoking the function. You will need to invoke the Lambda function using HTTP/REST API Gateway.

Alternatively, wrap the multiple invocations using a single function that calls the inner function internally.


Hendy’s conclusion is:

  • If you’re sure that what you want to do is fully programmatic, start with a TypeScript Function using Serverless Framework.
  • If you’re not sure, start by drawing the process as a BPMN diagram in Camunda Modeler.
    • Then identify the tasks, are they User Tasks or Script/Service Tasks?
    • If all of the tasks are Script/Service Tasks, it’s better to leave the BPMN diagram just as documentation, but not executable. And implement the process entirely using a TypeScript Function using Serverless Framework.
    • If some of the tasks are User Tasks, then it is good fit for executable BPMN process.
    • Find connected paths of Script/Service Tasks. By connected, meaning can have BPMN logic in between, but not separated by User Tasks or Events. Hendy recommends to merge these related Script/Service Tasks together and call it as a single Script/Service Task instead. That task can then be implemented as a Serverless Function.
    • To call Serverless Functions from Camunda BPM, it’s recommended to use AWS SDK (embedded within Camunda) and Run Lambda call directly, instead of using HTTP API. It is more performant, more secure (due to IAM Roles for ECS Tasks), less expensive, and easier to debug.

How can we help?

Leave a Reply

Your email address will not be published. Required fields are marked *