Hi Ejaskhan As per my understanding, this approach will require your data source to run a HTTP server within itself (embedded web server) and I am not sure If it is a good design. It looks like you are trying to build a synchronous(client-server model) processing model in Flink. But Flink is meant for processing data asynchronously (streaming/batch). Can you elaborate on the use case which you are trying to address? What kind of processing are you planning to do in Flink?
Check If the following approach makes sense for your use case. Accept the events from HTTP client and persist the events to a data store (SQL/NoSQL) and publish the same to Kafka(topic)/RabbitMQ(queue). Let Flink data source listen to these topics/queues and update the status (SUCCESS/FAILURE) in the data store. If your clients are ok to see some lag in events, you can directly publish the events to Kafka(topic)/RabbitMQ(queue) without persisting it in the data store. Let Flink do all the processing and finally write to the data store. Thank you Raghavendar T S https://www.linkedin.com/in/raghavendar-ts On Wed, Feb 3, 2021 at 11:29 AM Ejaskhan S <iamejask...@gmail.com> wrote: > Team, > > It's just a random thought. > > Can I make the Flink application exposing a rest endpoint for the data > source? So a client could send data to this endpoint. Subsequently, Flink > processed this data and responded to the client application through the > endpoint, like a client-server model. > > Thanks > *EK* > > > -- Raghavendar T S www.teknosrc.com
