Rubik aims to be a fast, scalable and productive Web framework for Go, by composing pre-built blocks of code to fasten the development process. It offers:

  1. 🟢 Writing server-side code for faster backend development using gen command.
  2. 🟡 Generating client SDKs for your backend on the fly for better/fast integration of frontends.
  3. 🔵 Debugging your APIs quicker with Rubik REPL.
  4. 🟡 Communication between services with it's own Messaging Passing layer and includes Event-Driven Development.

Rubik has a robust/thin layer of Go's reflection (which is optional) supporting the whole framework and provide many simple high-level APIs for handling complex tasks. The directory structure of Rubik is minimal and effective.

Why Rubik?

Rubik Framework for Go is a part of "Rubik Project" which was started in light of use-cases where you want stability and speed in creating your ideas and making it to life as quick as possible. It provides with a layer of abstraction so you don't steer far away from Go's standard library and use great tools to get you started with web development in Go.

If you are new to Go and want to create a web app easily and quickly with familiar architecture as most frameworks from different languages Rubik is the best way to create your app.

Is Rubik stable?

No, currently it is not!. The implementation of this project is being done in such a way that you will not have to think about anything while implementing your ideas. It should feel natural just to use Blocks and inbuilt tools while working on your ideas and "Rubik is not there yet." But it is stable enough to quickly create prototypes of your ideas.

How can you help Rubik Project?

  1. You can help Rubik Project by trying it out and helping us fix bugs as quickly as possible to make this project stable.
  2. Contributing with Pull Requests with potential fixes and features.
  3. You can make this project sustainable by donating us to make Rubik more of a main and serious attempt to create a framework that is "fast, flexible and solid", instead of this being developed in our spare time.


  • Keep a small core
  • Support Extensions
  • Simple and Descriptive with structural composition instead of functional
  • Extensive tooling and Automation with projects that blends well with the Rubik ecosystem
  • Avoid Repitition of common logic, "if one of us develops a foreign implementation it should be for all of us"


🟢 Solid 🟡 Flaky 🔵 Implementation Undecided