Our tech stack is React.js with GraphQl. We are thinking about creating our our tasklist application to display Camunda tasks in our application and allow users to interact with the forms (mostly external forms) from our application.
I know that the out of the box tasklist is based on Angular. I am curious if anybody has experience with working with Camunda and React?
I would love to know what potential pitfalls we might run into based on the fact we use something other than Angular? For example, would we experience issue with some of the out of the box controls… such as the Process Overview or history or human task Forms?
I know we can use the Rest API to query/interact with the Camunda engine. Do most people call the Camunda REST API via server to server communication or it mostly done client side… especially when integrating into another application? From an architecture design point of view, would you recommend wrapping the required REST API calls into GraphQL at the server level?
take a look at granate.
It lets you annotate your GraphQL schema to easily integrate with existing REST backends - in this case the Camunda REST API. Within short time (20 minutes) you can connect to Camunda via GraphQL.
granate comes with GraphiQL, the famous GraphQL GUI.
For my little Camuda example it looks like this:
For people who do not know GraphQL: In the above screenshot you see on the top left side your editable query and on the top right side the answer from the Camunda server. There is lots more in there…
Starting today I try to answer the question: how can we quickly generate GraphQL schemas (in the screenshot it the lower part) as a textual representations (schema language) out of existing REST backends. How can we partially automate that process to improve the GraphQL implementation speed.
BTW, our tech stack includes React
If you get your GraphQL-Server running which then talks to the Camunda REST API - like in this example - you must not bother with a specific GUI library / framework (e.g. Angular). You can use React “naturally” with GraphQL.
GraphQL is an abstraction layer. It hides the Backend (or many backends if you wish). The GUI-developer must not know the technical backend implementation details nor the REST API. The GUI-developer works only with the GraphQL schema and creates specific queries to fullfill the needs of a specific GUI. GraphQL has lots of advantages…
Maybe I should write a whole Blog Post about this integration, as it is a great improvement for lots of people writing GUIs with non-trivial data.
Thank you so much for sharing. This is exciting to see and I want to try it out.
Do you have a simple public repo to show some Camunda specific examples?
Also you mentioned that your app uses React. Would you mind sharing any experiences your team has working with React and Camunda? I am interested in learning about some of the Camunda tasklist js components and how easily they would plug into a React container.
@Greg_Svitak are you planning to have another backend other than Camunda? If you are just using Camunda, then you will want to look at the Authorization capabilities in Camunda and very likely want to extend them for more extensive permissions.
For forms your will want to look at another Form generator tool that would replace camunda Tasklist’s Embedded Forms. This is fairly trivial to.
If you are going to persist your data in another system and use that other system as the primary endpoint and camunda is just a behind the scenes system, then interacting with Camunda is really more of a System to System interaction rather than a direct front-end client question.
We are planning on using Camunda for mostly a backend routing engine. The a good portion of the data will be stored in our application’s database. We plan on sending just enough of the data to the process engine as process variables to allow the routing to happen.
The forms used in the tasks will either be external forms that we design for a specific business process or a generic form created via forms.io.
However I want to create a React components that will basically be able to display some of the Angular task list components such the process definition flow, and the history tab on any process form. Additionally we might want to be able to execute human tasks that are configured for certain processes.
Any suggestions about the above architecture… especially with React?
I too look for a similar solution. Did you integrated the camunda workflow with the react application? Is there a way we can extract the form details or the form itself through rest api and use it to the render in the react application.
Thank you for your prompt reply. Graphql extension you pointed is really useful but it is just replacement for the rest api calls isn’t? I wanted to know how to create the forms dynamically in my react SPA and seamlessly integrate it with the camunda workflow user tasks.
I don’t have clarity in it. I thought of storing the form.io or any such json in any nosql db with the key as form key.
Use the camunda rest api to get the form key for the current user task in the running process instance
Use the form key to retrieve the form json from the db
React form io component can renderer the form from the json in the SPA
Is this will work?
I have another doubt too. When I proposed this idea to my UI team they were not convinced saying that the forms may not as simple as I can render in form io. It could be complex. I’m yet to the see such scenario but if this situation comes how to handle it? How to make the camunda user task and complex UI which isn’t aware of the camunda user task to talk seamlessly? How to bridge these two pieces?
Everything you need about the sequence flow of steps between a “forms validation servicer”, the SPA, and Camunda are all there, working examples, Repos with OSS code, Angular SPA examples, screenshots, etc.