Phoenix Channels C# Client

Chat / Discussions
, ,
1

Hi all!

I’ve just shipped a C# Phoenix library, and wanted to share it here with some learnings…

Why even bother building another C# client?

Well, current ones I’ve seen either don’t support Unity, no longer maintained, or tightly coupled with certain a websocket dependency.

What problems will this new client library solve?

Prioritized based on my needs:

  1. Loose dependencies. (Inject your own Websocket lib)
  2. Statically-Typed, Maintainable, and easy to use. (It has a lot more types than JS lib)
  3. Unity compatible. (After all, I need to ship my phoenix-powered game!)
  4. Unit + Integration tests

Structural Changes to the JS Client

The JS client was “too smart” for me. It has loosly-typed APIs, and the code is super compact, which took me a while to really understand. That might be good for JS and an experienced Phoenix dev, but not for the uninitiated.

(An example is how the JS client doesn’t draw a distinction between sending events internally or externally. Both data flows leverage the recvHooks and bindings fields)

Instead, I’ve taken the time to break down everything so when you start looking at the code, the code reads as a client spec. A good example of that is how the phoenix messages are implemented:

  • The Message class encapsulating the parameters details “{event, ref, payload, topic}”.
  • InBoundEvents and OutBoundEvents enums, to distinguish [close, error, reply] from [join, leave], respectively.
  • There is also the Reply struct which represents the {status, payload} reply, so we can properly map it to the Push object.

Then, with all this static typing, the library greatly simplifies the mapping of messages, since it now knows about control messages which should be kept internal in the library, and external messages, which should be dispatched to the listeners.

What’s Next?

There is so much work to do! I haven’t had time to implement Presence, especially since I don’t use it in my game, but PRs welcome! Also, the library is currently pre-v1.0, since I’d love to hear suggestions on how to improve the APIs even further, and open to contributions.

… Last but not least … I do apologize for the coding style. I’m a Swift guy by trade, so I don’t know what C# people usually do :stuck_out_tongue:

11 Likes
2

I did C# since .Net 1, so I scanned through it and I think the C# code looks great! :smile:

Class and Method names are capitalized, local variables and private fields are pascalCased…the only change I would make is having the public properties/fields be PascalCased, thus differentiating between local variables/args and properties/fields. Also it is less common in C# to have the hanging indent-style curly braces, but I’ve seen some big projects that use that style like Caliburn if memory serves (framework by Rob Eisenberg, the dude behind Aurelia/Durandal).

So overall everything looks very consistent and clean from what I can see, so again, very impressive for not being a C# guy! :thumbsup:

1 Like
3

Thanks for the detailed feedback!

What do you think about _privateField convention, is that the norm as well? Do private functions need a differentiation as well?

1 Like
4

I personally used _PrivateField because it worked with snippets. Nowadays maybe you can dynamically change a snippet’s variable first letter casing. So I would have for property notified change properties, e.g.:

private string _MyProp;
public string MyProp
{
  get { return _MyProp; }
  set 
  { 
    if (value != _MyProp) 
    {
      _MyProp = value;
      NotifyPropertyChanged(value);
    } 
  }
}

Disclaimer: That’s from memory anyway (I’ve been doing only JS/TS/Elixir for the past year or two) and I’m on my phone! :wink:

I think I would use four spaces but on my phone I’m doing two…yes, here is an example of a more fully fleshed base class property. :smile:

1 Like
5

Cool!

I’m using https://github.com/jfis/dn-phoenix with some tweaks. And I do found there are some JS stuff does not fit into C# world. Glad to see a client not translated line by line from JS. Here are some of my changes:

  • The Timer does not play well within UnityEditor, so I removed the auto reconnect code, let the game decide what to do
  • Added Push.Receive<T>(string, Action<T>)
  • Also added shortcuts Push.Ok , Push.Timeout , Push.Error

Best HTTP looks useful, will also check it.

1 Like
6

Those are some excellent notes!
I’ve had the same issues you described, the timer issue was especially
annoying.

In my library, I make sure to clean all timers when you call disconnect.
So, even in my game, I always call disconnect and use my own coroutine
based retry logic.

The generic variant of receive looks very useful. I think it will be a good
addition.

Feel free to open issues or submit PRs when you find the time :smiley:

7

Hate to resurrect this thread but is this still something you are actively working on?

8

@AlejandroHuerta Yup! My game is still in production, and the library is still actively maintained.

9

Ah that’s great to hear. So you have any plans for the c# upgrade in beta? Such as async/await?

10

Not yet, that will have to wait until unity officially rolls out support for those features.

11

Wont be waiting very long as 2017.1 is in beta and scheduled to release in July with support for it. Anyways I’m glad you’re still supporting your library. Seems to be the only one still being actively worked on.

12

That’s great news, I had no idea!! Better start working on it then :wink:

13

I’ve been using your library, @Mazyod, with BestHTTP and it’s been working out great so far in local development. I’ve debated using the official .NET implementation of websockets, perhaps later. I’ve also wrapped your library to be able to use async/await. Is there anything you need help with to convert to .NET4.5+?

1 Like
14

Awesome, glad to hear it’s been treating you well! :smiley:

Honestly, I just didn’t prioritize the migration, since Unity will only release an experimental version of 4.6+ support. If you can help out, that would be awesome!

The main good thing to be covered is the SynchronizationContext, to remove the need to plug in a callback handler, and synchronize everything with the main thread within the library instead.

Right after that comes the support for async/await, for nicer APIs to handle the replies and whatnot. I’m not sure yet how asyc/await can work with different results, like “ok”, “error”, … etc, but could be a fun challenge to design properly.

15

Yeah I understand. I’ve run into some bugs with 4.6 profile so far.

SynchronizationContext is already set up for us so as soon as you call await it’s implicitly captured by Unity’s context. As for the return value the way I handled it is by essentially returning your Reply class and handling the status myself. Not sure there’s a better way to design that.

I’ll see if I can write up a PR this month.

1 Like