rustypaste v2

[tessus]

Continuation of #433 as a new discussion...

I think there are a bunch of things that would be nice and could be implemented step by step. The thing is that the current rustypaste is very simple on an architectural level (fs access only, no db, no user authn/authz (except token access)...). While other features would be nice they are not really necessary. rustypaste does what it was designed to do. Period.

And here comes the.... wait for it... the "however".

Rust is very good in optimizing code and even a huge list of dependecies can be compiled into an efficient and highly performant binary.

For rustypaste v2 I would imagine a shift of frameworks and philosophy. Start simple, but keep the options open for expanding its features, either by adding them to the core or via a plug-in system.

For starters, I'd replace axum with rocket. Then I'd add diesel for the storage backend (everything but the files). e.g. I like sqlite for local databases (single user), but despise it for server applications. I come from a DB background and we can discuss this in a sepatate thread. On the other side, do we expect thousands of concurrent users accessing rustypaste v2? Either way, my point is with diesel we can allow people to choose the db backend (sqlite, mysql, postgres).

I really like the idea of 0x0.st's moderation TUI. Something like that could be added later with ratatui, given that the v2 architecture provides a proper REST API.
A proper API would allow for other things in the future as well: e.g. a react web interface (either compiled into rp v2 or as a seperate product, whatever tickles your fancy. Personally I suck at frontends and I'am really bad with coding stuff like that.)

The filesystem-only architecture was simple, but made rp rather limited feature wise. Many optimizations or new features (user/group authn/authz) are complex (or more complicated) to implement. e.g. for #367 the fix with a db backend is trivial. But with the current architecture it involves multiple filesystem operations, including proper locking, which in turn is basically reinventing a transactional rdbms.
Not that I am saying a user authentication/authorization feature is required, but if something like that came up in the future, using a db backend would make things a lot easier.

It might sound old fashioned in the age of agile (non-)development, but a SW requirements specification document would certainly help. I found that, while creating one, design issues are found early on and can be rectified before implementation actually starts.

Personally I am happy with rustypaste as it is. But if more features are wanted, the architecture and design philosophy will have to change. Thus v2 or ng (or if you are a star trek fan: tng).