What I built
Category Submission: COVID-19 Communications
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.
Demo Link
You can check the demo at https://party-hub.herokuapp.com/ (if it stops working I probably ran out of credits, my bad 🙈)
Link to Code
PartyHub
About
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
Requirements
- 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.
Setup
- Set the following environment variables (check Twilio's console)
- TWILIO_ACCOUNT_SID
- TWILIO_AUTH_TOKEN
- TWILIO_API_KEY
- TWILIO_API_SECRET
- Start database with
docker-compose up - Setup the project with
mix setup
Running
…How I built it
The stack for this project is a simple one:
- PostgreSQL
- Elixir/Phoenix
- Twilio's Programmable Video API
- JavaScript for some front-end magic, specially thanks to Twilio's SDK
- Bulma for CSS awesomeness
Thinks to consider when using Programmable Video API
You may consider a stream a single thing, but it's not
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.
Subscriptions are stateless
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.
Top comments (0)