Hello everyone, With the new release, the worker has been separated from the backend. My goal is to run a flow as an API and spin up a worker container solely responsible for handling that flow [Flow As A Microservice]. Could you guide me through the necessary code areas that need changes to achieve this? [Aside from running a worker container instance and calling the flow as an API]

Hello @moesaleh welcome to the server, do you mind telling us more about your use case? So just to understand this correctly you want a single worker instance to handle one specific flow only ? and the rest of the flows can go to another flow totally ?

Hello @Abdul (Viva-Palestina)💔 , Thank you for responding. I am the CTO of SwanBlocks (https://swanblocks.io/), one of the first startups utilizing the ActivePiece Technology Stack and ecosystem. Our platform bridges the on-chain (Web3) and off-chain (Web2) worlds, among other features. I wanted to express my admiration for your product, and the team behind it; it’s fantastic. I believe ActivePiece has immense potential, not only as a Zapier alternative but as a no-code backend-as-a-service where each flow functions as an API. This is exactly what we’re doing for our first client. Our first client is a SocialFi (Decentralized Social Network) with 50,000 users. They provide a Web2 experience in a decentralized fashion, with every post, comment, and piece of content stored in decentralized storage via SwanBlocks. Additionally, they tokenize everything (content, courses, short movies, masterclasses, etc.) through NFTs. We have already achieved this using the AP platform and SwanBlocks features, leveraging flows as backend APIs. The next step is to use ActivePiece as a microservice orchestration platform. We need to treat a specific high-frequency flow as a microservice from an architectural perspective, running it in its own container with a dedicated worker to handle and execute only this flow efficiently.