chouzar / chip

Registry library for gleam
12 stars 2 forks source link

List all registered subjects #7

Open ashton opened 3 months ago

ashton commented 3 months ago

Hey, first, nice lib! Thank you!

But, I was looking at the git history, and noticed that you removed the all() function, which returned a list of every registered subject in chip.

I know that now we have dispatch and I could use it to get the information I want from every registered subject, but it makes much more difficult to summarize everything into a single place. Since Gleam uses by default immutable data, and dispatch receives a callback, it goes against Gleam way of working.

I cannot do something like


let all_data = []

chip.dispatch(registry, fn (subject) {
  all_data = list.concat(all_data, process.call(subject, GetData(_)))
})
chouzar commented 1 month ago

Hey! Sorry for the late response 👋🏼 removed all because I could not think of a good use-case for retrieving all subjects in the registry. This would put some strain on the caller if there are hundreds of thousands of subjects in the registry.

Maybe doing something like lookup or match functions from Elixir registry module.

But with the current state of the API if you'd like to aggregate the data you may need to do something like this:

pub fn main() {
  let self = process.new_subject()

  chip.dispatch(registry, fn(subject) {
    let data = process.call(subject, GetData(_))
    process.send(self, data)  
  })

  let all_data = aggregate(self, [])
}

fn aggregate(client, accumulator) -> List(x) {
  // this function will listen until messages stop arriving for 5000 milliseconds
  case process.receive(client, 5000) {
    Ok(data) ->
      let data = list.concat(accumulator, data)
      aggregate(client, data)

    Error(Nil) ->
      list.reverse(accumulator)
  }
}
mxlje commented 4 weeks ago

Thank you for this library! I’m pretty much just getting started with Gleam and OTP and essentially built my own version of it, but especially the automatically removing processes when they die is very nice.

I also was confused why I couldn’t list all subjects or groups, and I think the main reason is that it would be great for debugging. Getting an insight into what is stored, what the groups are etc. Essentially what’s described in #4 would be great I think.

chouzar commented 3 weeks ago

Thanks for the kind words! Getting back names on the registry would be trivial, however I don't want to introduce a mechanism that would encourage folks to use chip as a small database.

Its main use-case is for subject search through a specific name or through dispatch for a group. Maybe I can add something to inspect as described on #4:

/// Returns registry datapoints like a list of tags, groups, number of registered subjects. 
/// Maybe some insight into the consumed memory (state + selectors) 
/// Information on the different tables and records in them.
pub fn info(registry: Registry(msg, tag, group)) {
  todo
}