Documentation Discussion from slack

[rogeralsing]

@channel what part of the proto.actor documentation would you like to see improvement on, any specific areas?

1 reply
Today at 7:01 PMView thread

Troy Robinson 6:43 PM
definitely w/ asp .net core examples!!!

Roger:pa: 6:43 PM
meaning interactions between endpoints and e.g. cluster actors?
6:43
And SignalR <-> Actors ?

Troy Robinson 6:48 PM
Yes, SignalR would be awesome as well, but mainly how to use proto.actor in controllers if possible

Roger:pa: 6:56 PM
👍 We have that on our list for articles to produce
🙌
1

Jeff Ward 7:01 PM
replied to a thread:
@channel what part of the proto.actor documentation would you like to see improvement on, any specific areas?
@Roger - I have been digging into documentation hard for past 2 days and decided to join the Slack server to learn more.
I can definitely answer this!
You do a great job at describing how actors themselves work. Where I feel like it is lacking is:
For those of us who are not super savvy on actor systems, it is hard to see how the actors work into a greater systerm, even a simple REST API. I am unclear how to integrate Actors into a REST interface.
How to persist and retrieve data, such as GetAllProductsForUser(int userId). Coming from an Entity Framework background, and now going into event sourcing, its a bit unclear how I do this
Templates and starter projects for Microservices and other projects. (We are visual, this will help very very much!)
Inter-Actor messaging, do I need to use Azure Service Bus, RabbitMQ? or is this obsolete now?
External process execution examples (How do I send an email, or a ping to an external API - I know its trivial, but examples would be great)
Feel free to ping me about questions, I know i'll be pinging you guys with questions haha (edited)
👍
3

Jeff Ward 7:10 PM
@Roger super cool framework! I am building a multi-tenant microservice system for my own infrastructure. I have no dependencies and would like it to be as scalable as possible. The goal of the microservices is to have (25+ different micrservices - Reviews, User Profiles, Membership Subscription Products, Membership subscription memberships, Products, Digital Products, Video Digital Products, Image Digital Products, Order Management, Order History, Appointment Bookings, User Bank Information, User Credit Card information, Company Employee directory, etc...)
I was / am planning for each Microservice as actually a very tiny API versus a classic Stateful Microservice, each with its own SQL database and will use Entity Framework (I know with event sourcing EF may not be applicable) - the architecture would use the API gateway / orchestrator pattern similar to this here

I can do this pretty clearly using classic CRUD patterns + microservices. The idea is so that I can create X number of applications which consume a select sum of microservices to power the application (The microservices are building blocks that can be consumed by the applications)
I want it to be performant, scalable, and quick - previously I was looking planning on having the scalability to be handled by a combination of Azure Functions (Would end up being married to Azure...) and docker containers... Then I discovered you guys and Proto.Actor seems much easier to work with compared to Service Fabric or Akka.net itself.
I would love to integrate and use Proto.Actor for my infrastructure, but am unclear how the Actors work into the greater supreme ecosystem as I described above (if that makes sense)
Do you have any microservice examples or templates I can view and learn how to use Proto.Actor in a microservice architecture? (edited)

proto.actorproto.actor
Proto.Actor
Proto.Actor Website
👍
1

Roger:pa: 7:20 PM
@jeff Ward I would say there are two common approaches to services using Proto.Actor.
One approach is to have a cluster for a specific micro service, or rather for a sub-system.
where that sub-system lives on its own. say a telemetry processor for IoT. where actors are used for the parts inside that sub-system only.
This sub-system could ofcourse interact with other systems, using any standard mechanisms, say http/grpc/queues etc.
Another approach is to use a cluster for all your services, as Proto.Actor clustering is basically built around service discovery. meaning you could have some nodes hosting service A, and some other nodes hosting service B etc. and they can all know about eachother due to the service discovery.
Both works very well. I personally tend to favor the sub-system approach as it helps keep things more isolated
👍
2

7:20
But you are right, all of this needs to be documented and explained more in detail

