Hello, I am new to actor systems and would like to ask a question. What are the best practices for handling database queries (synchronous or asynchronous) using actors? For example, when receiving an API endpoint request, I want the actor to go to the database and return a response message with the data. What is the best way to implement this?
@@Stannardian Hi! This is more of a general question (although I'm not very familiar with the async / await or .PipeTo() part either). Should I just send messages that will be converted by the "database-handler" actor into plain asynchronous database queries? Is this the right way to do it?
@@zkWarrior I'd keep the db queries async and maybe put an actor in front of the query handler if you want to do things like limit the number of parallel database requests / open connections at any given time. The other reason for maybe having an actor responsible for this is so you can avoid having to spread DbContexts et al around to lots and lots of actors who might need database access. My $0.02
@@Petabridge Thanks for the reply! I'll try to experiment with that and maybe will check out some vids on the channel just to know more of the technical stuff.
Hello, I am new to actor systems and would like to ask a question. What are the best practices for handling database queries (synchronous or asynchronous) using actors? For example, when receiving an API endpoint request, I want the actor to go to the database and return a response message with the data. What is the best way to implement this?
Is the question on how to do the async / await portion of this or just how data access should look, generally, when using actors to facilitate this?
@@Stannardian Hi! This is more of a general question (although I'm not very familiar with the async / await or .PipeTo() part either). Should I just send messages that will be converted by the "database-handler" actor into plain asynchronous database queries? Is this the right way to do it?
@@zkWarrior I'd keep the db queries async and maybe put an actor in front of the query handler if you want to do things like limit the number of parallel database requests / open connections at any given time. The other reason for maybe having an actor responsible for this is so you can avoid having to spread DbContexts et al around to lots and lots of actors who might need database access. My $0.02
@@Petabridge Thanks for the reply! I'll try to experiment with that and maybe will check out some vids on the channel just to know more of the technical stuff.