What is the quickest and dirtiest way to store a ratom on a server?

118 views Asked by At

Periodically, on my super simple web app, I will want to reset my app state (which is in a reagent atom) back to a pristine default. Before I do, however, I want to send my sullied app state off to a server for hoarding purposes. It will have data about the things the user did in my app. I might want to retrieve that app state later to my front end. I could even get that ratom from where I stored it and swap it back in and see my app just as it was before it was all reset.

So, to get all that coolness underway, what is the quickest and dirtiest way to stuff that ratom somewhere?

I will want to store that app state each time I reset my app. The user resets the app a bunch of times in a session. Because of that there will be lots of instances of the app state to store on the server... both for a single user session and across different user sessions. I also may want to do things on the server... poke through the stored states and maybe make new endpoints where I can get analytics on them and so on. So however it's stored would be nifty to be able to peruse server side. Lots of the solutions online are awesome seeming but look... deep.

How can I get started on this easily? If it's a simple initial step of those more complex solutions, cool... I could expand later. Side note: Crux would be cool but it looks complicated. I'd need an easy on ramp. I am using reagent on my front-end. I am happy with whatever ajax type tool would be easy. I am unsure on how I pack my state up on the client side and unpack it on the server side for storage. Sorry for the somewhat broad question here: I'm just trying to keep having fun on my project and not go down a two week rabbit hole. I might get stuck down there and never emerge.

1

There are 1 answers

4
Biped Phill On

Quickest way to hoard but stay focused on the client side? Serialize the state as a string with (pr-str @rat) -- the reverse operation would be clojure.edn/read-string if you ever need it -- then send the string to the server as a ? parameter value on an inane GET request that you have not even programmed an endpoint for. Recover the stuff from your server logs later!

P.S. But you will definitely have to "go down a two week rabbit hole". The server side is the other fun part.