Forem: Amin Arria

Sponsorly: Manage Your Newsletter's Sponsors

Amin Arria — Mon, 11 Jan 2021 03:12:43 +0000

What I built

I built a web service called Sponsorly. It allows you to manage your newsletter sponsors.

You will generate a unique URL you can share with possible sponsors that will allow them to sponsor an issue of your newsletter.

Also, for sponsors, they can create an account an keep track of their sponsorships.

Category Submission:

Built for Business

App Link

sponsorly.aminarria.tech

Screenshots

Onboarding a new user that has newsletters

Creating a newsletter

Seen issues available for sponsoring

Sponsoring an issue

List of sponsorships to confirm

Description

The app has to types of users: Creators and Sponsors.

Creators are the ones that have newsletter and need sponsors. They create a newsletter and generate a unique URL to share to possible sponsors. Generally issues for a newsletter are automatically generated by the app, but in case its needed they can be created, edited, or deleted by the user.

Once sponsors have sent sponsorships for an issue they can be reviewed and one of them confirmed for that issue. In case it's needed a confirmed sponsorship can be canceled.

When seen the issues for a newsletter you will be able to filter by:

Confirmed: issues that have a confirmed sponsor
Pending: issues that are pending a confirmed sponsor
Past: issues that already have been published

On the other hand we have Sponsors. They access newsletters through the URL generated by a Creator and select an issue to sponsor.

One particularity about Sponsors is that they don't need an account, the app will just ask for an email when creating the sponsorship request instead.

After making a sponsorship request they can register using that mail (or any other time really) and any sponsorships they have will associate to their account.

Link to Source Code

AminArria / sponsorly

Manage your newsletter's sponsorships

Sponsorly

Requirements (versions used)

PostgreSQL 12.3
Elixir 1.11.2 OTP 22
NPM 7.0.10

Local Development

First fetch dependencies

  mix deps.get

Fetch NPM dependencies

  npm install --prefix assets/

For the database you can use docker-compose with our docker-compose.yml file that sets it up. Otherwise you need to create a user named sponsorly_user with password sponsorlydevelop, give permission to create a database, and run mix ecto.create.

Then we have to run the migrations

  mix ecto.migrate

Last, we start our Phoenix server

  mix phx.server

Now you can visit localhost:4000 from your browser.

Deploying

For deployment we are using releases in a Dockerfile.

Part of using releases is moving the configuration to releases.exs which runs on startup instead of compilations as the other configs. This allows us to have set everything at runtime and not worry about secrets leaking to the world (or at least not so easily).

The following are the…

View on GitHub

Permissive License

MIT License

Background

The idea for this submission came from Cassidy Williams.

On one of her streams she started mentioning that an issue she has with here newsletter is managing sponsors. Some of the problems where:

Keeping track of current sponsored issues
Issues available for sponsorship
Doing all this manually for each and every sponsor
Payment

So I emailed her about using her idea, she gave me the OK, and here we are 😁.

How I built it

(How did you utilize DigitalOcean’s App Platform? Did you learn something new along the way? Pick up a new skill?)

To build this project I use my day-job stack:

PostgreSQL
Elixir/Phoenix (maybe I'll use LiveView)
Bulma

It's nothing fancy, but it gets the job done.

To deploy the project I created a Dockerfile which I then deployed using DigitalOcean's App Platform.

For the deploy to work (and since I had the free credits) I decided to use DigitalOcean's Databases to create a managed PostgreSQL instance.

And that's it! Now Sponsorly is deployed and ready for everyone to use.

Hope you enjoy it 😁

My First Deploy

Amin Arria — Sun, 27 Dec 2020 20:58:11 +0000

So I was a bit curious about how DigitalOcean's App platform worked so I decided to add basic authentication stuff and deploy it, but I wanted to have email confirmation as well so I did a small detour to setup that as well using.

User authentication

Rule 1: Never do your own authentication

This is one of those live rules that you just have to trust and besides, why reinvent the wheel?

For authentication I'm using Phx.Gen.Auth a new authentication system generator for Phoenix. The main difference from authentication libraries you find is that this is a generator and not a library. This means that it generates all the code that it needs and inserts it into your project (as if written by you).

Why use it? Well basically I have two reasons: 1) I wanted to try it out. 2) I always end up having to dive deep into how to customize other libraries workflow because there's an edge case I need to handle so way easier to handle if its just code in my project.

