Real World Examples?

[chabad360]

The Ergo model is very interesting to me, and I would like to try building some stuff in it. But as someone who's completely unfamiliar with the methodology, it's really unclear how exactly certain things are supposed to work within this model. Stuff like database access (do I want to have a pool that sits in front of a meta-process? wait, I need a regular process to run the meta process, and how do I handle errors? Do I need to have a result type?), or API access (am I supposed to have a meta-process for the connection and then call into it?). Point is, I don't think these are going to be the only questions I run into, it took me a few hours to grok how stuff is supposed to get composed together, and I still have yet to figure out how to actually build stuff in this (and I'm pretty sure I'm not stupid).

Basically, this is a long-winded way of saying that having an example application(s) that has some degree of complexity would make it a lot easier for me (and I imagine a lot of other people) to learn the patterns here (which seem to be somewhat different from traditional Go).

[halturin]

Basically, you just need to understand the actor model itself. Its a bit different way of thinking :)

To work with DB, you do not need to use meta-process. It was created to work with things that require keeping read/write handler running (TCP socket, for example) while the actor handles messages sequentially.

Think of your program design as a nano-service architecture in which actors are services that communicate to each other by message passing.

[chabad360]

To work with DB, you do not need to use meta-process. It was created to work with things that require keeping read/write handler running (TCP socket, for example) while the actor handles messages sequentially.

Most databases I know of, you communicate with them over the network with a long lived TCP connection (often a pool of said connections). Not sure what exactly is different here?

[chabad360]

what can i say, you didn't read the documentation

I did, numerous times, over and over. But after an additional reading, it's pretty clear I didn't do enough reading on the Actor Model. I'm doing that now. So... Fair enough.

However, none of that changes the fact, that instead of looking at some Go code and getting an intuitive understanding of how things want to work. I'm stuck either reading code in languages I'm not familiar with, or reading lots of articles.
If you have any suggested resources I should consult, feel free to drop them.

I think if I'm successful in wrapping my head fully around this, I will try to contribute some form of example application.

[halturin]

I was expecting Call and HandleCall to pass the error without terminating the called actor

From the documentation

For synchronous requests, the HandleCall callback method is invoked in an actor based on act.Actor. The result returned by this method is sent as the response to the request.

To stop a process, simply return a non-nil error value from the message-handling callback. After termination, the Terminate callback method will be called, with the reason argument being the returned error value.

https://docs.ergo.services/actors/actor

[halturin]

Most databases I know of, you communicate with them over the network with a long lived TCP connection (often a pool of said connections). Not sure what exactly is different here?

a huge difference. Working with DB you don't need to keep reading from the socket. You just send your request, receive the answer. That's it.

The main idea with actors is to quickly handle received messages and return from the callback.

[halturin]

forgot to mention... there is a trick. if you really want to get the error as a result of Call request you may use SendResponseError of gen.Process interface. In this case, you have to return nil, nil in your HandleCall callback.

But I wouldn't recommend to use this way since error for Call method implies the request has been delivered and handled by the actor. any there - for the result of such handling according to the business logic and could be literally anything - a value, or an error.

[Capybara-1]

As the original poster mentioned, I also want to understand actor-based solutions for databases like MongoDB or Redis. Should operations on the database be handled like other actors using Call or Send for synchronous or asynchronous data retrieval, or is it better to use global functions in the traditional Go way?

[Capybara-1]

I'm curious whether Ergo can also implement a similar Actor Pool approach to replace the aforementioned spawn --> receive model?

sure, you can use act.Pool for this approach https://docs.ergo.services/actors/pool

Wow, that’s exactly how I also implemented it!

I previously tried using the code you mentioned to implement database operations, but I feel that in scenarios with many requests, a single actor can impact overall performance.

[Capybara-1]

I'm curious whether Ergo can also implement a similar Actor Pool approach to replace the aforementioned spawn --> receive model?

sure, you can use for this approach https://docs.ergo.services/actors/pool`act.Pool`

Wow, that’s exactly how I also implemented it!

I previously tried using the code you mentioned to implement database operations, but I feel that in scenarios with many requests, a single actor can impact overall performance.

However, during the process of using the pool, I encountered a problem: it cannot automatically set the RegisterName for each worker in the pool. I'm wondering if there will be an optimization in the future to assign a RegisterName to each worker in the pool.

[halturin]

yeah, act.Pool helps you to distribute the load.

[halturin]

However, during the process of using the pool, I encountered a problem: it cannot automatically set the RegisterName for each worker

no need. register the name of your act.Pool process and use this name in your Call requests. see the docs.

[Capybara-1]

yeah, act.Pool helps you to distribute the load.

Currently, the way I assign the RegisterName to workers is by getting their parent's RegisterName and then adding a random value. This approach isn't very intuitive.