Hi everyone,
I’ve been working on a framework called Jazzy for a while now, and I’m finally sharing it with the community.
I built Jazzy because I wanted a tool specifically focused on building REST APIs. While there are great web frameworks in the Nim ecosystem, I often found them either too complex or requiring too much manual setup for basic needs like database integration and authentication.
I’ve already used Jazzy in a real-world project, and it handled all my requirements smoothly. After seeing it perform well in practice, I felt it was time to share it.
Jazzy aims to be a "batteries-included" solution for API development. It comes with:
It’s currently at v0.1.2 (Early Alpha), so there are definitely things to improve. I’ve set up a website and some documentation to help people get started. It’s also available on Nimble if you want to give it a quick try.
How to support? I’d really appreciate any feedback or bug reports. If you find the project interesting, leaving a star on the repo would mean a lot to me.
If you’d like to contribute, PRs are welcome for both the core framework and the documentation.
Links:
GitHub: https://github.com/canermastan/jazzy-framework
Website: https://canermastan.github.io/jazzyframework/
Docs: https://canermastan.github.io/jazzyframework/en/
Update: JazzyNim v0.2.0 is out! 🎷
I've just released version 0.2.0, which introduces a built-in Thread-Safe In-Memory Cache system. It’s designed to be dead simple and just works out of the box.
Here is a quick look at how you can use it:
- Store a JSON value for 1 hour (default)
- ctx.cache.put("latest_stats", %*{"users": 100, "active": 20})
- Retrieve it easily
- let stats = ctx.cache.getJson("latest_stats")
- Or get a string with a default value
- let theme = ctx.cache.get("user_theme", "dark")
Project Status & Development
The project is under very active development, and we've already started working on v0.3.0.
We are currently building the first real-world production projects with Jazzy to battle-test every feature. Stress tests and memory usage analysis show very promising results the framework remains stable and lightweight. We are continuously expanding our test suite to ensure long-term reliability.
Any feedback or suggestions are highly appreciated!
I’m genuinely happy to hear this! It means a lot to me to receive such positive feedback from the community.
To answer your question: Jazzy is currently in its 0.2.x phase and is in very active development.
A few friends and I are actively dogfooding Jazzy in real-world projects (using a ReactJS + Jazzy stack). So far, the core functionality has been rock solid for our use cases, and we are constantly refining it as we find edge cases.
However, since the framework is still very young, I wouldn't recommend it for mission-critical or high-stakes production systems just yet. We are working towards a major v0.3.0 release which will introduce essential production-oriented features like a built-in Dev UI, structured logging, Request IDs and other features.
Even with v0.3.0, Jazzy will still be in its early stages. If you’re building a side project, a startup MVP, or an experimental tool, I’d love for you to give it a spin! But for anything where high availability and long-term stability are critical, it's best to wait until the framework matures further.
Wow, looks like v0.3.0 is shaping up to be a great release — really looking forward to it!
I'm currently planning to build my own blog project and have decided to go with Jazzy. Do you have an estimated release date for v0.3.0? Either way, I'll be waiting for it. Thanks for your hard work on this!
Thanks for the support! I'm happy you're picking Jazzy for your blog project. I'm currently running the final tests and polishing the documentation to make sure everything works as expected.
v0.3.0 will likely be out tomorrow evening. If I run into any unexpected issues, it might slide to the day after, but tomorrow is the main goal. Thanks for your patience.
Major Update: Jazzy v0.3.0 is finally here!
We’ve been working hard to turn your great feedback into features. This release is all about Developer Experience and making Jazzy more "batteries-included" than ever.
What’s new in v0.3.0?
A huge thanks to the community members who suggested these features and contributed code. You are making Jazzy better every day! 💖
Check out the full release notes and changelog here: Jazzy v0.3.0 Release (https://github.com/canermastan/jazzy-framework/releases/tag/v0.3.0)
Thank you — this library is amazing. Your contributions will definitely pay off in the future.
I also tried to build a library myself, but unfortunately I didn’t have enough time to finish it. Still, I’d like to share a bit — if you’re interested, I hope you won’t judge it too harshly 😄
Here’s a sample of my code. It’s working, but not fully complete yet:
Controller Home("api/v1"):
[GET("index")]
[UseGuard(AuthGuard)]
proc index() = Http200 "Hello from HomeController! "
[PUT("users/:id")]
[UseGuard(AuthGuard)]
proc users(
id {.param.}: int,
name {.query.}: string,
user {.body.}: UserDto
) =
Http200 user
[GET("account/:id")]
proc accounts(
id {.param.}: int,
name {.query.}: string
) =
if name == "":
Http400 "erro"
Http200 "Hello from accounts! " & $id & ", name = " & name
[GET]
proc html() =
Http200 "<html>hello mf</html>If it’s possible to structure things in this style, I think it would be really great. What do you think?
Thanks for sharing this! I think creating a library is really a challenging task and I definitely congratulate you.
Actually, I really like the 'Spring/NestJS' style decorators ([GET], [UseGuard] etc. etc.) in other ecosystems. That's why I was very happy to see you did something like this when I looked at your code. However, when it comes to Nim, I think it creates a bit of complexity. That's why I don't like this style for Nim.
My goal with Jazzy is to keep everything as comfortable and memorable as possible. I think the current Route.get style fits the language's flow better and offers a simpler developer experience. Also, honestly, I struggle while typing pragmas like {.param.}, {.query.} from the keyboard 😄
You've done great work, if you finish the library I'd really like you to share it! Thank you very much for your feedback.
This is some really great stuff- love the batteries included approach.
A few things that came to mind off the top of my head- arguably frameworks like symfony could be done a lot more elegantly but are used anyway because they were used in many live projects and were not the cause of hacking. So some kind of explanation why e.g. the auth is secure and SQL injections don't happen would probably help folks who already want to use it.
mummy is threaded, so I don't quite understand how async-on-top works, and why it's good. Not saying it's not!! Just curious why it was done.
Hi! Thanks for the feedback. I really appreciate these questions as they help me refine the project's vision.
On Security
Security is definitely a priority, and your message reminded me that I should communicate this better to the users. Instead of going into deep technical details here, I’ll be adding a dedicated Security section to the documentation soon. For now, I can say that Jazzy’s ORM uses parameterized queries by default to prevent SQL injections, and we follow industry standards.
Why Async on top of Mummy? (The Future-Proof Approach)
This is actually where Jazzy’s core philosophy shines. Jazzy is my third attempt at building a Nim framework, and I designed it this way to solve the "limitation" issues I hit in the past.
Even though Mummy is a multi-threaded server and our current DB driver is synchronous, the core architecture of Jazzy is entirely async. Here is why I took this "async-on-top" path:
The goal was to build a framework that doesn't just work today but is ready for the Nim ecosystem of tomorrow.
@hieuht
Do you have a repo or a code snippet you could share? Specifically how you got the equivalent of "python decorators" to work in Nim? (those [GET("index")] lines.
It should be as simply writing a macro, but in the past, Nim never allowed for a list of left-aligned macros and/or procedure declarations to really connect to each other. It broke basic Nim syntax. It could get things to work with indentation; but that doesn't match decorator expectations of a lot of programmers.
But perhaps there is a work-around I'm not aware of? Or a new Nim feature? I'd love to learn more. Thanks!