Hi there friends! Reposting our team’s manifesto since the original post from months ago was scrubbed when its OP deleted their account.

This is based on the version from our repo and probably a bit rougher around the edges than what was posted initially, but it helps outline the goals and reasoning behind formally forking our project from Lemmy.


Our fellow Chapos,

The current rust backend has a lot of Technical-Debt™; we’ve made several critical changes that have let us scale to 10k+ users and had to put out a lot of fires on the way. These changes have also left us in a state where merging upstream Lemmy is a large job even if we would do it weekly to keep up.

We as a team feel we have hit a dead-end or brick wall with continuing to maintain the current backend in rust as-is while maintaining upstream compatibility. Additionally, there are several architectural changes we would like to make that would both require forking and a significant rewrite of the current codebase.

Since a rewrite is inevitable and rust/choice rust libs have shortcomings or simply aren’t ready for maintaining a production load web server, we have decided to use a new language. On the human side, the “core team” feels that the current tech stack is painful or slow to work with, makes onboarding difficult, and has been a turn off from getting new contributors. So-

Goals

In the short/mid term we want to:

  • Convert majority of client requests to the rest api away from websockets
  • Build a v2 api with the goal of splitting the current request/response objects up (ie. make it possible to query smaller data sets so a User component isn’t getting irrelevant data, basically make an actual modern/“standard” api)
  • Use a mature query builder that allows rewriting the sql queries/joins to be sensible, not reliant on cross joins, can properly filter based on inputs etc

Why Rewrite?

In technical specifics

  • Rust compile times are frustrating (30+ minutes per compile)
  • Many Rust libs are not mature enough for a small team web server to be a good idea, nor is the query building/orm side without strict limitations

In human terms

  • Some of us are facing severe burnout on Rust or don’t find it fun for this project’s specifics
  • We’re finding it difficult to keep contributing fixes because we have to code in a reactionary style and Rust does not lend itself to getting something quick done
  • Rust learning curve is steep or the lang itself turns away new contributors

Why Typescript?

Technical:

  • It offers typing/auto-complete/other goodies to JS
  • The ecosystem has many mature libs web servers, middleware, querying, testing, documentation
  • Iteration is quick and our BE/FE tech stack would be similar
  • We do not face any optimization/performance issues that make compiled langs needed

Human:

  • Most of us are familiar with TS/JS already
  • Learning curve is small and we can maintain a codebase that is friendly to new devs or even someone new to coding
  • The TS community is very friendly, welcoming and focused on accessibility. It’s extremely fast growing and immensely popular for web projects- As such it offers the best chance to sustain the project via new members

Conclusion

Most importantly, we want this to be fun, even if that means putting in the work to fork and rewrite in a new language.

There will be new pain points, new tech debt, and many human hours of work to even bring this to current 1:1 functionality, but that is worth it if the end result is something we own, enjoy and can easily share.

We encourage everyone in the community who is as passionate about Hexbear as we are to pitch in and contribute to the project. Here’s our getting started guide.

Thanks for reading and Viva La Hexbear!

:hexbear-shining: