Actor system that works alongside the functional framework Language-Ext
An issue with working with C# is that no matter how much of Language-Ext functional framework you take on-board, you will always end up bumping into mutable state or side-effecting systems. A way around that is to package up the side-effects into atoms of functional computation that are attached to the mutable state (in whatever form it may take). The Actor model + functional message handling expressions are the perfect programming model for that.
Concurrent programming in C# isn't a huge amount of fun. Yes the TPL gets you lots of stuff for free, but it doesn't magically protect you from race conditions or accessing shared state, and definitely doesn't help with accessing shared external state like a database.
| Documention | Description |
|---|---|
| Overview | A quick guide to the core features of the Process system |
tell |
Send a message to a Process - This should be your prefered mechanism for communicating with processes |
ask |
Request/response for processes - use this sparingly. |
| Publish / Subscribe | Mechanism for a Process to publish messages and state. Other processes can subscribe through their inbox or external systems can subscribe through Reactive streams (Observables). |
| Message dispatch | The power of any actor system, especially when it comes to a changing network topology is in its message routing and dispatching |
| ProcessId | Process address/location mechansim |
| Routers | A router is a Process that manage sets of 'worker' processes by routing the received messages, following pre-defined behaviours, e.g. Round-robin, broadcast, etc. |
| Dispatchers | Similar to routers but without the need for a router process, all routing is done by the sender |
| Registered processes | A sort of DNS for Processes, can also register dispatchers |
| Roles | A special type of dispatcher that's aware of the aliveness of cluster nodes and what their roles are |
Make sure you have the Echo.Process DLL included in your project. If you're using F# then you will also need to include Echo.Process.FSharp.
In C# you should be using static Echo.Process, if you're not using C# 6, just prefix all functions in the examples below with Process.
If you want to use it with Redis, include Echo.Process.Redis.dll. To connect to Redis use:
// C#
RedisCluster.register();
ProcessConfig.initialise("sys", "web-front-end", "web-front-end-1", "localhost", "0");"sys"is the 'system name', but easier to think of it as the name of the cluster as a whole. That means you can use a different value to point it at another Redis db (for multiple clusters). But for now it's easier to call itsysand leave it."web-front-end"is the role, you can have multiple nodes in a role and the role based dispatchers allow you to implement high-availability and load balancing strategies."web-front-end-1"is the name of this node, and should be unique in the cluster"localhost"is the Redis connection (can be comma separated for multiple Redis nodes)"0"is the Redis catalogue to use ("0" - "15")
Note, neither of those lines are needed if you're doing in-app messaging only.
| Nu-get package | Description |
|---|---|
| LanguageExt.Core | All of the core types and functional 'prelude'. This is the core framework that the Echo library is based upon. |
| Echo.Process | 'Erlang like' actor system for in-app messaging and massive concurrency |
| Echo.Process.Redis | Cluster support for the Echo.Process system for cluster aware processes using Redis for queue and state persistence |
| Echo.Process.Owin | WebSockets gateway into the Echo.Process system. Uses Owin to register the WebSockets handler. |
| Echo.ProcessJS | Javascript API to the Echo.Process system. Supports running of Processes in a client browser, with hooks for two-way UI binding |