![]() You can browser through the code here, but I will walk through the salient parts 3. It sends a stream of JPEG images down a websocket to display a jumping stick-figure in browser. I have put together a simple Phoenix app which can be used as a template for doing just this. Recently I was inspired to get rid of an Nginx frontend of a deployment and discovered that custom WebSocket handlers on the Phoenix Endpoint got a lot easier since 1.4, by implementing the behaviour. Though creating a separate Cowboy instance does mean using Nginx, or similar, as a proxy if you want to use only the standard ports (443 / 80) for your application. ![]() Previously, firing up a separate Cowboy seemed to me the simplest option, side-stepping what seemed to be some hair-rising configuration fiddliness to get custom WebSocket handlers working directly with Phoenix, which I could not be doing with. ![]() One way incorporate those into a Phoenix app is to fire up a separate Cowboy instance, on a different port to Phoenix, and use Cowboy Websocket Handlers directly. Using binary terms to communicate between Erlang nodes on the Internet (eg Phoenix web-server to Nerves devices) is much simpler 2 and more compact than JSON.Ī bad (but common) option used to send binary messages over WebSockets is to Base 64 encode them, and send it using Phoenix Channels when used for MJPEG streams, the image processing and message-size overhead causes noticeable lag on the stream.Īs well as text messages, the WebSockets protocol supports binary messages which are the best option for, well, binary messages. There are plenty of other reasons for sending binary messages over WebSockets, other than for images, such as sending audio files or documents. MJPEG streams are simply a rapid series of JPEG snapshots, sent and displayed one after another. I have been using the Nerves Framework and Phoenix servers to relay MJPEG streams from Raspberry Pi Zero cameras for a while 1. Very occasionally it is useful to have lower level access to the WebSockets in order to send binary messages. This is implemented with developer-friendly abstractions over WebSockets, initially with Channels, and now with the amazing LiveView. el.One of the great things about Phoenix has always been its Websocket support. pipeline :auth do plug :basic_auth, pile_env( :calendlex, :basic_auth )Įnd live_session :private, on_mount: Ĭonst originalInnerHTML = this. lib/calendlex_web/router.ex defmodule CalendlexWeb.Router do use CalendlexWeb, :router import Plug.BasicAuth But how can we protect a bunch of live routes using this approach? Let's jump to the router file and find out: #. In this particular case, we will use basic HTTP authentication for the sake of simplicity. Therefore, we must use an authentication mechanism to protect all the admin routes. Since this section of the application will expose sensitive data, we don't want to make it accessible to anyone not authorized. Let's get cracking! The private admin scope In this part, we are going to start implementing the private side of our application, in which we will be able to manage the existing event types and create new ones. We also implemented the booking form, which schedules a new event for the selected event type, date, and time slot. In the last part of the series, we generated the available time slots for a given data and rendered them as clickable items in the calendar's live view.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |