Zeebe integration with GraphQL

Hi,

We are a startup in the renovation field and we have a bunch of long-running business-processes which include calling various microservices (now we have around 20 of them) and external systems. We have our homegrown orchestration engine based on Kafka, but we are not satisfied with it and would like to migrate to something more standardized, with better monitoring, tooling etc. A few days ago I discovered Zeebe and it seems to be a good fit for us since we have some experience with BPMN both in development and business teams. However, I have some concerns, how seamlessly Zeebe can be integrated into our existing ecosystem:

  1. All our services are written in GraphQL (we have a GraphQL gateway which merges microservices schemas with Apollo Federation). As I see, Zeebe supports gRPC out of the box. What’s the best way to integrate GraphQL services with Zeebe are there any guides or examples?
  2. The second question is connected with the first one: suppose the call to GraphQL service failed with an error (so the HTTP code would be 200 but the response will contain an internal error code). Is there a way to show these errors correctly in the Operate tool and can I use incidents for that purpose?

Thanks

1 Like

Hi Nasushkov,

You need to write an adapter. I’m not sure how generic a GraphQL-BPMN architecture would be. Obviously you can standardise your own architecture, but I’m not sure how reusable it would be for others.

Things like error responses you would read the error code and fail the job in the Zeebe client lib in your adapter.

This article is a good resource: https://medium.com/holisticon-consultants/https-medium-com-zambrovski-distributed-orchestration-with-camunda-bpm-part-1-f03aa6d2b99f

And this recent discussion in the #zeebe-kafka channel in the Zeebe Slack: https://zeebe-io.slack.com/archives/CNS503HPX/p1578356255020200

They talk about REST and RPC over Rabbit MQ, but the principles are similar in terms of separation of concerns.

best,
Josh

1 Like

Hi Josh,

Thanks for the guidance! What do you mean by “adapter”? Should I write a special job worker for that purpose? Also, I’m a little confused with clients and workers. What’s the difference between them? In particular, here I see two clients for Node.js: zeebe-client-node-js and workit. The last one claims to be an “extensible worker for Node.js”. So what are the use cases for these two libraries?

Thanks,
Nikita

So, you work out how you map your GraphQL data to BPMN service tasks, and use a declarative pattern. And you implement the mapping semantics in a simple worker that needs the minimum amount of specialisation - ie: you don’t have to write a different worker for each service task type, it just does some generic transformation based on the payload / custom headers.

That’s an adapter - between BPMN service tasks and your GraphQL endpoints.

That adapter is written using two client libs - Zeebe and GraphQL. It talks to the Zeebe engine over gRPC and to the GraphQL endpoint(s) using gql.

Workit is a lib that allows you to write workers that can be switched between Camunda (using the external task worker pattern over REST) and Zeebe (using gRPC). It was developed by Ville de Montreal for forward-compatibility. They are on Camunda and wanted to develop their system so they can migrate to Zeebe in the future, by just changing a config setting.

1 Like