aws-cdk-rfcs VS websocat

This was the most voted RFC.

The scheduler is a refined and improved version of the older rules mechanism. So, why would you use the older rule mechanism for scheduled tasks? I don’t see any reason other than the better CDK constructs support (which is only temporary, see this PR).

CDK released the L1 construct for Pipes in v2.55 back in December 2022. Unfortunately, the L2 construct is still in progress, so we will have to manually specify most of the CloudFormation template but bear with me, it won’t be too painful. The community is working on an L2 construct; you can find the issue on GitHub here.

The experimental cdk feature is described here. The rfc is still open so you might be able to track or influence how it will stabilize.

More info on L1 vs L2 constructs here. I plan to keep an eye on this open RFC.

You could hardcode the stack names. But this is one of the biggest limitations CDK still has: no easy way yet to refactor names like this. There's an open RFC, but it isn't moving much.

It is not very convenient to delete some resources manually and there are several discussions with AWS developers to fix it.

It's worth mentioning that AWS CDK already has an RFC for integration testing so we might end up with something even better. In the meantime, if you are serious about integration testing, time to give AWS CDK and Provider Framework a look!

One apparent limitation of the CDK is that, at least for the nonce, it can only be used with AWS (there are two notable projects in the work right now that will greatly expand CDK's reach: cdk8s and cdktf). With Terraform you can use choose from a plethora of providers. Hell, I was able to set up my home network running on Unifi Dream Machine using Terraform. How cool is that?!

It's similar to running netcat in server mode, wrapping a script. It's even closer to doing that using websocat [1], whereby one does not have to do the websocket header juggling.

The main difference is that while netcat or websocat will spawn a new process for each connecting client, ScaleSocket has a concept of rooms (channels). For a room, a process is spawned once only. All clients connecting to the same room are routed to the same process. This is not straight forward to do using the forementioned tools.

There's a small comparison page [2] where I have mentioned some alternative tools.

[1] https://github.com/vi/websocat

one combination I came to really love this year is babashka (https://github.com/babashka/babashka) + websocat (https://github.com/vi/websocat). I wrote about a method of live web programming with this pair at https://github.com/whacked/cow/blob/main/a%20technique%20for...

babashka isn't strictly necessary; you can also pipe plain text, but pushing hiccup expressions to the browser DOM from the REPL with instant feedback has opened a new world of interactive programming for me.

No... the core of it is a django instance in the cloud with a Vue front end (what you're seeing in the screen shot). To push data in, the client connects to a websocket (using https://github.com/vi/websocat) and push key/value pairs in. I'm not in the middle of gameplay at all.

There's really nothing to this. I just have to provide the bus name and an optional pattern. Now using websocat, I get output like this:

Subscriptions is real-time streaming of data from server to client through WebSocket. You will need a constantly active connection to stream such events. You cannot use curl for this and have to use a WebSocket client like websocat if you want to access it via command line. Once executed, a stream of pending transaction IDs will start flowing in.