Jeff Ward 7:25 PM
Thanks for the quick reply! I tend to think the same way as you, and keep things more isolated and abstracted to reduce the noise. Personally - I was thinking of also using your #2 option, in my mind each microservice would be its own cluster - however it might make more sense to toss them all in a single cluster.
I am scaffolding my infrastructure now for this, would love to incorperate Proto.Actor sooner rather than later (more difficult to later).
#1 -Is there any code or examples I can review for this? A clean architecture would be super cool
#2 -Do you think i'll end up opening a painful can of worms if I apply proto.actor globally as a pattern for all micrsoervices vs applying it on a case-by-case basis?
#3 - for your option #2, How would this work with an API gateway pattern?
#4 - I am big fan of distributed systems and documentation, I'd love to contribute to the documentation and aid of Proto.actor if I end up integrating proto.actor into the microservices (edited)

ivanpaulovich/clean-architecture-manga
🌀 Clean Architecture with .NET5, C#9 and React+Redux. Use cases as central organizing structure, completely testable, decoupled from frameworks
Website
http://paulovich.net/
Stars
2929
Added by GitHub

Roger:pa: 7:29 PM
#2 -Do you think i’ll end up opening a painful can of worms if I apply proto.actor globally as a pattern for all micrsoervices vs applying it on a case-by-case basis?
Using a single cluster for all your microservices, there are some concerns to keep in mind.
temporal coupling. using actors everywhere, might lure you to over-use RPC style messaging, just because it is easy to do. when you probably need queues/logs between some services. this can ofcourse be solved, but it is easy to get lazy if some easy to use feature is just right there
Technology coupling. even if proto.actor is crossplatform. you would still couple your service interactions to proto.actor itself. again. separating using queues/logs might be better
👍
2
🙌
1

7:30
as for contributing to documentation. see https://github.com/AsynkronIT/protoactor-website/labels/bounty-source%20%24%24%24
We offer $400 per written article on that list

Jeff Ward 7:31 PM
Very cool you have a list of articles to create, i'll check them out!
7:33
It sounds like the best option would probabaly to apply Proto.actor on a case-by-case basis, where it is needed to increase performance.
this can ofcourse be solved, but it is easy to get lazy if some easy to use feature is just right there
I love abstraction and write my own libraries to accomplish this regularly, i'd love to to tackle this, i am just newbie on actors / proto.actor and am learning how to do this. I'll dig into the documenation more and learn how this can be done!

Jeff Ward 7:41 PM
For multiple clusters, just to confirm I would have an API gateway that would summon Cluster A for XYZ and Cluster B for ABC. Do you have any examples of a multi-cluster implementation ?(My gut says this might be outside the realm of Proto.actor and is more-so a classic kubernetes service discovery question.. although not sure. ) I see you have ClusterGrainHelloWorld (many nodes per single cluster) , ClusterPubSub (single cluster PubSub example), KubernetesClusterHelloWorld (deploy single cluster with many nodes example).
I think your example KafkaVirtualActorIngress answers my question for multi-cluster implmentation
7:42
Thanks for all the answers and info! I know your busy, no rush in replying. Thanks for this very cool project, im excited to dig in

[rogeralsing]

Andreas 6 hours ago
additionally some parts are still unclear. Or I didn’t found

• when I need Remoting and when Cluster, What exactly the difference.

• Authorization and Authentication. How to ensure actor can’t call particular other actor, or is it not relevant? Or is it already implemented in GRPC?

• Multitenancy. How to separate messages from different tenants, for example in EventStream. My understanding create an ActorSystem per Tenant is a very bad idea because they will compete for system resources. How it’s right then?

• How to integrate actors into existing Aspnet.Core app. How to do DI properly, like create and dispose context for databases etc.

• Akka has some pages about patterns and antipatterns.

• How to configure clusters. Which parameters are existing regarding to this. Can I build heterogenous members (alike microservice), or should they be better equal.

• Some xml docs in code would be awesome. It’s not always obvious what the class or method argument is good for.

• Lists of possibilities, for example which Mailboxes are good for what, or which recovery strategies are to use when.

• Last paragraphs in the bootcamp are missing