Mazyod
Phoenix Channels C# Client
Hi all!
I’ve just shipped a C# Phoenix library, and wanted to share it here with some learnings..
https://github.com/Mazyod/PhoenixSharp
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:
- Loose dependencies. (Inject your own Websocket lib)
- Statically-Typed, Maintainable, and easy to use. (It has a lot more types than JS lib)
- Unity compatible. (After all, I need to ship my phoenix-powered game!)
- 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
Messageclass encapsulating the parameters details “{event, ref, payload, topic}”. InBoundEventsandOutBoundEventsenums, to distinguish[close, error, reply]from[join, leave], respectively.- There is also the
Replystruct which represents the{status, payload}reply, so we can properly map it to thePushobject.
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 
Most Liked
ibgib
I did C# since .Net 1, so I scanned through it and I think the C# code looks great! 
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! 
Mazyod
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?
ibgib
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! 
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.
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"