This is PartyHub, the place where all your parties will happen! At least while we are all in quarantine :/
Here you can create a party or visit any of the other ongoing parties. The first one to come will be that party's designated DJ. All other party-goers can choose to share their own video and choose who's video they see.
You can check the demo at https://party-hub.herokuapp.com/ (if it stops working I probably ran out of credits, my bad 🙈)
PartyHub is a video sharing app designed for parties. You can join any ongoing party or start it yourself, you can choose to share your video, and you can choose who to watch.
Fill free to try the DEMO while credits last.
What to expect on the future
This are a couple of features on the roadmap that will improve the party experience, but sadly for time constraints (yeah, my bad) haven't been implemented:
- Group chat with selected people
- Automatic DJ substitution
- private parties
- Elixir 1.10.2 (with Erlang/OTP 22)
- Docker and docker-compose
- A Twilio account and API key/secret - sign up
Note: If you plan on deploying this remember to use HTTPS or otherwise browsers won't allow media features.
- Set the following environment variables (check Twilio's console)
- Start database with
- Setup the project with
The stack for this project is a simple one:
- Twilio's Programmable Video API
- Bulma for CSS awesomeness
If you are like me, when you thing of a video stream you just think of one stream of data, but when using this API you'll quickly find out that's not the case. On the basic case you are presented with an audio stream and a video stream (there is also data stream, but let's ignore it). On API terms, they are called tracks and they are independent. Why is this important? Because SDK events like trackPublished will trigger twice, so if your handler isn't idempotent you'll start to see things happening twice.
Disclaimer: as mentioned above audio and video are to separate things, but for simplicity I'll grouped them with the word track.
On of the first things that bit me was how the subscriptions worked. Subscriptions are how the Twilio's API handles if you should get some track, for that they use rules (filters) to choose. The thing about rules is that the API don't manage their state, you can't remove, push, pop, append, or do any action over the existing ones. You need to send them the rules as you want them, nothing more nothing less.
The solution I solution I came up with, without having to persist anything to a DB for simplicity and time, was to manage the state of the rules on the front-end and just use the back-end as a proxy. It will receive the rules, add some default ones that everyone has, and send it off to the API. Later when the user is subscribed to new tracks it will get an event through the SDK.