Qqwy
I am working on a small library that computes a moving average, which would work well with Phoenix PubSub, in that it could subscribe itself to a topic using Phoenix PubSub, and then handle the events as they come in.
However, users should be able to modify the exact logic that is going on inside, including what topics it is subscribed to. This is a bit of a problem though, because a PubSub-broadcasted message does not contain any identifying information (It is just a ‘plain’ message that will trigger your GenServer’s handleinfo.)
So, if I want to give users the ability to subscribe to varying PubSub topics, they need to be able to tap into the handleinfo part of the GenServer that the library constructs, to allow matching on the proper messages.
What would be a proper way to do this?
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #performance










First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
idi527
I remember seeing GitHub - JEG2/hanabi_umbrella: The sample application for Paul Dawson and James Gray's Lonestar Elixir 2017 talk: The NeverEnding Application. · GitHub, where I think phoenix pubsub was used to tie different umbrella apps together. You might want to look into
hanabi_engine/game_manager.ex.Maybe you can use
pg2without phoenix pubsub in order to add your custom logic?Most Liked
chrismccord
I still don’t have a complete picture, especially around users making their own events, but let’s start wit this code. Here we have a
GameStorewhich is the boundary for the game system. You are correct that you want to wrap the pubsub mechanism so the caller doesn’t need to know about it. Given different actions in the system, like purchasing or transferring an item, you’ll broadcast events as part of the success cases. Meanwhile, you can expose asubscribe/0,subscribe/1and unsubscribe functions on theGameStorefor other callers to consume. If they are interested in stats they can subscribe to the “stats” group. I show the Caller example below the GameStore:Does this put you on the right track?
windholtz
updated code available here:
https://github.com/mwindholtz/phoenix_pubsub_example
Qqwy
Thank you very much for your help, everyone.
To make it more clear what I am struggling with, I have written it down now as a library: SlidingWindow. (Still very work-in-progress; it does not have a lot of documentation yet as things might still change a lot.)
It does what I want to perform in a finite-state-automaton kind of way; that is, SlidingWindows does not care about GenServers or anything at all right now, but only about gathering and updating the information stored in the struct.
An example of a behaviour to calculate averages: (See also the file test_helper.exs)
And then you can create it using something like:
In the end, I think that the smartest decision I can make is to not mess with wrapping this inside of a GenServer-like layer myself, as there are an infinite amount of possible ways how someone might want to manipulate the FSA. Rather, I’ll write some example code on how it could be wrapped in your own GenServer including an
send_aftermessage to ensure that the data inside never becomes stale.