top | item 12726626

(no title)

ruler88 | 9 years ago

The concept is fantastic. I do think that some details need to be ironed out for it to be developer-friendly.

Good: 1) I love higher abstraction for things that just work. I hate writing boilerplate code to do simple stuff. JS and Redis caching is one that I often have to write boilerplate code for. 2) Cheap and simple way to improve performance.

Bad: 1) Lacking fall-back mechanism and transparency about what would happen if error occurs, connection dies, etc. 2) One common reason (at least for me) people use redis caching instead of local caching is to have caching across difference servers or even services. How do you deal with conflict resolution and asynchronous operations?

discuss

order

z3t4|9 years ago

Scaling solutions will always look different ... I think the idea here is that you have a one to one relation between the app and the database, so that the session data is not lost when the app restarts. And apps tend to restart often, especially during development. You might also store state history for easier debugging with time-travel.