Fork me on GitHub
#off-topic
<
2021-10-05
>
salkadam05:10:45

Rsocket with clj or cljs , any library supporting that

delaguardo08:10:42

There are official java and javascript libraries - https://github.com/rsocket/rsocket-java https://github.com/rsocket/rsocket-js Both should be easy to use within clj or cljs context

dgb2310:10:29

I just had the most liberating epiphany... I kind of got stuck (for the lack of a better word) for months(?) thinking about and implementing data driven design techniques. The knot I had to open is that I had this assumption or model of having a schema driven pipeline (or DAG) about things. You start with a schema representation (such as spec/json-schema/malli/SQL...) and then kind of derive and ammend stuff until you get a domain model, a UI or what have you. I thought like I was going somewhere super important here (haha). But while implementing this pattern It never felt quite right. It sometimes (and just 5min ago) felt like I’m bending over backwards and abusing things. Little workarounds, edge cases, more definitions and conditionals. In some specific cases the above approach is kind of true, but in general It’s the other way around! The essence is the actual thing in our heads that we want to communicate. It’s the thing that “drives” representation and the schema is just meta data about that (or maybe one specific representation). The real essence are the thoughts and relations we want to communicate - from human to human and human to computer. This is why there is no one, all encompassing structure that has enough generality to represent and “drive” all other representation. I can generate the schema or just simply put it next to the thing where it is needed. Following that train of thought I’m going to start doing the opposite more: writing/designing code that is closer to a context appropriate representation first. Now I don’t know if the above makes sense at all or whether that is obvious/trivial some of you or if the pendulum just swings into another direction? But personally it feels like I got rid of a blockage that I kept banging my head against while thinking “I just have to get this blockage right, then it will stop hurting so much”. Feels great!

dgb2310:10:00

(I also feel like I’m having a bit of a deja vu here but I hope I finally got it :D)

slipset10:10:10

I think you’re right on the money, if I understand you correctly. I’ve been thinking about somewhat the same thing, but perhaps in a different context: So, imagine a webapp where you basically have two endpoints, somewhat like graphql, you have one endpoint which accepts actions, called doit, another which accepts queries, called q. Now the problem I was struggling with is what kind of queries should your q endpoint accept? The generic solution would be to just expose whatever data model you happen to have in your database, but most likely you do not want to query your backend at that level, so you probably want to allow for queries which are tighter coupled to your higher level domain model, eg who cares how you store customers and addresses in the database, this is nothing you want to expose. Anyways.

☝️ 1
Lennart Buit11:10:03

we have a GraphQL schema that allows for queries pretty close to how our apps use it while it maintains room for schema growth. Sounds eerily similar :)

dgb2310:10:12

Yes! And even just how q looks doesn’t even need to be static and your db schema neither. They don’t need to drive all the things. Maybe you want to generate them or maybe you only care about a specific part in some context. They might be implicitly obvious, or someone might have to provide them explicitly.

dgb2310:10:27

And most importantly there is just stuff you don’t foresee or even care about.

respatialized13:10:12

I think Data And Reality by William Kent grapples with a lot of these issues in a very clear way. As a former philosophy student, I found it to basically be an intro to metaphysics text disguised as a computer science book. And I also found myself repeatedly thinking while reading it "huh, sounds like Datomic took the right approach with regard to this data modeling problem," particularly with regard to the last bit you mention - the "stuff you don't foresee" - because of its open and associative model.

🙏 1
dgb2315:10:39

that’s on my reading list 🙂 it grows way faster than it shrinks!

mauricio.szabo16:10:02

Datomic and datalog databases, for me, are puzzling. In a way, they make growing and enriching your schema incredibly easy. It's also easier to simply "start small" and grow with Datalog. On the other way, when the schema becomes more stable, I miss SQL so much - not the language, specifically, but the power it gives me to group, aggregate, join and split in a somewhat predictable way (I'm mostly talking about powerful SQL databases here like PostgreSQL, not MySQL to be clear 😄)