nats.io

[AndyPook]

Another client library for https://nats.io started at https://github.com/AndyPook/A6k.Nats

Nats has a super simple, mostly text based, protocol. So it's a nice example for Bedrock.
The "official" dotnet client is based on the go client. But has a lot of locks and is not really idiomatic c# inside.

A6k.Nats is really early stage, lots of things missing. But the basic pub/pub stuff works.
Any commentary on how it's using Bedrock, structs, ValueTask etc would be really appreciated.

One comment for @davidfowl and others close to corefx...
Even if the protocol bits of Bedrock do not make it into a Microsoft.* package... it would be really appreciated if some of the socket based bits already in there could be made public (or at least pubternal, if that's still a thing).

Having to cut/paste large chunks of stuff out to make a basic client work, just makes me feel a bit dirty 😃

[davidfowl]

@AndyPook there's a nuget package you can use!

https://github.com/davidfowl/BedrockFramework#using-ci-builds

[davidfowl]

BTW this looks awesome and is exactly the type of thing I want to see working with bedrock!

[davidfowl]

@AndyPook I'd really appreciate it if you could provide more feedback for any methods you'd like added to SequenceReader to make parsing easier or anything that can be added to the writing side of things to make it easier to write formatting code.

[AndyPook]

This kind of framework makes me happy. It's relatively easy/quick to "hide" all the nitty-gritty of networky stuff and actually level up to the thing you're actually trying to solve.

"feedback":
Make Bedrock.Framework just about the abstractions and "helpers"

• move Protocols.WebSockets elsewhere (Bedrock.Framework.WebSockets ?)

• move helper bits out of Experimental into Framework (ie helpers from Bedrock.Framework.Infrastructure)

• can Client/Builder now be factored in terms of ConnectionBuilder in corefx? (or removed all together?)

• it would be a-nice-thing if corefx exposed things like SocketConnection/DuplexPipe etc (ie Transports/Infrastructure) so we don't have to cut/paste them (Orleans has their own copies too).

For writing we always use something like NatsWriter (wrapper around a IBufferWriter< byte >) they're kinda like extension methods for writing the the things-your-protocol-needs (strings, numbers, blobs, json...)
I've tended to have some "standard" bits then use partial to add the bits I need for the protocol. So I'm kinda sharing a base type with cut/paste.
I wonder if there's some neater way of doing that? 🤔 though I can't see how, given how this works.

It does take a certain twist-in-the-brain to grok how to do stuff at this level. Some of the constructs/mechanisms like ref struct, really understanding where/why boxing or allocations might affect perf.... etc... is not something this dev is used to.
That's not "feedback" as such, just that you still need to do some learning to be able to do-the-right-thing.
But wow! so much "easier" with this (once you get it) than when I first tried to do an mDNS thing back-in-the-day

[davidfowl]

move Protocols.WebSockets elsewhere (Bedrock.Framework.WebSockets ?)

Why do you think this is important? Most of these pieces of code don't bring in any dependencies so why split it up into multiple dlls?

move helper bits out of Experimental into Framework (ie helpers from Bedrock.Framework.Infrastructure)

This makes sense. Actually some of these belong in the box somewhere.

can Client/Builder now be factored in terms of ConnectionBuilder in corefx? (or removed all together?)

Why? That's part of the opinionated DI enabled stack.

it would be a-nice-thing if corefx exposed things like SocketConnection/DuplexPipe etc (ie Transports/Infrastructure) so we don't have to cut/paste them (Orleans has their own copies too).

We'll finally get here in 6.0. .NET 5.0 has the client side, and kestrel will have a server implementation. DuplexPipe should be part of Pipelines (which is in the BCL in 5.0)

[AndyPook]

none of it is "important" :)
You're right the WS stuff is just-a-bunch-of-classes. I guess I'm looking for a set of parts to build clients/protocols. Having some other set of protocols in the package is a bit of a distraction. No biggie.

ConnnectionBuiler... more of a question really. But sure, it's just one opinion/style of many. I'm trying to get a grip on what moving parts I need to figure out and which I can just reuse and hoping for less copy/paste. A lot of these things "appear" to be very similar, just different naming. I'll need to spend more me in this space to really grok why some of these things can't be public/resusable.

I'll try to pay more attention to 5.0 see what I can get to "click"