Client server article #17
Conversation
|
|
|
Hi @glopesdev I would like to update the zeromq to the new docs theme but there's this article that hasn't been merged in yet, can you review and merge it in before I do the update? |
|
@banchan86 @RoboDoig now that the docs infrastructure has been updated, it would probably be best to rebase this PR and build off that. There is no immediate rush though, just leaving this here as a note. |
RoboDoig
force-pushed
the
client-server-article
branch
from
3a18a02 to
fde25b4
Compare
|
I've done the rebase, I'm just going to run through and check that all the steps still work with the current version of ZeroMQ. Please hold off on merging until then! |
|
@banchan86 @glopesdev all looks good now |
|
Note to self: svgs not required anymore, test locally with build script and delete the svgs |
|
@glopesdev @banchan86 in the docs build script, should the argument for Export-Image here be pointing to the artifacts\release folder? |
|
@RoboDoig It should, this was my mistake when I updated to the new artifacts build layout. I will create a new PR soon to both fix this along with introducing separate member pages. |
Use separate member pages and remove unused docfx config properties
|
@banchan86 - would you like it to be moved to a new Tutorials section at the top-level (e.g. Manual, Reference, Tutorials) or a Tutorials subsection in the Manual (along with Recipes)? |
|
Note to self - replace references to 'node' with 'operator' |
|
@banchan86 - thanks so much for your suggestions! I've updated the PR with these changes. |
Are there future tutorials planned? I think the way we have done it with the other docs is to have a new The changes look good to me! One other thing I noticed is that the last section of |
|
I definitely have ideas for other tutorials but no immediate plans to write them up. My feeling is that even if there is only one tutorial it would be nice to stay consistent with the main bonsai-rx documentation so it's a bit more intuitive to navigate. |
|
@banchan86 - Added a separate tutorials section |
There was a problem hiding this comment.
Did an initial review of the first half, will need to digest more to finish it! Left some initial comments if you want to work on it if not can wait till I finish my review. One thing I did notice though was that the PR history looks a bit weird, not sure if you want to fix it for a cleaner PR history before adding more commits. Looks like some of the commits were repeated.
|
|
||
| We had to change quite a few things to modify this workflow so let's step through the general logic. The first thing to note is that since we are avoiding the [`SendResponse`](xref:Bonsai.ZeroMQ.SendResponse) operator in this implementation we need to pass messages directly into the [`Router`](xref:Bonsai.ZeroMQ.Router). To do this we generate a [`BehaviorSubject`](xref:Bonsai.Reactive.BehaviorSubject) source with a `NetMQMessage` output type and connect it to the [`Router`](xref:Bonsai.ZeroMQ.Response) (can implement this by creating a [`ToMessage`](xref:Bonsai.ZeroMQ.ToMessage) operator, right-clicking it and creating a [`BehaviorSubject`](xref:Bonsai.Reactive.BehaviorSubject) source). This will change the output type of the [`Router`](xref:Bonsai.ZeroMQ.Router) operator from a `ResponseContext` to a `NetMQMessage` so we need to make some modifications to how we process the stream. | ||
|
|
||
| We want the [`Router`](xref:Bonsai.ZeroMQ.Router) to generate a reply message every time it receives a request from a [`Dealer`](xref:Bonsai.ZeroMQ.Dealer). Since we are now building this message ourselves instead of using [`SendResponse`](xref:Bonsai.ZeroMQ.SendResponse), we branch off the [`Router`](xref:Bonsai.ZeroMQ.Router) with a [`SelectMany`](xref:Bonsai.Reactive.SelectMany) operator. Inside, we split the `NetMQMessage` into its component `NetMQFrame` parts, taking the `First` frame for the address, using [`Index`](xref:Bonsai.Expressions.IndexBuilder) to grab the middle empty delimiter frame and creating a new `String` which we convert to a `NetMQFrame` for the message content. We [`Merge`](xref:Bonsai.Reactive.Merge) these component frames back together and use a [`Take`](xref:Bonsai.Reactive.Take) operator (with count = 3) followed by [`ToMessage`](xref:Bonsai.ZeroMQ.ToMessage). The [`Take`](xref:Bonsai.Reactive.Take) operator is particularly important here as 1) [`ToMessage`](xref:Bonsai.ZeroMQ.ToMessage) will only complete the message once the observable stream is completed and 2) We need to close the observable anyway to complete the [`SelectMany`](xref:Bonsai.Reactive.SelectMany). Finally, we use a [`MulticastSubject`](xref:Bonsai.Expressions.MulticastSubject) to send our completed message to the [`Router`](xref:Bonsai.ZeroMQ.Router). |
There was a problem hiding this comment.
Consider a step breakout for this paragraph too.
There was a problem hiding this comment.
I've split this into a step breakout for the actual construction and left this paragraph as explanation as it's probably the bit that benefits most from more detailed breakdown of the logic.
This PR contains an article added to the ZeroMQ docs that describes the construction of a workflow running a simple client-server network architecture.
Loosely related to issue #15.