Aaronontheweb on dev
Fix #4083 - Endpoint receive bu… (compare)
type FunPersistentActor2<'Message>(actor : Eventsourced<'Message> -> Effect<'Message>, recovery) = inherit FunPersistentActor<'Message>(actor) override __.Recovery = recovery let propsPersist2 (receive: Eventsourced<'Message> -> Effect<'Message>, recovery) : Props<'Message> = Props<'Message>.ArgsCreate<FunPersistentActor2<'Message>, Eventsourced<'Message>, 'Message>([|receive,recovery|])
How to store this data correctly?
I'm going to store only Guid and amount of the item
Also I'm going to have a Resolver that keeps the description of each item (by Guid)
But everytime when player is asked about item, it needs to resolve it first (the same for shops). This will probably create a huge load for Resolver..
I can create a PersistentActor for each item with the PersistentId = Guid. Then I can get this actor by Context.ActorSelection("../Guid") , how about performance here?
The projections can be used, but the parameters of the item I need in a lot of different places, will this work?
Can you suggest the best practice for such scenario?
@cgstevens I almost feel like the two are on slightly different layers... Akka.NET with clustering can act as sort of a service mesh, but it looks like Istio is a higher level of abstraction.
IMHO, from an architectural standpoint Istio looks like it does a lot.... possibly too much. That's an opinionated statement, but concepts like Authentication should be handled at the API Gateway level and not at a service mesh level.
(Broader opinionated statement) I'm always careful of libraries/frameworks that are backed by massive corps like Google/IBM (and even MS; see: EF). They have a lot of organizational/process strength to enforce rules that go with making large frameworks work well. Smaller shops, it's often a very difficult battle.
OTOH, This has been re-hammered into me because I'm on a team with only 4 devs in the entire company right now. ;_;