GraphQL and All Javascript Team

We have a 100% Javascript team and would like to use Camunda! I know it can be done but looking for latest guide. In particular we are using BFF(Backend For FrontEnd) so facade service and we want to access Camunda via GraphQL schema. Any information on GraphQL Schema and its maturity? Is it always up to date with latest Camunda etc? Also what are persistence options for workflow information in Camunda? MongoDB, PostgreSQL etc? What version of Camunda do you recommend if we are going to access via GraphQL? Appreciate a prompt response as we are finalizing a design soon for rapid development.

This is certainly possible and there are a few different ways of doing it. for backed stuff you can either use script tasks or you could use external tasks written using the JavaScript Client.

For frontend - you can use embedded forms or you can just create an independent back that connects the engine over network.

Camunda doesn’t support this officially but there is a GraphQL community extension that you can look at. I don’t know much about it’s usage since it’s maintained by the community, so you’ll need to do your own investigation.

When would you choose script task over external tasks written using Javascript Client? Whats the main difference there?

For Front End we are using VueJS connecting to Facade service (BFF Backend For Front End) do you know how could connect this to the Comunda Engine. I think the schema GraphQL is for the client to BFF so BFF has the GraphQL schema. It can in turn call rest api.

There are a few different ways the most common works as follows:
You can just use the REST API to query for tasks - each task can have a key contained in the form key section of the task and you can use that to link it with the page you want to display. Once the user has finished you would once again use the rest api to complete the task.

Are those tasks also defined in Javascript? Like an external Javascript task can be queried via the rest api?

Tasks are created as part of a BPMN model that is generated by using the Camunda Modeler and deploying that model to the engine.

Ok, but you mentioned external tasks implemented using Javascript client and also the script task? Are those implementations of the task? and the modeler defines them?

If you want to run some kind of backend javascript code you would create a service task in the camunda modeler, that task would be defined as an external task with a topic name.

Then you would independently build a javascript worker that subscribes with that topic to the engine. It could then fetch and do work

ok, thanks. And what’s the relationship between a Javascript worker and what you mentioned earlier either use script tasks or you could use external tasks written using the JavaScript Client.

Script task need to be local and need to be deployed to the engine with the model, it makes it harder to version them and also makes them harder to test.

External tasks are over network, so easier to scale in some cases, easier to maintain and version.

So I think we will go with external tasks. Is external task more or less the same as the javascript worker described above?

Yup, external tasks are an implementation type in which a javascript worker can be used to do it.
This tutorial video will give you an idea of how it work.

Perfect. Our whole team will take a look at this. Sorry about so many questions but we are moving very rapidly on BPM selection and implementation.

Any advantages to embedded forms? We want to use VueJS. And what I have seen for embedded forms indicates Angular more supported. In any event which do you think is more flexible? And what data does forms address specifically? Task data? Process data?

GraphQL community extension is far from complete and not up to date. I’d recommend using it only when team also includes a Java developer, who could either contribute to it or customize it to your needs. We started using the extension, but ended up forking it to have the features we needed.

That said, as we were able to learn some Java while doing this (and continue to learn), we have been able to continue with Camunda (although, still very much in development – with small pilots running). We have ReactJS frontend and Hasura GraphQL as BFF (because we wanted to have unified GraphQL API for Camunda, PostgreSQL tables and custom APIs).

For us, bpmn-js ecosystem has been equally important. We use it both for visualizing the process state and parsing user tasks with form definitions.

output

1 Like

Side note, would recommend typescript vs js in workers.

“It depends.”

The “official” nodejs external task client is not written in typescript yet.

But most of my use cases involve calling external APIs with OpenAPI specification. I prefer being able to generate type definitions from OpenAPI specification and relying on those types while writing the clue code.

Yes, it’s a preference. If ts is new for your team then sure.
In case you do consider ts all you need to is types.

It’s plain and simple with better dev speed/quality/runtime surprises…

1 Like

Agreed. I stand corrected.

1 Like