# README
cameronelliott/janus-go
A Go language Websocket based package for controlling the Janus WebRTC gateway
Vision
I would like this library to be come:
- trusted
- stable
- reliable
For the purposes of controlling Janus in production environments.
Please join me by providing feedback and Pull Requests, praise, constructive criticism, whatever you like.
Prinicpals guiding the effort to make this super trustworthy and stable
- Be humble. I make mistakes, I invite and encourage your review and constructive critism on how to improve this lib.
- Use a number of articles and blog posts as guides for the prinicpals behind how this library works.
- Outline the techniques used to guide the code toward robustness and trustworthyness.
- Provide a real world example of usage.
Articles used to create the guidelines for stability and robustness
Why You Should Be Using errgroup... Blum
Managing Groups of Goroutines in Go. Block
Defer, Panic, and Recover/Gerrand
Notable packages
nhooyr/websocket: used for websockets, the big win here IMHO is context.Context which supports cancellation.
golang.org/x/sync/errgroup: may or may not be included on this package in the future, but can provide a very useful tool for propagating error values between goroutines and their creators.
Techniques used for the stability and robustness of this project
- Switch from github.com/gorilla/websocket to github.com/nhooyr.io/websocket, the reason being is that nhooyr.io supports context.Context for many websocket operations. This is a big win for reliable concurrency in many situations. See comment/link below about Google policy requiring use of context.Context
- Propagate all non-nil
error
s up the call stack, AND up the goroutine chain. This should mean no ignored, lost, swallowed errors. - Support the use of this package golang.org/x/sync/errgroup. This is how error values can be returned from goroutines to their parents. Links to articles about Structured Concurrency below.
- Writers to channels should use
defer close(channelx)
to close channels, especially where nested goroutine lifetimes occur. (Structured Conncurrency) - Use context.Context on call paths from Http requests (see google blog post below)
- Use a lint or static analysis tool to make sure there are no missed errors
- Use best practices for logging levels. Dave Cheyney has good articles on this.
Techniques not used
- Share by communicating,
this is a great approach for robust concurrency, but it requires more changes to the original than I am comfortable making. It would also break the API for existing code. So we are going to live with the mutexs and locking in the code.
Google blog post about usage of context.context inside request handlers
An old Google blog post said this about their policy about context.Context:
At Google, we require that Go programmers pass a Context parameter as the first argument to every function on the call path between incoming and outgoing requests. This allows Go code developed by many different teams to interoperate well. It provides simple control over timeouts and cancelation and ensures that critical values like security credentials transit Go programs properly. Go Google Blog
Credits
Original work by https://github.com/notedit In addition to this popular library, he has a lot of cool WebRTC related software, and stuff for the Medooze media server, another awesome SFU like Janus. Check his stuff out! :smile: