Fork me on GitHub

Any opinions on I'm considering it for some event-driven stuff at work but the spec is in yaml, it looks like it's still in progress, and I haven't seen it before in the Clojure community šŸ˜ž edit: added link


No, sorry, I meant but forgot to add the link


so like a yaml version of swagger?


Hmm, it's inspired by OpenAPI, yes, but it's meant to be for asynchronous endpoints, e.g. message busses, not HTTP APIs


Like SNS/SQS on the AWS stack

Ben Sless13:02:52

It's supposed to be agnostic of both medium (http, queueing systems, etc) and serialization format I like the idea

šŸ™‚ 2

Hum, but what does it do except just documentation? It says it has generator,.but I'm confused how it would generate say publishing/consumption of an SQS message?


I guess discovery and documentation on its own would be pretty nice. If you could ask a service for it's set of async notification and their schema and a description of when/why they'd be published for example that be cool.

Ben Sless07:02:44

Think about all the annoying scaffolding you always need to do to connect to anything Imagine you just codegen it from the api spec Low code pipe dream?

šŸ‘ 2

Well, I can imagine a lot, my point was, it didn't seem like it could code gen things that aren't an API, at this time, but maybe I'm misreading.


I think that the generation feature makes more sense in strongly typed/oop languages. As in it will generate the data classes that will work with a given message bus


In other words, scaffolding


I think for me to be excited, it would need to generate a full client. Like if I just create a client and than call (listen event-type callback) or something. And it handles everything else needed to subscribe to events, handle errors, dead letter queues, missed messages, encryption/decryption, etc.


Or like, if I call an API and it responds through a SNS message later for example, if the generated API took a callback that handled the async SQS response for me, etc.


Does anyone know of any half-decent diagrams of React's architecture?


I haven't had that much luck, but in case anyone else is interested, this seems to be the best diagram I could find: sources: ā€¢ ā€¢


I'm pretty sure these diagrams are somewhat out of date, but better than nothing!

šŸ‘ 2
Cora (she/her)14:02:59

yeah that seems to be for class-based component and not hooks

Cora (she/her)14:02:55

which is fine if that's what you're using but hooks is what nearly everything is using these days

Cora (she/her)14:02:34

maybe the popular react-wrapper cljs projects still use classes?


both fulcro and reagent have hook support or are working on it if I'm not mistaken


This is basically the best diagram I could find that explained anything. If there are others, would love to check them out.

Cora (she/her)17:02:38

"hooks" is the key thing to add to your search

Cora (she/her)17:02:50

lifecycle is also helpful

Cora (she/her)17:02:10

confusingly, you can use both hooks and classes in the same application and so knowing both lifecycles is helpful


Thanks! these are great!

pizzaspin 2

Ideally, I'm trying to find something that ties all the pieces together (renderers, reconcilers, hooks, lifecycle, events, etc). Something similar to the following, but for React

Cora (she/her)22:02:19

feels like a job for mermaid-js, time to make it šŸ™‚

Cora (she/her)22:02:53

I mean it's all a render loop with hooks to call functions at specific times so there's not anything clean like that, I don't think

Cora (she/her)22:02:03

oh, I guess that does loop, though


I also don't mind pencil and paper


For react, I think overview isn't a bad mental model, but I just need to turn several parts red.

Cora (she/her)22:02:37

pencil and paper is great, too!

Cora (she/her)22:02:55

I love wizard zines and it conveys so much with hand drawings

šŸ¤Æ 2
wizard 2

yea, those are really good!