6
dUcKtYpEd
19d

Im learning ALOT about C# these few months because i believe diving into more strict typed languages is a requirement to be a more well seasoned dev. With my journey I am leaving a nice trail of C# complaints. This sums up my frustration with the language and set of libraries. Above is a C# websocket handling some json sent over the line. Below is a node.js snippet setting up the entire connection and handling the return. The C# snippet is a compilation of 8 different 3rd part tutorials that I pulled together to make work for me. The node snippet is straight from the packages documentation. The native node.js implementations documentation is even better than the 3rd party packages docs. I highlighted the portions of the C# code that frustrate me to no ends. Without copying and pasting from different examples that implement it in numerous different ways, how am I to know how to instantiate a buffer ? I need a result and a getBytes method. I dont need to go read RFC6455 and implement it step by step myself to make a websocket handler. I would like to think we have evolved to the point of offering simple websockets.

Comments
  • 1
    The handler protocol impl is SignalR

    The example is just binding an actual socket and giving you access to the underlying data stream. At that point the message protocol you're streaming is entirely up to you. Could be binary data, could be text, could be sanskrit.

    Node handles the serialization interp bits and prefers textual data, presuming http.

    https://dotnet.microsoft.com/apps/...
  • 0
    @SortOfTested I really dont want to use SignalR though. It sucks that its the only option cause i need my client to be entirely agnostic to how the server is handling websockets. I intend on using the native Websocket library not .net's SingalR js package. This is definitely more barebones usage of websockets but node just flexes hard on the fact that you can get a socket going with very little knowledge of anything other then the websocket paradigm
    https://pubnub.com/blog/...
  • 0
    @dUcKtYpEd
    All you have to do is define a general WebSocketMessage wrapper object with a property string|byte[] Data and a field string MessageType.

    Keep a dict of string -> Type

    Read the whole message to string, deserialized to WebSocketMessage.

    Grab the string body, get the corresponding Type from the dict using MessageType.

    Deserialize to T. Prolly 20 lines of code to a stable deserializable Middleware.
  • 2
    Ionno shit about csharp, but theres probably an easier way to do that, take this scala code for example
  • 1
  • 0
    @yellow-dog that java flow looks alot like the way node implements it. I like that
  • 0
    @SortOfTested thank you for the explanation. I would like to implement something like this but im having trouble finding any docs or tutorials that can walk me through. With being rather new to C#, these concepts are foreign to me.
  • 0
    @dUcKtYpEd its scala you cringe normie boomer -.-"

    But yeah scala is just java+js+fp, i think youd like it more than csharp
  • 0
    @yellow-dog gonna say, isnt it one of javas subsets
  • 2
    @dUcKtYpEd blocked and reported
  • 0
    @dUcKtYpEd
    Just to note, cask under Scala is also a framework.
  • 1
    @SortOfTested javax.servletsomething.websocket also uses annotations for callbacks, its not very far off from the standard implementation
  • 0
    @yellow-dog
    Def, just pointing out it didn't pass his metric either.

    At the end of the day, if we know the data is a stream of utf-8 chars, turning it from byte[] to a string is inconsequentially trivial in any language.
Add Comment