Orchestrator (like Camunda) between frontend and backend?

Question

I have the following use case. We have both a frontend application and a backend application. Earlier, events on the frontend application directly call the backend application. Now we want to introduce an orchestrator (like Camunda or similar in-house product) between the frontend and backend applications. Following will now be the sequence of events.

1. User clicks on the button in frontend application. This action is part of a workflow graph and the next node in the graph linked to this button click action is to call the related backend API.
2. This button click instead of directly calling the related API in backend calls another API that sends a message to a kafka topic.
3. The orchestrator is listening to this kafka topic and executes the next node in the workflow graph to call the related backend API.

Questions

1. Is this a correct use case for introducing an orchestrator or the previous method of directly calling backend itself was fine?
2. For introducing an orchestrator between the frontend and backend applications, are the steps mentioned above correct or there is a better way?
3. Many a time, we need to show the response of the backend API in the frontend. How can that part be handled when the orchestrator is added and the flow mainly becomes asynchronous?

Edit: 4. If the workflow is as follows

user_task_1 => call_API_1 => user_task_2 => call API_2

Both user tasks are button clicks on the frontend application used to manage an entity. When the first button click or user_task_1 happens, a new workflow instance is created. The status of this workflow instance is user_task_1_completed for now. Later when the user_task_2 which is again another button click on the frontend application is completed, how can we retrieve this workflow instance? Just with the entity ID, we can’t retrieve the workflow instance ID as there could be multiple button clicks or workflow instances for the same entity. Is it right to add the workflow instance IDs in the frontend application or there is some better way?

Answer 1

In short

Using an even orchestrator between the frontend and the backend looks to me like catching flies with a steamroller: it seems at first sight a rational and efficient idea but turns out to be a heavy solution that does not bring the expected benefits.

More arguments

The problems

The approach described would tightly couple user interface to the event-api of the orchestrator. Experience shows that this is hard to maintain. This is why MVC architecture emerged in the first place: view and controller handle the UI and model the backend, thus a sound separation of concerns.

The front-end would moreover be bound to the availability of the network and might suffer from low network performance. Imagine: the user clicks on that button, nothing happens, clicks again and again, gets click-mad, ultimately resulting in ten time the same event passed, the same event processed, the same reply received, just amplifying the poor perceived performance. (Don't forget that when you're local in the frontend it's at nanosecond level, whereas event processing via kafka will bring you in the milisecond range.)

Lastly, orchestrators are more designed for backend orchestration (business workflows/events) than front-end orchestration (UI elements).

The solution

If you nevertheless want go that way, consider at least using an MVP-like paradigm on your frontend: the UI communicates with a local layer (misleadingly called "presenter" in MVP) that transforms user input into commands (very suitable for events) and queries (could also be well implemented with pub-sub like approach of kafka). It would nevertheless keep front end reactivity, inform users when network is lost, filter repetitive actions that just repeat an event that was just sent etc...

Personally, I'm not sure the performance will fit, but this depends a lot of the kind and number of events at your frontend, the number of concurrent users and of course the fine tuning of the architecture. Keep us posted with your experiment ;-)

.

Answer 2

Firstly, I think rather than using React, you can use Camunda or a workflow tool to call the API from backend and as mentioned in the above you can try using MVC type of architecture to do same. You can easily achieve your case that way. You can still achieve this in your particular approach but that will be making this whole process quite complex.

Secondly if you still want to go ahead with your current on the click of button you need to invoke a instance in orchestrator toll and that workflow id can be used by service to determine the changes done by that particular action.