One small modification I had to do was adding the logic to ask for email confirmation before allowing to sign in. Thankfully this was sort of easy thanks to comments like this in the generated code:

@doc """
Used for routes that require the user to be authenticated.

If you want to enforce the user email is confirmed before
they use the application at all, here would be a good place.
"""
def require_authenticated_user(conn, _opts) do
  ...
end

Email library

For emailing related stuff I decided to use my usual choice of library Bamboo. For mail service I decided to give Postmark a try after some recommendations (and changes to Mailgun's free trial).

Postmark was a bit extra complicated to setup because it doesn't allow public domains emails such as @gmail.com for sign up. I had gotten a free year for a .tech domain recently so decided to setup mail forwarding to my email from it and sign up with that. So after that small detour it was about the same as other mail providers I've used.

Bamboo let users create abstractions called Adapter to have a common interface. For my non-production environments I'm using Bamboo.LocalAdapter which just prints the email and for production Bamboo.PostmarkAdapter

Deploying

Now to the important part: deploying to App Platform.

Since neither Elixir nor Phoenix are natively-supported I need to add a Dockerfile to my project so it can run. Also, I had to do some changes to use Elixir's releases and use environment variables at start-time instead of compile time. Thankfully all this (including a demo Dockerfile) is explained in Phoenix's documentation: Deploy with Releases.

Next, still no deploy (sorry), I went ahead and a managed database cluster (1 node ja) so my app could connect to it. Why not use the dev database they offer? Well because the credits they gave out expire in 60 days so no point in not trying all the cool stuff they have.

Now finally I have a deployed app: https://sponsorly.aminarria.tech/

"Deploy to DO" button

This was very direct:

Went into my app's settings in DO and downloaded its spec
Created a deploy.template.yaml following the documentation and seen what was in my spec.
Add the button to my README

Although for this to work properly, mainly because of the Postmark requirement, I made a small change so the Bamboo adapter can be changed to the local one using a environment variable USE_LOCAL_ADAPTER = "true".

And that's it! I have a bare-bones app deployed and that you can deploy with the click of a button (and some config of environment variables)

A Sponsorship Manager for Your Newsletter

Amin Arria — Mon, 14 Dec 2020 10:59:06 +0000

What is a "newsletter sponsorship manager" you say? Well, think a scheduling/appointment app, but for your newsletter's issues and their sponsorships slots.

The Roadmap (I hope so)

The following will serve as a high-level roadmap for the features that will exist.

The application will have 2 set of features, 2 types of users:

Creators (people that have a newsletter)
Sponsors (people/companies that want to sponsor a newsletter issue)

For our Creators we need the following:

Specify interval of newsletter issues (this to automatically create availability)
Create one-off issues
Define amount of sponsors per issue (might allow only one for v1, related sponsor slot tiers)
Unique link to your newsletter "calendar" for sharing (think Calendly)
Receive payment
Sponsorship confirmation step (maybe only for first-time sponsors)

For our Sponsors we need the following:

Sponsor an issue (duh)
Send copy
Track sponsored issues
Send payment

There is one extra feature that I would love to build, but might be a bit too much for the duration of the hackathon and my time constraint, but maybe I can do it.

What I want is an automatic way to detect when an issue is sent and update the information (and maybe notify the sponsor). For this I'm thinking about a special email address they can add to their mailing list and then detect the sent issue.

Tech Stack

The stack used its going to be something ~~boring~~ simple:

PostgreSQL
Elixir/Phoenix (maybe I'll use LiveView)
Bulma or Tailwind (haven't decided)

AminArria / newsletter_sponsorships

Newsletter Sponsorships Management

NewsletterSponsorships

To start your Phoenix server:

Install dependencies with mix deps.get
Create and migrate your database with mix ecto.setup
Install Node.js dependencies with npm install inside the assets directory
Start Phoenix endpoint with mix phx.server

Now you can visit localhost:4000 from your browser.

Ready to run in production? Please check our deployment guides.

Learn more

Official website: https://www.phoenixframework.org/
Guides: https://hexdocs.pm/phoenix/overview.html
Docs: https://hexdocs.pm/phoenix
Forum: https://elixirforum.com/c/phoenix-forum
Source: https://github.com/phoenixframework/phoenix

View on GitHub

Don't stop the party, PartyHub

Amin Arria — Fri, 01 May 2020 02:46:30 +0000

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

AminArria / party_hub

PartyHub, videoconference for your parties

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

…

View on GitHub

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.

Scalable Broadcasting Using WebRTC

Amin Arria — Thu, 14 Mar 2019 01:24:44 +0000

The Idea

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

Our idea is pretty simple: use WebRTC to create video broadcasting (1 user sends video to N users). For this we will first look into how to design it, create a proof of concept, and finally implement it in Erlang.

WebRTC Problem

As you may know, WebRTC uses a peer-to-peer connection to transmit video. This works incredible for one-to-one calls or even for small group calls.

The problem is we are building a broadcasting feature, this means that there could be 100, 1000, or even 7 billion users connected. So if we try using WebRTC as is, this means the broadcaster will have to establish that many peer connections and send to each one the video he wants to broadcast. So, unless the broadcaster has a lot of CPU power and bandwidth to spare it will crash and burn trying.

How can we solve this issue? Well, all of our research gave us the same basic solution: broadcaster sends video to a central server and this server sends it to all listeners, been the central server the one with the CPU/bandwidth burden. Sounds simple, right? Well unfortunately doing this using WebRTC is not that simple, because it is meant to be peer-to-peer. This means that we can't simply create a central server and relay the video to the clients.

Solution

Janus is a WebRTC Server developed by Meetecho conceived to be a general purpose one. As such, it doesn't provide any functionality per se other than implementing the means to set up a WebRTC media communication with a browser, exchanging JSON messages with it, and relaying RTP/RTCP and messages between browsers and the server-side application logic they're attached to. Any specific feature/application is provided by server side plugins, that browsers can then contact via Janus to take advantage of the functionality they provide.

Great! We have something that looks like can solve all our issues regarding a central server using WebRTC, but before declaring this "the cure to all diseases" we decided to create a PoC to check two things:

Verify that broadcaster/listener WebRTC connections behaved as expected (only one per peer to Janus).
We could use Janus without its Javascript library.

Why focus on not using Janus's JS library? Well because we plan on using our backend as a wrapper for all things Janus. Saving frontend from having to deal with Janus's extra complexity.

Making the PoC

Now the first hurdle in this new journey: Creating a JS client for Janus. Looking into the demos and documentation we found out we needed to use the video room plugin.

First things first, Janus works by creating a session to identify clients and a handle (sort of a session inside the session) to interact with a specific plugin, so let's create them:

function start_session() {
  msg = JSON.stringify({'janus': 'create', 'transaction': 'create_session'});
  janusConnection.send(msg);
}

function start_handle() {
  msg = JSON.stringify({'janus': 'attach', 'transaction': 'create_handle', "plugin": "janus.plugin.videoroom", 'session_id': sessionId});
  janusConnection.send(msg);
}

IMPORTANT: Janus websocket uses the sub-protocol janus-protocol in JS is just another argument, but in case you need it, you set it in the header Sec-WebSocket-Protocol field as per RFC 6455

Next thing is for our broadcaster to create the room, join it, and start broadcasting:

function make_room() {
  msg = JSON.stringify({janus: 'message', transaction: 'create_room', body: {request: 'create'}, session_id: sessionId, handle_id: handleId});
  janusConnection.send(msg);
}

function join_room_publisher() {
  roomId = parseInt(roomInput.value);
  msg = JSON.stringify({janus: 'message', transaction: 'join_publisher', body: {request : 'join', ptype: 'publisher', room: roomId}, session_id: sessionId, handle_id: handleId});
  janusConnection.send(msg);
}

function start_broadcast() {
  peerConnection = new RTCPeerConnection(CONFIG);
  peerConnection.onicecandidate = on_ice_candidate;
  peerConnection.ontrack = on_track;

  navigator.mediaDevices.getUserMedia(CONFIG).then(function(stream) {
    localVideo.srcObject = stream;
    peerConnection.addStream(stream);

    peerConnection.createOffer().then(function(offer) {
      peerConnection.setLocalDescription(offer);
      msg = JSON.stringify({janus: 'message', transaction: 'publish', body: {request: 'publish'}, jsep: offer, session_id: sessionId, handle_id: handleId});
      janusConnection.send(msg);
    });
  });
}

As you can see we have started using WebRTC, its important to know that Janus responds to the publish request with the WebRTC answer in the jsep field. Also, by default Janus includes the ICE candidates inside the SDP, you can change it to send them using trickle, but for this PoC it was fine as is.

That's pretty much it for the broadcaser side of things, just two things missing (sending ICE candidates and keepalive), but will talk about them later as they are the same for broadcasters and viewers.

Now, the viewers. We already have the session and handle taken care so we just only need to go into the room and start receiving the feed from the broadcaster. To do this two things we need: the room ID and the feed ID for that broadcaster. Why is there a feed ID? Well because Janus doesn't impose an actual limit on number of broadcasters, you can set it when creating the room.

function join_room_subscriber() {
  roomId = parseInt(roomInput.value);
  feedId = parseInt(feedInput.value);

  peerConnection = new RTCPeerConnection(CONFIG);
  peerConnection.onicecandidate = on_ice_candidate;
  peerConnection.ontrack = on_track;

  msg = JSON.stringify({janus: 'message', transaction: 'join_subscriber', body: {request : 'join', ptype: 'subscriber', room: roomId, feed: feedId}, session_id: sessionId, handle_id: handleId});
  janusConnection.send(msg);
}

function join_subscriber(payload) {
  peerConnection.setRemoteDescription(new RTCSessionDescription(payload.jsep));
  peerConnection.createAnswer().then(function(answer) {
    peerConnection.setLocalDescription(answer);
    msg = JSON.stringify({janus: 'message', transaction: 'blah', body: {request: 'start'}, jsep: answer, session_id: sessionId, handle_id: handleId});
    janusConnection.send(msg);
  });
}

So now that broadcaster and viewer side of things are done let's send our ICE candidates:

function on_ice_candidate(event) {
  msg = JSON.stringify({janus: 'trickle', transaction: 'candidate', candidate: event.candidate, session_id: sessionId, handle_id: handleId});
  janusConnection.send(msg);
}

One final, and important, thing missing is the keepalive. Janus by default will terminate any session that doesn't send any request in 60 seconds. Remember, sessions and websockets are different things.

function keepalive() {
    msg = JSON.stringify({janus: 'keepalive', transaction: 'keepalive', session_id: sessionId});
    janusConnection.send(msg);
}

So after all this we have a working PoC for our broadcast using Janus :D

The Project

First of, dependencies:

Erlang (we worked with OTP 21).
Docker and docker-compose
Cowboy: to handle the client-server websocket connection.
websocket_client: to handle the server-Janus websocket connection.
jsx: JSON decode/encode, all our websockets communicate using JSON.

Let's start by creating a module in charge of server-Janus communication, janus_handler.erl:

-module(janus_handler).

-behaviour(websocket_client_handler).

-export([init/2,
         websocket_handle/3,
         websocket_info/3,
         websocket_terminate/3,
         start_link/1]).

start_link(From) ->
  Opts = [{extra_headers, [{<<"Sec-WebSocket-Protocol">>, <<"janus-protocol">>}]}],
  websocket_client:start_link("ws://localhost:8188", ?MODULE, From, Opts).

% Websocket Handler
init(From, _ConnState) ->
  {ok, #{from => From}}.

websocket_handle({text, Msg}, _ConnState, State) ->
  DecodedMsg = jsx:decode(Msg, [return_maps]),
  process(DecodedMsg, State).

websocket_info(create_session, _ConnState, State) ->
  Msg = jsx:encode(#{janus => create, transaction => create_session}),
  {reply, {text, Msg}, State};

websocket_info({create_handle, SessionId}, _ConnState, State) ->
  Msg = jsx:encode(#{janus => attach,
                     plugin => <<"janus.plugin.videoroom">>,
                     transaction => create_handle,
                     session_id => SessionId}),
  {reply, {text, Msg}, State};

websocket_info({create_room, SessionId, HandleId}, _ConnState, State) ->
  Msg = jsx:encode(#{janus => message,
                     transaction => create_room,
                     body => #{request => create},
                     session_id => SessionId,
                     handle_id => HandleId}),
  {reply, {text, Msg}, State};

websocket_info({join_publisher, SessionId, HandleId, RoomId}, _ConnState, State) ->
  Body = #{request => join, ptype => publisher, room => RoomId},
  Msg = jsx:encode(#{janus => message,
                     transaction => join_publisher,
                     body => Body,
                     session_id => SessionId,
                     handle_id => HandleId}),
  {reply, {text, Msg}, State};

websocket_info({join_subscriber, SessionId, HandleId, RoomId, FeedId}, _ConnState, State) ->
  Body = #{request => join, ptype => subscriber, room => RoomId, feed => FeedId},
  Msg = jsx:encode(#{janus => message,
                     transaction => join_subscriber,
                     body => Body,
                     session_id => SessionId,
                     handle_id => HandleId}),
  {reply, {text, Msg}, State};

websocket_info({send_offer, SessionId, HandleId, Offer}, _ConnState, State) ->
  Msg = jsx:encode(#{janus => message,
                     transaction => send_offer,
                     body => #{request => publish},
                     jsep => Offer,
                     session_id => SessionId,
                     handle_id => HandleId}),
  {reply, {text, Msg}, State};

