# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 18
# self = https://watcher.sour.is/conv/5wtfywq
@lukem You mean traditional RDBMS type databases?
@lukem You mean traditional RDBMS type databases?
@lukem You mean traditional RDBMS type databases?
@prologic In my case it was a MongoDB document store but I generally dread working with anything that (a) deals with user-generated data, (b) requires special treatment when it comes to backups and (c) cannot be easily fixed in case of a destructive event. It takes a lot of my brainpower while offering very little value in return.
@prologic In my case it was a MongoDB document store but I generally dread working with anything that (a) deals with user-generated data, (b) requires special treatment when it comes to backups and (c) cannot be easily fixed in case of a destructive event. It takes a lot of my brainpower while offering very little value in return.
@lukem I couldn't agree more! That's why I LOVE Bitcask 😍
@lukem I couldn't agree more! That's why I LOVE Bitcask 😍
@lukem I couldn't agree more! That's why I LOVE Bitcask 😍
@prologic fortunately for my post-release sprint I'll migrate to a dedicated solution that didn't exist when I was starting. Hell, it's about damn time.
@prologic fortunately for my post-release sprint I'll migrate to a dedicated solution that didn't exist when I was starting. Hell, it's about damn time.
@prologic but I looked at the projects of yours and they look cool! I use plain ol' Redis for basic caching and I wonder if I could replace it with Bitcask or Bitraft.
@prologic but I looked at the projects of yours and they look cool! I use plain ol' Redis for basic caching and I wonder if I could replace it with Bitcask or Bitraft.
@lukem Use Bitraft at your own riskβ„’; However it is based on Bitcask, it just isn't very well designed, maintained and its really (_at this time_) just a "toy". Bitcask however is a serious key/value store that scale! It of course powers all Twt.social pods like this one! Its very highly efficient at what it does and incredibly low latency for read/write workloads. 😎
@lukem Use Bitraft at your own riskβ„’; However it is based on Bitcask, it just isn't very well designed, maintained and its really (_at this time_) just a "toy". Bitcask however is a serious key/value store that scale! It of course powers all Twt.social pods like this one! Its very highly efficient at what it does and incredibly low latency for read/write workloads. 😎
@lukem Use Bitraft at your own riskβ„’; However it is based on Bitcask, it just isn't very well designed, maintained and its really (_at this time_) just a "toy". Bitcask however is a serious key/value store that scale! It of course powers all Twt.social pods like this one! Its very highly efficient at what it does and incredibly low latency for read/write workloads. 😎
@lukem To give you an idea of its kind of performance characteristics, when we were leaking sessions here on Twtxt.net I fied it, but also had to write a cleanup job for the "production data". I was a _bit_ worried that the startup would take a while and effectively cause a downtime while it was running the cleanup job on startup to nuke all the "leaked" sessions. Nope! To my surprise it nuked all the ~450k sessions in a matter of seconds! πŸŽ‰ (_of course I'm not really sure why I was surprised! 🀣_)~_
@lukem To give you an idea of its kind of performance characteristics, when we were leaking sessions here on Twtxt.net I fied it, but also had to write a cleanup job for the "production data". I was a _bit_ worried that the startup would take a while and effectively cause a downtime while it was running the cleanup job on startup to nuke all the "leaked" sessions. Nope! To my surprise it nuked all the ~450k sessions in a matter of seconds! πŸŽ‰ (_of course I'm not really sure why I was surprised! 🀣_)_~
@lukem To give you an idea of its kind of performance characteristics, when we were leaking sessions here on Twtxt.net I fied it, but also had to write a cleanup job for the "production data". I was a _bit_ worried that the startup would take a while and effectively cause a downtime while it was running the cleanup job on startup to nuke all the "leaked" sessions. Nope! To my surprise it nuked all the ~450k sessions in a matter of seconds! πŸŽ‰ (_of course I'm not really sure why I was surprised! 🀣_)_~