it feels like pretty clojure-macro-able to me 🙂

I've also asked in #datomic but this is probably a broader issue

no but I'm very familiar with github package registry, what's the question?

@U05509S91 i've pushed the datomic-pro jar to a private repo with mvn deploy. This "works", but I can't get leiningen to pull with the normal coordinates

I have been able to pull a different library with the same credentials (https://github.com/yi-jiayu/clj-left-pad/packages/18529)

So i'm thinking maybe there is something wrong with the pom.xml . I don't know how to debug it

it comes out a bit differently it seems (i'm trying to pull it as com.datomic/datomic-pro)

💯 for an actually-off-topic message 🙃

Almost anything by Amon Tobin is dope!

(there's a #music channel BTW)

I appreciate that you might not be able to talk about this too much. But what are you sending the events too? What's listening to the channel? Also, how much code is generally involved in creating each event?

So our current system isn't a unified framework - it just uses plenty of go blocks/channels, our system has plenty of API calls to external systems, db calls etc, so we hand off anything blocking to a threadpool and then park our logical threads. However I've prototyped a more coherent system that sounds more like what you are aiming at - when requests hit the system, they have some minimal initial processing and are then placed into an a/pub. There are then "processors" which subscribe to the pub and listen for topics. Caveat - almost entirely untested prototype - but it was fairly straightforward to write a macro to handle all of the plumbing, so writing processors is just a matter of specifying what input topics to listen to for a given processing function.

This is exactly what I'm thinking about, yep

1 tip: meander looks fantastic for that initial processing 2 questions: A. How do you handle state in handlers? I'm trying very hard to think about this. B. What drove you to come up with this?

A - I don't have any complex handlers mimicing our production code written up in the new system yet, but I don't suspect it would be any different to your average clojure code.

B - We wanted to see if we could come up with a more linear code path for requests - currently it's a fairly typical nested route of calls, e.g., handler calls some logic function which calls some sub routines, which return to the logic function, which returns to the handler, which returns a response. with the event based system it's a linear path, which could be easier to reason about - but we're still not positive on it

Meander looks quite interesting, thanks

What are you looking to build?

I'm trying to decouple state from my web handlers. The intention is that people writing web handlers have a tendency to not care about the "how" of creating a user (e.g. postgres db or whatever) it just wants to call into a domain function and have it work. You could either encapsulate the "domain" into some opaque object blob, or you could communicate using data and leave interpretation and state management up to something else.

I have some workflow enhancements that will naturally flow out of this. For example, if the result of events are data, they can be spec'd. Then you can generate the variations of those responses, and open up a bunch of browser tabs to ensure that they look correct while working on them.

e.g. does role XYZ overflow the container it's in. Or, what does the UI look like if you try and access it as an unauthorized user? Things like that.

Yeah, my prototype includes assigning specs to event types. Each event processor also specifies what events it might produce, and the engine can then do verification of return types (or verify that the processor is expected to not return an event). Reducing the amount of state is also something I've been wondering - right now we end up having to pass around some blob of required components, which isn't great

I've been wanting to get back onto it to get a more fully fledged system, looking at how our current logic would map over, but...the usual story, other priorities raise their head

The giant blob of dependencies has bitten me many times. I did use an integrant system which specified exact dependencies for everything, but it was declared too verbose. I need to rethink things there a little too, in order to combine it with the event system. But I own the event system, so I can shift it as needed.

I think that there's only a handful of use cases you need to cover: - integration tests: you can share a big map of dependencies here. Integration tests inherently don't fit in your brain. They aren't part of something simple. Add additional subscribers in order to peek into the inner workings. - unit tests: just orchestrate the event handlers you need into a new set. This should be easy (if it isn't, then we are doing something wrong) Both of these are parallel friendly too. As the event system won't be a place.

Anything really :) even a blog post describing it and it's trade offs