y=1and see what happens.
@akashlal it did answer my question and question wasn't properly formed it was about how do you create actor for single task, but issue I created to Coyote repo and answer you added there also answered that with an example. I'm evaluation Coyote for our app company I work for is building. What we have is just normal app with with React UI and API similar to REST. It's going to be multi-tenant app where tenants can register them self. I'm just trying to get my head around how Coyote works and how could we integrate to it to our app.
I'm still having little bit of trouble understanding how would we write tests all those events we will be sending from our API controllers to actor runtime using Coyote tests. Those event classes might be coming from JSON deserialization. Example we might have CommentCreateEvent that would contain Text property that should not be null, empty or over certain length. Should we use Coyote randoms to init properties like that so they will randomly have any of null, empty, ok (a valid value) or over max length value?
We would also like to write permission and authorization checking system using actor model. Example if I send GetChannelEvent and it would contain current workspace id, channel id to get and current user Id, how could I have shared authorization code to check If sending GetChannelEvent for that specific channel id is valid for current user? I mean is the a way to somehow forward it to permissions checking actors first? In our current proof of concept app we use MediatR and we do permissions checking in it's pipeline.
I don't follow you authorization example. Decide first on breaking up the logic of your application into actors (e.g., one actor designated to do permissions-checking), then write the tests as if you are simulating a real workload through the system. In general, a coyote test can exercise multiple actors.
@lovettchris what I was thinking that we would write most of our app with Task based concurrency (using Coyote Tasks) and then write our caching system in same process using actors and Coyote Tasks would call into caching actor system in same process. Is this possible?
Note that you cannot use the above two programming models at the same time in the same process.
Makes me think it's not possible to do.
@Chobbly_gitlab Yes, 3.1 is coming. To quote @pdeligia
Regarding netcoreapp2.2, we plan to change to a netcoreapp3.1 target (which is LTS, https://dotnet.microsoft.com/download/visual-studio-sdks, 2.2 is now end-of-life)
@akashlal we will do proof of concept using only Coyote actors. I haven't designed anything before in this event based programming style so getting it right is not so easy.
We are using MediatR currently so going actor per request is pretty similar in that sense. Like having actors CreateUserActor and EditUserActor. These actors needs to check permissions that is user allowed to create or edit comments and other stuff. So I was wondering is StateMachine actor best for this? I was thinking request would have multiple states like Init, PermissionCheck, StoreToDatabase and Terminate (not sure if terminate needs to be it's own state). If I understood correctly I should do a monitor that would check that these request actors get terminated properly during tests? We need to add caching at some point so that caches N amount of users. So we should probably have UserStoreActor that would be a named actor "UserStore" and that would then handle caching of these users and start worker actors that will access database so it doesn't block. Are there any example projects even in another language that might help me with the design?
@wanton7 Try drawing a state machine on paper for your actors. If you can do it, then probably using the same design with StateMachine is a good idea. If you are unable to clearly identify the "States" of the state machine, then use a normal Actor.
You can consider using Monitors for checking high-level properties of your system, for instance, that the "work gets done" or "request is always completed". The fact that Actors are terminated properly is a more lower level-check, which is also useful. Start with a simple monitor and once you're comfortable with the testing, then write more sophisticated ones.