@wildanr C# 7 introduced the ability in switch statements to match on types and not just values, so your logic within a receive method can be a big switch statement matching on the type of each message you expect to handle

I am looking for some insight on weather I am painting myself into a corner or not. I am creating an actor that I think of as a "service". I want it to have a well defined public API. I do not wish to expose a set of messages that you can send the actor, I want to expose a set of operations you can try to run.

What I am currently thinking is exposing these operations as static methods on the same class that I am implementing my actor (basically a #region on the top of the file). I have one static method called Spawn that takes in the ActorSystem, plus arguments that are required for my Props. The other static methods, they all take in the ActorSystem, and, inside the (static) implementation, I do both the ActorSelection() and the necessary Tell/Ask depending on the guarantees I want to provide from my method. I got this inspiration from my interpretation of the "erlang way". I also desire to hide the internal akka messages that make the bridge from "outside the actor" to inside the actor (thus creating a clearer public API). What are your thoughts on this approach?

The other path I am exploring is hiding stuff behind interfaces, and injecting the ActorSystem into the constructor of the (only) implementation class. The feeling I get is that it feels kind of "muddy", because I am creating wrappers on wrappers. And I find it harder to keep my goal of hiding the akka messages that my actor accepts.. I seek your wisdom.

@wildanr The UntypedActor documentation does have a note about how the "Untyped Actor API is recommended for C# 7 users". I don't think this is implying "...instead of the ReceiveActor". The ReceiveActor inherits from UntypedActor (see code). The big difference between UntypedActor and ReceiveActor is how the user handles receiving messages. The internal (to Akka) logic is the same. If you prefer one method that handles all the incoming messages (aka "OnReceive"), use UntypedActor. If you prefer having that hidden and defining message handlers (aka "Receive<MyMessage>(...)"), use ReceiveActor.

You can disregard my question. When trying to write the tests for a controller (which is not related to having an actor system), the static implementation was starting to be on my way. So yeah, I created an interface to describe the service (which hides the ActorSystem), and an implementation that forwards the public API calls to the static public API of the actor. For now, I am happy with this.

@spankr thanks for your explanation. I'm just a little bit confused the first time I read it. Usually when something is recommended, there is another choice that is "less recommended". Anyway, thanks once again!

Getting this error when trying to start actor for listening The type initializer for 'DotNetty.Transport.Channels.DefaultChannelId' threw an exception. ---> System.Net.NetworkInformation.NetworkInformationException: An error was encountered while querying information from the operating system. ---> System.AggregateException: One or more errors occurred. (Could not find a part of the path '/sys/class/net/lo/mtu'.) (Could not find a part of the path '/sys/class/net/vinternal_25/mtu'.) (Could not find a part of the path '/sys/class/net/vtarget_13/mtu'.) (Could not find a part of the path '/sys/class/net/lo/mtu'.) (Could not find a part of the path '/sys/class/net/vinternal_25/mtu'.) (Could not find a part of the path '/sys/class/net/vtarget_13/mtu'.) ---> System.IO.DirectoryNotFoundException: Could not find a part of the path '/sys/class/net/lo/mtu'.

Shouldn't it be a lightweight process that can be easily instantiated to allow for general use of microservices? I don't see why it should be stateful given the ideology is that each actors does one simple thing.

actors are stateful by their very nature - this is one of the crucial concepts of that paradigm. Also actor system is a hosting environment for them - also works as a container and in cluster scenarios it's responsible to maintain connectivity with other nodes. So the cost of initializing actor system in some configurations may be higher than initializing a HTTP server.