Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir web development 101: collaborative todolist with realtime updates

blog.openbloc.fr

Post reply on HN
Print view View original

51–60 of 97 posts

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

#51

Post by whalesalad »

I'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement.

While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly.

The real beauty of Elixir/Erlang is being able to run hundreds of thousands of concurrent "threads" (co-operative in userspace, not OS-level).

Anyway I do not mean to detract from the post here -- just feel like a todo list is not a shining-star example of Elixir and would love to see some more hackers post their concurrency work here.

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

#52

Post by toolz »

5ersi wrote: post #28
oelmekki wrote: post #21

Earlier quoted context omitted.

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.

clients don't have any api to get at data pushed by http/2 - it is not a websocket replacement and can't be used for the same things. http/2 will be used to multiplex static resources to clients - not application data

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

#53

Post by out_of_protocol »

pmontra wrote: post #40
bsaul wrote: post #30

Earlier quoted context omitted.

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.

I'm in the fourth month of a Phoenix project, which shields me from almost all of OTP, and I agree with your point. Maybe even "Erlang with a Ruby syntax" would be too much. Similarities with Ruby don't go any further than "def" "do" "end" and many library modules and functions deliberately named to mimic corresponding modules and methods in Ruby. Everything else is different, both syntax and semantic. After 10 years…

I don't see how Ecto is any worser than AR - imo it is not AND way more flexible. Also, `from ...` form is not the best choice - other form (e.g.

  user = User |> User.actual |> User.by_email(email) |> ....
) allows query decomposition, the same way AR does.

  user = User.actual.by_email(email)...

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

#54

Post by conradfr »

benwilson-512 wrote: post #29
fabian2k wrote: post #15

Earlier quoted context omitted.

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 operati…

I did (i.e paid) the Pragmatic Studio course and a large part is making a project that mimics a HTTP server and I find it a great way to discover functional programming and pattern matching (doesn't touch Phoenix though).

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

#56

Post by brightball »

whalesalad wrote: post #51

I'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly. The real beauty of Elixir…

For what it’s worth, the collaborative to do list is giving you an example of websockets with channels. Channels dedicates 3 server side processes per socket IIRC. One for the connection, one to supervise the connection and one to represent the user state for that connection. That’s only possible because of how cheap those Erlang/Elixir processes are. Because of that, just about any websocket example is a decent representation.

Plus, when you really start thinking about how the entire platform is designed specifically for passing small messages around between process, websockets become an even better example since that’s exactly what they do with the browser. You enable passing small messages between millions of connected clients to a server side environment built for passing millions of small messages between clustered and horizontally scalable servers.

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

#57

Post by benwilson-512 »

brazzledazzle wrote: post #46
benwilson-512 wrote: post #27

Earlier quoted context omitted.

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 i…

Do you use Absinthe?

Hey! Yup I'm actually one of the co-authors of Absinthe. Got any questions?

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

#59

Post by skrebbel »

ams6110 wrote: post #48
oelmekki wrote: post #21

Earlier quoted context omitted.

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…

I've been out of front-line web development for a while. Are Websockets supported widely enough that a developer can reasonably assume they are available and not have to worry about workarounds such as comet/long polling?

Almost, depending on who you ask.

But Phoenix contains these workarounds and it works great. So with Phoenix Channels you can really just act like It Just Works.

(phoenix.js is one of the best parts of the library IMHO - its design beats eg socket.io dead out of the water)

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

#60

Post by sergiotapia »

brightball wrote: post #34

If you're doing development with a web socket layer, it's entirely worth it to try out Phoenix Channels before you commit to another stack. It makes your life so much easier. There are a lot of other great reasons to use Elixir though.

Phoenix Channels feels like cheating because it's just so intuitive and you get so much performance straight out of the box. It's obscene! Maybe I'm used to Ruby perf that this blew me away so much.

On free tier heroku dyno and the $7 postgres hobby dev, performance was around 27,000 messages sent per second before POSTGRES started complaining. It wasn't even the app itself that was complaining, it was postgres. This was sent via websocket using phoenix channels and persisted to the database.

If you're a backend guy, add this tool to your repertoire - you'll become a wizard and just have tighter code with less headaches.

Post reply on HN