Show HN: WebReducer – micro event sourcing cloud function (webreducer.dev)

10 points by zekenie ↗ HN
Hey everyone, WebReducer is a project I've been working on since last December. You can read about my process here: https://offbyone.us/tags/micro-business/

Send some data to WebReducer. Then, write a reducer function to retain some state. You can change the reducer function as much as you want and recreate that state.

Still working on how to explain it. It's a tiny FaaS platform. It's a tiny database. It's micro event sourcing. It's "redux" on the server as a service. It's a backend for tiny personal projects. It's a place to send your webhooks.

I'm looking for feedback on the following:

- Do you get what it is?

- What would you use it for?

- What would I need to iron out for you to seriously consider trying this?

7 comments

[ 2.4 ms ] story [ 25.5 ms ] thread
This is pretty nice. Doesn't seem to be working at the moment.

- Do you get what it is?

It's a tiny serverless nodejs platform that comes baked in with a global state store. Supports updates via websockets as well.

- What would you use it for?

If I had to use this for home automation, perhaps have it remember if the "light was on or off" to get toggle functionality to something that doesn't have it.

Reminds me of napkin.io except for the websocket endpoint.

Thanks! What wasn't working for you? Were the requests not coming in? I think I've fixed that. Sorry about that.... HN peak!
Oh and the other difference between this and Napkin is that this is stateful. Return something from the reducer to store a new state object
I think this has potential, but right now, it's complex for me to understand or use. My use case was an extremely simple counter I could use everywhere. Sometimes I want to track something but I don't want to go through the hassle of setting up analytics properly. But it seems the /write/ URLs don't support GET at all, which makes it unsuitable for that.

I can share some feedback if you'd like. Feel free to ping me on my email.

webhooks + state + websockets + micro events in a node.js FaaS is an interesting idea even if it is an antipattern of sorts.

I can see myself using it as a side car to a mission critical event sourcing setup. For bug reports, graceful batch restarting of user websockets when my real-time app goes down for maintenance. auxiliary things you may not want managed internally at key times.