websocket_info({send_answer, SessionId, HandleId, Answer}, _ConnState, State) ->
  Msg = jsx:encode(#{janus => message,
                     transaction => send_answer,
                     body => #{request => start},
                     jsep => Answer,
                     session_id => SessionId,
                     handle_id => HandleId}),
  {reply, {text, Msg}, State};

websocket_info({trickle, SessionId, HandleId, Candidate}, _ConnState, State) ->
  Msg = jsx:encode(#{janus => trickle,
                     transaction => trickle,
                     candidate => Candidate,
                     session_id => SessionId,
                     handle_id => HandleId}),
  {reply, {text, Msg}, State};

websocket_info({keepalive, SessionId}, _ConnState, State) ->
  Msg = jsx:encode(#{janus => keepalive,
                     transaction => keepalive,
                     session_id => SessionId}),
  {reply, {text, Msg}, State}.

websocket_terminate(_Reason, _ConnState, _State) ->
  ok.

% Internal
process(#{<<"transaction">> := <<"create_session">>,
          <<"data">> := #{<<"id">> := SessionId}}, State) ->
  Msg = #{session_id => SessionId},
  send_msg(Msg, State);
process(#{<<"transaction">> := <<"create_handle">>,
          <<"data">> := #{<<"id">> := HandleId}}, State) ->
  Msg = #{handle_id => HandleId},
  send_msg(Msg, State);
process(#{<<"transaction">> := <<"create_room">>,
          <<"plugindata">> := #{<<"data">> := #{<<"room">> := RoomId}}}, State) ->
  Msg = #{room_id => RoomId},
  send_msg(Msg, State);
process(#{<<"transaction">> := <<"join_publisher">>,
          <<"plugindata">> := #{<<"data">> := #{<<"id">> := PubId}}}, State) ->
  Msg = #{publisher_id => PubId},
  send_msg(Msg, State);
process(#{<<"transaction">> := <<"join_subscriber">>,
          <<"jsep">> := Offer}, State) ->
  Msg = #{jsep => Offer},
  send_msg(Msg, State);
process(#{<<"transaction">> := <<"publish">>,
          <<"jsep">> := Answer}, State) ->
  Msg = #{jsep => Answer},
  send_msg(Msg, State);
process(#{<<"janus">> := <<"ack">>}, State) ->
  {ok, State}.

send_msg(Msg, #{from := From} = State) ->
  From ! {reply, Msg},
  {ok, State}.

You might wonder what that From stored in State is, well at the end it will correspond to the process handling the client-server websocket connection. That way we establish a one-to-one relationship between the two processes and they can pass requests/responses one to another.

Since we plan our server-janus connections to be established on-demand let's create a supervisor for them and add it to our app's (janus_erlang_wrapper) supervision tree.

-module(janus_erlang_wrapper_sup).

-behaviour(supervisor).

-export([init/1,
         start_link/0]).

-export([]).

start_link() ->
  supervisor:start_link({local, ?MODULE}, ?MODULE, []).

init([]) ->
  JanusSup =
    {janus_sup, {janus_sup, start_link, []},
     permanent, infinity, supervisor, [janus_sup]
    },
  {ok, {{one_for_all, 10, 10}, [JanusSup]}}.

-module(janus_sup).

-behaviour(supervisor).

-export([create_janus_connection/0,
         init/1,
         start_link/0]).


start_link() ->
  supervisor:start_link({local, ?MODULE}, ?MODULE, []).

create_janus_connection() ->
  supervisor:start_child(?MODULE, [self()]).

init(_) ->
  JanusHandler =
    {janus_handler, {janus_handler, start_link, []},
     transient, 5000, worker, [janus_handler]
    },
  {ok, {{simple_one_for_one, 10, 10}, [JanusHandler]}}.

Great! Now we can dynamically establish connections from our server to Janus and communicate with it. Final step will be to create the API our clients will use, for this we create a websocket handler for Cowboy:

-module(ws_handler).

-export([init/2,
         websocket_handle/2,
         websocket_info/2,
         websocket_init/1]).

init(Req, State) ->
  {cowboy_websocket, Req, State}.

websocket_init(State) ->
  {ok, State}.

websocket_handle({text, Msg}, State) ->
  DecodedMsg = jsx:decode(Msg, [return_maps]),
  process(DecodedMsg, State);
websocket_handle(_, State) ->
  {ok, State}.

websocket_info({reply, Msg}, State) ->
  EncodedMsg = jsx:encode(Msg),
  {reply, {text, EncodedMsg}, State}.

% Internal
process(#{<<"request">> := <<"create_session">>}, State) ->
  {ok, JanusWs} = janus_sup:create_janus_connection(),
  JanusWs ! create_session,
  {ok, State#{janus_ws => JanusWs}};

process(#{<<"request">> := <<"create_handle">>,
          <<"session_id">> := SessionId}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {create_handle, SessionId},
  {ok, State};

process(#{<<"request">> := <<"create_room">>,
          <<"session_id">> := SessionId,
          <<"handle_id">> := HandleId}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {create_room, SessionId, HandleId},
  {ok, State};

process(#{<<"request">> := <<"join_publisher">>,
          <<"session_id">> := SessionId,
          <<"handle_id">> := HandleId,
          <<"room_id">> := RoomId}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {join_publisher, SessionId, HandleId, RoomId},
  {ok, State};

process(#{<<"request">> := <<"join_subscriber">>,
          <<"session_id">> := SessionId,
          <<"handle_id">> := HandleId,
          <<"room_id">> := RoomId,
          <<"feed_id">> := FeedId}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {join_subscriber, SessionId, HandleId, RoomId, FeedId},
  {ok, State};

process(#{<<"request">> := <<"publish">>,
          <<"session_id">> := SessionId,
          <<"handle_id">> := HandleId,
          <<"jsep">> := Offer}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {send_offer, SessionId, HandleId, Offer},
  {ok, State};

process(#{<<"request">> := <<"listen">>,
          <<"session_id">> := SessionId,
          <<"handle_id">> := HandleId,
          <<"jsep">> := Answer}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {send_answer, SessionId, HandleId, Answer},
  {ok, State};

process(#{<<"request">> := <<"trickle">>,
          <<"session_id">> := SessionId,
          <<"handle_id">> := HandleId,
          <<"candidate">> := Candidate}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {trickle, SessionId, HandleId, Candidate},
  {ok, State};

process(#{<<"request">> := <<"keepalive">>,
          <<"session_id">> := SessionId}, #{janus_ws := JanusWs} = State) ->
  JanusWs ! {keepalive, SessionId},
  {ok, State}.

As you might notice we are having one API request for each Janus request. This was done for simplicity's sake, but you could easily write an API request which performs multiple Janus requests.

Considerations

Multiplexing websockets

As you saw, we create one server-Janus websocket per client. On actual live usage this might not scale properly due to the overhead of having to establish the websocket connection on-demand, so we designed a possible solution: multiplex multiple sessions through a set of previously created websockets. Something like this:

Create a fix set of server-Janus websockets on start using a worker pool.
Create a unique ID for requests, should identify the process to send Janus's response.
Add the request's unique ID to transaction value.
When handling a response from Janus decode the request ID to figure out to what process should we send the response.

NOTE: Sessions have to be unique, one per client.

Problems inside Docker

I think I've haven't mention this, but we are using Janus inside a Docker container. Normally this wouldn't be an issue, add it to our docker-compose.yml, expose the ports, and that's it.

Sadly no, things aren't so easy. STUN servers have one simple job: to tell a client its public IP. That way if a client is behind a NAT and only knows its private IP it can find out its public IP. We are using our own set of STUN/TURN servers (inside the same docker-compose as Janus), which becomes an issue when Janus creates its ICE candidates given that Janus and STUN are on the same LAN. Because the STUN server returns to Janus its public IP as the one it has inside the Docker containers' network, a private IP. If you don't know a lot about networking, just know that this is REALLY bad.

Thankfully Janus has ways to handle this sort of things, you can have it replace the host IP on all ICE candidates by an IP of your choosing:

Pass the argument -1 <public IP>
In janus.jcfg inside nat section set nat_1_1_mapping = "<public IP>"

Conclusion

Great! Now we have a working and scalable broadcasting using WebRTC. So many new things learned, a bit over-engineering over there, but we made it. :D

You can find the code for all this in

AminArria / janus_erlang_wrapper_demo

Demo for a Erlang app wrapping Janus

Demo: Erlang wrapper for Janus

This is a demo Erlang app to demonstrate the usage of Janus. For further information regarding "why this demo?" I encourage you to read my blog post Scalable Broadcasting Using WebRTC.

The demo will expose the following endpoints:

http://localhost:8080/janus-client Client connecting directly to Janus for video broadcast
http://localhost:8080/api-client Client connecting to our Erlang app
http://localhost:8080/websocket Endpoint to establish a websocket connetion with our Erlang app.

NOTE: This demo was tested using Firefox 65 and Chrome 72.

Requirements

Erlang/OTP (tested with Erlang/OTP 21)
Docker Compose

Running Demo

First turn on Janus

make ops

Start Erlang app

make run

To stop Janus

make ops_stop

Demo

Both clients, janus-client and api-client, present the same interface and way to use so everthing explained below applies to both.

As broadcaster

Start session
Start handle
Make room (This will fill the Room ID field)
Join as publisher (This will…

View on GitHub

How to explain what is the back-end?

Amin Arria — Mon, 03 Sep 2018 17:10:19 +0000

Disclaimer: I'm never sure how it should be written: back end, backend, or back-end.

Lately I've had to explain to non-technical (read: lawyers, accountants, etc) people what is a back-end.

I've found out one thing: It's HARD

Do you have any tip, analogy, example, or something on how to explain what is the back-end?

Exercise: Making a Simple Regex Engine

Amin Arria — Sun, 05 Aug 2018 21:56:14 +0000

I've started working for Lambdaclass and getting to know Erlang. As preparation for interviews with potential clients I got an assignment based on this article: Build a Regex Engine in Less than 40 Lines of Code. So now I need to try and do it in Erlang, let's see how it goes.

The Task

Create a function (match/2) that will receive a string and a regex (also a string), and return true if it matches or false otherwise. You won't be using all of Regex, just a small subset of it as follows:

Syntax	Meaning	Example	Matches
`a`	match the specified character	`k`	k
`.`	matches any character (except newline)	`.`	a,b,c,d...
`?`	matches 0 or 1 of the previous character	`aq?`	a, aq
`*`	matches 0 or more of the previous character	`b*`	"", b, bb, bbb
`^`	matches the start of a string	`^ca`	ca
`$`	matches the end of a string	`eb$`	eb

Considerations

Before diving into making a solution I needed to establish certain considerations that I took into account when designing the solution.

The given regex won't be invalid (Eg: "^*", "*?")
I can ignore the existance of the newline character since I expect simple strings as inputs. Thus the character . matches anything
An empty regex matches nothing so match(SomeString, EmptyRegex) will return false
match/2 can return true as soon it matches something since I don't care about where or what.

Solving the Problem

First step to making a solution was to create the base cases. An empty string or and an empty regex can't match anything.

-module(regex).

-export([match/2]).

match([], _Regex) ->
  false;
match(_String, []) ->
  false;

Next step was to match same characters, something simple thanks to pattern matching:

match([Char | String], [Char | Regex]) ->
  matching(String, Regex);
match([_Char | _String], [_OtherChar | _Regex]) ->
  false.

Doing this I figured that I already had made a mistake, my match/2 function would match correctly things like match("hi", "hi"), but would fail matching match("oh hi", "hi"). I needed a way to try and match the string with the regex trying every single character in the string as a starting point. For this I modified match/2 to call a private matching/2 function. If it succeeded match/2 would return true, but if it failed I will try it again but dropping the first character of the string.

match(String, Regex) ->
  case matching(String, Regex) of
    true ->
      true;
    false ->
      match(tl(String), Regex)
  end.

matching/2 will work by consuming the regex and string. Whenever there is no more regex a match has been found. I'll add this clauses and modify the existing match of characters.

matching(_String, []) ->
  true;
matching([], _Regex) ->
  false;

matching([Char | String], [Char | Regex]) ->
  matching(String, Regex);
matching([_Char | _String], [_OtherChar | _Regex]) ->
  false.

For the . I just had to had a clause to match any character in the string against it and keep on matching.

matching([_Char | String], [%. | Regex]) ->
  matching(String, Regex);

Next step was to tackle the remaining special characters. I supposed the ^ and $ would be easier, so them first. For the ^ I only needed to add a clause to match/2 to check for it and return whatever matching/2 returns, can't keep trying. For the $ I would only need to check if the string is empty and return true or if not empty return false.

match(String, [$^ | Regex]) ->
  matching(String, Regex);

...

matching([], [$$]) ->
  true;
matching(_String, [$$]) ->
  false;

Now starts the hard part, handling ? and *. As always I think going from simple to dificult is best so let's start with ?. I need to consume both a string's and a regex's character when they match, but when they don't only consume the regex's character.

matching([Char | String], [Char | [$? | Regex]]) ->
  matching(String, Regex);
matching(String, [_OtherChar | [$? | Regex]]) ->
  matching(String, Regex);

Not the most beautiful pattern matching, but it works. The thing is this leaves us with an issue: Now we can have no string left and still match successfully (Eg: match("hi", "hio?"). To fix this I'll add a clause checking if ? is the next character and continue matching if that's the case.

matching([], [_Char | [$? | Regex]]) ->
  matching([], Regex);
matching([], _Regex) ->
  false;

For * its pretty much the same except when it matches we don't go ahead an consume it, instead we keep calling it until it doesn't match. Like before I'll also run into the issue of not having any more string so I need to add a clause for that as well.

One last problem: .*. This combination will match against every character and prevent matches like match("hello", ".*o"). This was really hard to figure a good way to deal with. Eventually I realized that since .* would match against nothing or everything I could just do like match/2 and use the same process of trying and consuming the string.

matching(String, [$. | [$* | RemRegex]] = Regex) ->
  case matching(String, RemRegex) of
    true ->
      true;
    false ->
      matching(tl(String), Regex)
  end;

The End

Finally after quite a struggle (and more than 40 lines of code) I managed to finish a simple regex engine. It was really interesting thinking about edge cases, how to best pattern match, and how to order the function clauses. I leave a snippet of the whole final module below.

PS: If you are interested in learning Erlang with some exercises check out Erlings

-module(regex).

-export([match/2]).

match([], _Regex) ->
  false;
match(_String, []) ->
  false;
match(String, [$^ | Regex]) ->
  matching(String, Regex);
match(String, Regex) ->
  case matching(String, Regex) of
    true ->
      true;
    false ->
      match(tl(String), Regex)
  end.

matching(_String, []) ->
  true;

matching([], [$$]) ->
  true;
matching([], [_Char | [$? | Regex]]) ->
  matching([], Regex);
matching([], [_Char | [$* | Regex]]) ->
  matching([], Regex);
matching([], _Regex) ->
  false;

matching(_String, [$$]) ->
  false;

matching(String, [$. | [$* | RemRegex]] = Regex) ->
  case matching(String, RemRegex) of
    true ->
      true;
    false ->
      matching(tl(String), Regex)
  end;

matching([Char | String], [Char | [$? | Regex]]) ->
  matching(String, Regex);
matching(String, [_OtherChar | [$? | Regex]]) ->
  matching(String, Regex);

matching([Char | String], [Char | [$* | _RemRegex]] = Regex) ->
  matching(String, Regex);
matching(String, [_OtherChar | [$* | Regex]]) ->
  matching(String, Regex);

matching([_Char | String], [$. | Regex]) ->
  matching(String, Regex);
matching([Char | String], [Char | Regex]) ->
  matching(String, Regex);
matching([_Char | _String], [_OtherChar | _Regex]) ->
  false.

How to teach DNS and DHCP

Amin Arria — Wed, 11 Oct 2017 20:37:54 +0000

I'm going to do a small talk/workshop/class to teach DNS and DHCP basics to the new members of our small sysadmin-like lab at my university. The main objective is to give the basics concepts, how to setup, and how to properly maintain an existing domain. So I was wondering what was the best way (or well, your way) to approach this and any tips/recommendations you had.