Crowdhailer
Advice for developing a library with Elixir and JavaScript parts. API/Documentation/Publishing/Redux
I am developing a library that unusually has a significant client part. In summary GenBrowser aims to give clients/browser an identifier that can be used to send messages to/from/between clients. In essence a pid.
For example
# browser 1
const { address, mailbox, send } = await GenBrowser.start('http://gen_browser.dev')
console.log(address)
# server
iex> {:ok, client} = GenBrowser.decode_address(address)
iex> GenBrowser.send(client, %{text: "From the server"})
# browser 2
send(address, {text: 'From browser 2'})
# browser 1
var message1 = await mailbox.receive({timeout: 2000})
message1.text
# From the server
var message2 = await mailbox.receive({timeout: 2000})
message2.text
# From browser 2
The security model relies on signing addresses that are sent out of the server, that is why the signed address needs decoding on the server.
I am not very up to date on the front end world and so want some advice on how to proceed with this project.
Ideally I want to keep the whole thing in one project and use as much of the Elixir ecosystem as possible. However that might be limiting.
Advice on the JavaScript API
There are two options for working with messages received.
mailbox.receive()that takes an optional timeout an returns a promise that completes on the next messagemailbox.setHandler(messageCallback, closeCallback)The first callback is called whenever a message is received, the second when the mailbox has been closed permanently.
These names api’s come from their erlang world equivalent receive and handle_*. They look reasonably sensible in the JavaScript world but could probably be more idiomatic
Npm publishing
The project has a JavaScript build step and the code is always to be used in a client.
- Would you expect this to be available on npm as well as a CDN
- If so should only the source (or only the bundle) be published to npm
JS Documentation
ExDoc has spoiled me for ease of setting up documentation. In these cases I am probably just looking for the most standard/simple way of doing things
- What is the recommended way to document a JavaScript library?
- Is there a way to integrate this documentation into the hex documentation?
Redux as Actors
With my (limited) knowledge of redux I think that redux and GenServers look quite similar.
Hence the name of this project.
Do you think this is a helpful analogy when describing processes to JavaScript developers.
Within a single process or store there is a single state tree.
I often say that sending a message is like dispatching on a remote store.
Is there any better way of explaining things? Should I just say actor model and not confuse the issue with mentioning redux
Most Liked
peerreynders
Given the nature of a mailbox as a potential source of an infinite stream of messages (events) a more contemporary interface like Observable seems more appropriate (active implementations RxJS, xstream, Bacon.js, Kefir) - Learning Observable By Building Observable.
While I realize that await is a popular construct to make asynchronous code look more sequential, I believe that this is ultimately barking up the wrong tree given the mercilessly single-threaded nature of JavaScript runtimes.
On the BEAM strictly sequential code makes sense given that you can have millions of tiny processes for concurrency. Pretending on a single threaded platform that sequential flow of control programming is sufficient for more complex interactions will in my opinion ultimately run into a brick wall.
The real answer is to start writing code that composes event streams and let the underlying platform schedule what gets processed when.
Can you please expand on this line of thinking - i.e. what has lead you to this conclusion?
- The Redux implementation was inspired by the Flux Architecture
- In the end the Redux analogy may not be that helpful to that many people. It is my impression that Redux adoption may have peaked since the introduction of the new Context API and since more people have started to rely on GraphQL clients (lifting whatever was left of their state up) and of course the general notion that You Might Not Need Redux. People may have adopted Redux for very different reasons and some are now only holding out because they aren’t yet ready to let go of the concomitant development tooling.
LostKobrakai
You could take a look at how phoenix handles their js dependency.
- It’s on npm, published out if the elixir repo
- It has it’s javascript docs on hexdocs.pm
As for the API:
I’d expect a callback driven interface. Promises are better for async results for a single action/task.
namelos
Redux is more like Agent since most of the effectful operations are strongly discouraged.
Most of the effects are handled with redux-saga or thunk. Redux-saga is a little bit like a worker, but there’s no mailbox.
The key difference is Redux simplified everything by dispatching the event to every possible listener, so there’s no such thing like pid at all. And it’s acceptable because in front-end we usually don’t have too much data.
And also all redux operation happens in a synchronous manner so there’s no need for a mailbox.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








