Hey Rustaceans, I’m building a secure, production-grade CMS with Axum, Yew, Diesel, and Trunk. It is designed to replace Wordpress and Elementor.
Repo: Thank you for your attention on this matter. 
JB
Hi @space-bacon !
It is nice to see that different CMS solutions built on Rust are emerging as alternatives to wordpress alikes. I believe the world should move away from imperative and slow systems to more optimized and reliable solutions, such as utilizing an immutable base and layering changes on top of it. While I believe I am not qualified to perform a helpful code review, I would like to share a few suggestions.
(Disclaimer, I am also developing a CMS solution called Yelken).
To begin with your repo’s readme, I believe it is mostly generated with an LLM. I am not opposed to usage of LLMs (even though I have not used an LLM yet), however, your current state of readme includes some duplicate parts which makes reading it hard (like Why This CMS? mostly overlaps with overview). You may want to prune them to improve the readability. There are also a few cases where incorrect information is presented (such as in Environment Setup, I could not find the mentioned .env.example).
I quickly skimmed through the backend part of the repo. First notable thing is the blocking database operations performed inside the axum's async handlers and middlewares. While this will not be noticeable from user perspective and may not become an issue at all, I believe it is not idiomatic to directly perform blocking I/O operations like running diesel database queries. it just defeats the purpose of using a web framework built on an async runtime as most of the time is spent on the database access for a CMS. I can suggest you to move these operations inside tokio's spawn_blocking. Or you can even use diesel-async for diesel related operations.
For user authentication part, while your config file includes a jwt_secret field, it is not used at all. Users are authenticated with a session token which is a UUID generated during user login. This lacks cryptographic verification which prevents you ensuring that received token is definitely generated by the backend. I can suggest you to utilize jsonwebtoken crate to generate tokens and verify them cryptographically. This may also eliminate storing tokens into database if you design this part carefully. Secondly, you might want to combine user passwords with a salt while hashing them to prevent having same hash for two users who use same password.
As far as I can tell, you are rendering public pages in the client side. While this is fine for some of the CMS use cases, rendering pages on the server is better in my opinion as it helps in SEO (I heard that client side rendered javascript applications can be crawled by some search engines, however, I am not sure if this is the case for webassembly applications). It also helps reducing first time to interact of the page (at the expense of increased compute cost on the server).
I also have some suggestions in terms of organizing your backend (or frontend) project. As you have a nice RESTful API, you may want to split your backend project into multiple crates for each management api (such as having a user crate that handles User Management APIs). This can have a positive outcome in your compile times and enable a composable backend (e.g. you can completely opt-out media related APIs and not include in the final binary at all). However, this can turn into a challenging task if those APIs are strongly coupled to each other and hard to split them into separate crates.
I hope you can get the outcome you are expecting from your project 
.
3 Likes
Good catch on the LLM generated readme. That is accurate. I vibe coded the entire project in cursor the last 7 days or so after sitting on the original idea for a year or so with basic functionality.
________
Thanks for the thoughtful (and human) critique — your input helped shape key improvements to the project. Here's a summary of what has been addressed based on your feedback:
• 
The README has been restructured to reduce duplication (particularly between “Overview” and “Why This CMS?”), and now provides clearer, more useful information about the stack and design goals.
• A `.env.example` file has been added for consistent environment setup.
• Authentication has been fully transitioned to a secure session-based system. Tokens are UUID v4 values stored and validated server-side, with optional HMAC-SHA256 signing using `session_secret`. The previously unused `jwt_secret` was removed to reduce confusion. Full rationale and implementation details are in `AUTHENTICATION_ANALYSIS.md`.
• Passwords are hashed using `bcrypt`, which automatically handles secure salting internally. No additional manual salting is needed, as clarified in `PASSWORD_SECURITY_ANALYSIS.md`.
• 
Diesel queries are still synchronous. Migration paths — including `diesel-async` and `spawn_blocking` — are documented in `ASYNC_DATABASE_MIGRATION.md`, with migration planned after the v1.0 milestone.
• The frontend is client-rendered via Yew (WebAssembly). While performant, this can affect SEO. I’ll evaluate server-side or hybrid rendering options for future iterations.
• 
The backend is currently monolithic for rapid development, but modularization into crates (e.g. per domain like users/media) is under consideration post-MVP, once tighter coupling is resolved.
Each of your points has led to real improvements or is actively tracked for future work. Thank you again for the constructive and practical feedback.
Some of this response was generated with LLM assistance.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.