I think the longest you can set it is 3 months nowdays.
hubertlepicki
hubertlepicki
@grych I like both the API and the idea very much. It’s like the RJS templates from good 'ol days Rails 2.x, but on steroids thanks to persistent nature of Phoenix sockets.
One must think of limitations and downsides of going with this approach before choosing it over say API + React, however I think it’ll do well for most applications. And I guess you can throw in some JavaScript where it does not do good enough job.
I usually deal with a lot of forms, and the dynamic bits on these forms can be like inputs that format say phone number, or postcode as you type. I think writing those as tiny react components would be great fit. Drab would still treat those as normal input when collecting the data server-side.
On a positive side, I am mostly thinking about the code you no longer have to write. Less code == less bugs.
On a negative side, I see that the coupling between back-end event handlers and UI will make stuff like UI upgrades slightly more complex. I also have a hunch you can easily write really bad spaghetti, unmaintainable code this way. I remember the problems we had with RJS and how eventually the Rails community decided to abandon the idea.
Either way, I will give it a shot really soon. The current front-end situation is ridiculous. This is a step back, but a tactical retreat rather than escape :).
2
grych
Creator of Drab
@hubertlepicki,
the big picture is to keep everything on the server side. I started with DOM interfaces, Drab.Query module simple translates Elixir functions (select, update etc) to corresponding jQuery methods and executes it on the client side.
Why not to create a similar module for, for example, React? So you could build the whole interface in Elixir.
1
grych
Creator of Drab
Ops, sorry my fault. I’ve changed the server over the weekend and have an issues with elixir/erlang installed from the package (Debian) - memory is leaking like hell. I am installing it from the source now. Please check in 1/2 hour, should be working again.
1
hubertlepicki
no worries, it was quite funny when colleague asked “I wonder how reliable it will be” and then bang ;D
1
grych
Creator of Drab
grych
Creator of Drab
This is what concerns me as well.
In theory, its reliability should be the same as Phoenix/Websockets, but you never know. This software still needs a lot of work and test. Anyway, enjoy!
1
grych
Creator of Drab
Issue solved. Actually it was not an problem with Drab, but with the Demo page. I will describe it, as it was quite an interesting case.
On the demo page there is a part which shows you /var/log/nginx/access.log in a realtime (to show how the server-side events can manipulate User Interface). This functionality uses Sentix which is a wrapper around command-line fswatch. This is a demo, so the code should be easiest possible, not have to be efficient or sophisticated.
This weekend I moved everything (not only Drab, also some other projects) to the new server, running Debian. The old one was running on 10-years old Mac Mini (OSX Lion). Movement was quite smooth, everything worked so after few tests I’ve updated the DNS.
Then I realized that the beam process of Drab Demo eats a memory, and it is growing very fast. Strange, as the same stuff worked without any issue on OSX. I recompiled Erlang and Elixir to the exact same version as on the old machine, without success. So I started :etop and tried to analyze what’s going on internally. And I’ve found the massive (hundreds of thousands and quickly growing) messages queued on some Drab processes.
The only difference now was fswatch - on OSX I used kqueue, on Linux - inotify. And bingo - that was the issue. The difference is that kqueue monitors file updates only (by default) and inotify is more complex: it can monitor every access to the file (describing it as :platform_specific).
The code of the demo page is simple, it runs an infinite loop and waits for messages when fswatch find that the file was accesses:
Sentix.start_link(:watcher, ["/var/log/nginx/access.log"], monitor: :intotify_monitor, latency: 1)
Sentix.subscribe(:watcher)
file_change_loop(socket, file)
defp file_change_loop(socket, file_path) do
receive do
{_pid, {:fswatch, :file_event}, {^file_path, _opts}} ->
socket |> update(:text, set: last_n_lines(file_path, 8), on: "#log_file")
end
file_change_loop(socket, file_path)
end
It worked perfectly on OSX, because fswatch sent :updated message only when log file was changed. But on Linux, by default, it sents :platform_specific message also when nginx access the file without updating it…
So what happened: when access log file was accesses/updated/touched, process received and message and… sent websocket message back (with socket |> update(:text, set: last_n_lines(file_path, 8), on: "#log_file")) to update #log_file div. While doing it, Nginx access the log file, which issue fsevent - and it finished with the classic positive feedback.
Solution was very simple, I just need to monitor only :update events from fswatch:
Sentix.start_link(:watcher, [file], monitor: monitor, latency: 1, filter: [:updated])
What is very interesting in this situation is that the server survived it and was able to handle all requests. Until it crash few hours later, because of the exhausted memory 
6