Right now, Ktor feels like it could really benefit...
# ktor
j
Right now, Ktor feels like it could really benefit from some service abstractions (i.e. cache, database, filesystem) in a centralized spot. I have a server framework I run on top of Ktor that has a bunch of these abstractions, and I'm thinking about moving those abstractions out to where other Ktor users can use them. It's fundamentally based in KotlinX Serialization, so for example, the database abstraction uses normal data classes with annotations and KotlinX serialization for managing tables. I've currently got email (SMTP/Mailgun), SMS (Twilio), database (MongoDB/Postgres), cache (Redis/Memcached/DynamoDB, pub/sub (Redis), and external file systems (S3 / AZBS). All of them have local mocks too. Would anyone here be interested in a set of libraries for abstracting database/cache/email/file systems oriented around KotlinX Serialization? Just trying to gauge interest.
j
I would love to see it! We currently have a set of libraries published at https://github.com/hudson155/kairo which my company uses for things like this. We have one for Slack Postgres and many others. We are currently working on a Redis one We use Jackson instead of KotlinX because it (at least when we started the company) is a lot more versatile. The library-of-libraries pattern is really nice
j
We used Jackson initially too, but migrated away from it after a while. I'm taking a look at yours!
j
Some of the documentation leaves much to be desired 😅
j
don't worry about it, you should see mine
j
If you end up publishing, I'd love to see it. Might provide some guidance on how we can migrate to KotlinX 🙂
j
Already published the server framework - it's called Lightning Server and I'm quite proud of it. https://github.com/lightningkite/lightning-server ...maybe not so much the documentation though. Such is the beast.
❤️ 1
j
amazing, I love the sample
how easy is it for your DB approach to support things like Postgres JSONB?
j
We don't right now but I don't think that would be particularly difficult Right now lists, sets, and maps become array columns
We've been using this in production in Lightning Server, it just has to be ported over to the abstractions library