Live data from Hacker News

Elixir web development 101: collaborative todolist with realtime updates

blog.openbloc.fr

21–30 of 97 posts

Re: Elixir web development 101: collaborative todolist with realtime updates

#21
post #3

> channel.on('update:todo' ... > channel.push('delete:todo' ... > Have a CRUD interface over websocket REST over websockets. What's the advantage over HTTP? I know websockets allow for pushing data to clients, but this is pull so apparently there should be no advantage, only more code to write. Edit: maybe you're sharing updates among all the users connected to the server. Still, for sending requests HTTP is enough.…

This is interesting when you want near realtime performances, as you don't have all the culprint of a http request : you basically just send a few octets (a json document, or even just a simple value), and you don't have to build a request and negotiate a connection.

This is not something obvious because we have helpers to make http requests, but there are many things going on while issuing a http request (building headers, encoding body, etc) [1]. A socket (be it a websocket or a classic socket) has this advantage that all the negotiating part is already done and you just have to send the message, in whatever format you want. Decoding the request on server side is way easier too.

[1] https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Me...

Re: Elixir web development 101: collaborative todolist with realtime updates

#22
post #10

Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't using OTP. They both justified using elixir because it was "closer to ruby" (???), and they both seemed to live a pretty difficult time with that language. Which makes me wonder : why would you ever want to use such a special language (purely functional isn't f…

I've seen a few (as in 2 ;) ) examples of this myself. And this is what "scares" me the most for elixir's future/potential. I think it's a great language/tech but ruby enthusiasts rushing into it thinking that it's "just like ruby but faster" may have a very bad influence on where the language goes. They may bring a lot of ruby best practices that don't transpose at all in elixir/erlang world.

Re: Elixir web development 101: collaborative todolist with realtime updates

#23
post #13
post #10

Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't using OTP. They both justified using elixir because it was "closer to ruby" (???), and they both seemed to live a pretty difficult time with that language. Which makes me wonder : why would you ever want to use such a special language (purely functional isn't f…

I'm guessing what they really meant is "it's close to rails" since the same people made both rails and phoenix AFAIK.

Some of the main contributors - starting with J Valim - were core ruby contributors I think.

Re: Elixir web development 101: collaborative todolist with realtime updates

#24
post #17

Earlier quoted context omitted.

No, there is not a handshake for every message you send over websocket. You do the handshake only when you open the connection.

HTTP keepalive should get you much of the same benefit, though? The major improvement comes from fewer headers sent over websockets?

SSL Session Reuse needs to be configured as well, otherwise every single request will have to perform a new handshake, independently of keepalive.

In practice I've always observed HTTPS requests to take at least twice as long compared to a back and forth through a websocket, even when SSR and keepalive are enabled. I don't know if having both theorically allows for single-roundtrip HTTPS requests.

Re: Elixir web development 101: collaborative todolist with realtime updates

#27
post #3

> channel.on('update:todo' ... > channel.push('delete:todo' ... > Have a CRUD interface over websocket REST over websockets. What's the advantage over HTTP? I know websockets allow for pushing data to clients, but this is pull so apparently there should be no advantage, only more code to write. Edit: maybe you're sharing updates among all the users connected to the server. Still, for sending requests HTTP is enough.…

A bit tangential but one of the things I've enjoyed about using GraphQL lately is how easily it can be used over websockets. All the API work you do to support HTTP can be immediately used over websockets because the it never required a specific transport to begin with.

Phoenix channels make it super easy to setup and use websockets, but you're sort of on your own as far as figuring out how to work REST conventions into it since all the tooling that exists for REST generally assumes and requires HTTP.

It's great to be able to write the code for the API once and support it across a broad variety of transports.

Re: Elixir web development 101: collaborative todolist with realtime updates

#28
post #3

> channel.on('update:todo' ... > channel.push('delete:todo' ... > Have a CRUD interface over websocket REST over websockets. What's the advantage over HTTP? I know websockets allow for pushing data to clients, but this is pull so apparently there should be no advantage, only more code to write. Edit: maybe you're sharing updates among all the users connected to the server. Still, for sending requests HTTP is enough.…

This is interesting when you want near realtime performances, as you don't have all the culprint of a http request : you basically just send a few octets (a json document, or even just a simple value), and you don't have to build a request and negotiate a connection. This is not something obvious because we have helpers to make http requests, but there are many things going on while issuing a http request (building h…

HTTP/2 multiplexes requests over one socket connection, so it should solve most of problems you state.

Re: Elixir web development 101: collaborative todolist with realtime updates

#29
post #10

Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't using OTP. They both justified using elixir because it was "closer to ruby" (???), and they both seemed to live a pretty difficult time with that language. Which makes me wonder : why would you ever want to use such a special language (purely functional isn't f…

Are those web applications? If they're using Phoenix, they are also using OTP under the hood, but they don't have to use it directly.

To elaborate on this a "traditional" stack of Phoenix for the web and and Ecto for the DB uses quite a bit of OTP, particularly if websockets are involved (every connection is a GenServer).

The thing is, going from Ruby to Elixir involves two learning curves: groking functional programming, and then groking processes. They really do need to be learned in that order since, within any given process, you're just operating in a relatively normal functional world.

HTTP requests are very easily envisioned in a simple functional way. You've got request data in, and you're gonna return response data. The interaction you have along the way with OTP based database pools and so forth is as a client, you aren't really having to manage the lifecycle of any of that stuff. In other words to get going with basic web stuff it's more critical to just become familiar with functional programming, and less critical to understand how OTP works. This is totally fine from a learning curve perspective.

What's cool about Phoenix channels though is that each user's connection, and each channel that they run is a GenServer. It provides a great opportunity to get some hands on interaction with the concept in a way that naturally fits into with the web application they're building.

TL;DR:You can be a client / user of OTP processes without knowing the details of how they work, and that's generally enough for HTTP.

Re: Elixir web development 101: collaborative todolist with realtime updates

#30
post #22
post #10

Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't using OTP. They both justified using elixir because it was "closer to ruby" (???), and they both seemed to live a pretty difficult time with that language. Which makes me wonder : why would you ever want to use such a special language (purely functional isn't f…

I've seen a few (as in 2 ;) ) examples of this myself. And this is what "scares" me the most for elixir's future/potential. I think it's a great language/tech but ruby enthusiasts rushing into it thinking that it's "just like ruby but faster" may have a very bad influence on where the language goes. They may bring a lot of ruby best practices that don't transpose at all in elixir/erlang world.

That was indeed my underlying point. I see elixir more as "erlang with easier syntax", than "ruby with a more powerful runtime".

aka : you should get to understand erlang design decisions prior to jumping into the tech. Which probably means having more experience than building the typical low load website made with RoR.

Post reply on HN