Rust10x Blueprints: What Are They?

Context

First, let's get some context and the genesis of Rust10x.com.

After decades of building production applications, primarily highly interactive enterprise cloud applications, I, Jeremy Chone, decided to crystallize all our experience into building a new modern scalable set of application code blueprints and patterns to build high-quality cloud and device applications.

As I believe Rust is a transformative language in terms of code efficiency and developer velocity (quality & speed of delivery/iteration), this effort is primarily focused on Rust and building applications the Rust way.

There are going to be 2 main blueprints:

• rust-web-app, which aims to become a multi-service cloud applications code base. This is the most advanced Rust10x blueprint to date.
• rust-desktop-app, which will be based on the previous AwesomeApp and will be migrated to Rust10x with an updated code base.

This effort is supported through various channels:

• My YouTube Channel (https://youtube.com/jeremychone)
• This Website (https://rust10x.com)
• Discord at Jeremy Chone Server #Rust10x
• A set of GitHub repos for the blueprints (https://github.com/rust10x)
• More casual patterns and code samples (https://github.com/jeremychone-channel)

Blueprints vs. Frameworks

One very important aspect of our approach is that Rust10x Blueprints are NOT frameworks. Instead, they are fully functional code bases that demonstrate how to implement key aspects of production applications, allowing developers to either start their application with them or cherry-pick patterns they find fitting for their code design.

In fact, one of our key strategies for flattening the complexity curve is to prioritize Architecture First over Easy First, even if this often means starting with a slightly higher level of complexity.

All-in-one-solve-it-all frameworks can be very appealing because they allow for a quick and "easy" start. However, as the application grows, the point of diminishing returns can arrive relatively quickly, and complexity can escalate rapidly.

In many ways, it's not the fault of these large frameworks, but rather the nature of attempting to incorporate too many facets into the same system (library, framework, services), making it inevitably more complex to perform some specific functions that did not fit initially.

Obviously, the goal is not to swing to the other extreme and avoid using any framework at all. For example, Axum is a great "micro" framework that provides the right level of abstraction for its domain (Web Routing & Request Flow) without trying to solve all higher-level web application patterns. This "micro-frameworks" approach makes them leaner, more composable, and therefore more scalable.

So, our approach when choosing technology for our production application code is to prioritize the smaller, focused tools that solve a problem we do not need to address ourselves, but that get out of the way so we can solve what we need in the way we want.

Why Rust?

While we have been writing relatively large applications in Java, Node/TS, and have invested quite a bit in those languages, from our perspective, Rust is a transformative language that offers enough unique attributes to become one of the highest net value languages for building high-quality applications at a high-velocity cadence.

Here are the key unique attributes of Rust:

• Memory Safe at C/C++ speed and memory efficiency.

  • Until Rust, we either had to take the responsibility of coding memory-safe code in C/C++, or be okay with accepting the memory overhead of some GC (Garbage Collected) languages such as Java, Go, Node, etc.
  • In cloud or even desktop environments, memory is not cheap, and GC language runtimes can require an order of magnitude more memory than their C/C++ and now Rust counterparts.
  • This characteristic can make a big difference in terms of reach for cloud or next-gen desktop/device applications (the same service/application can run on more devices and in greater numbers).

• Thread Safe at C/C++ speed and efficiency.

  • Interestingly, this is a less discussed quality of Rust, but it's one of the biggest from our perspective, and it's something that even Java or Go does not provide.
  • Assuming we are not taking the unsafe route, the language/compiler ensures that our code is thread-safe, and we do not write data that can be read by another task/thread.
  • This is huge, as now, normal development teams, without decades of C/C++ experience, can build fast, multi-threaded applications for desktop and cloud environments at C/C++ speed.

• Modern & Scalabe Language suitable for writing small to large code bases.

  • Rust's design as a modern language supports the development of applications ranging from small to large scale, providing advanced features like pattern matching, zero-cost abstractions, and a powerful type system, all of which contribute to both the safety and efficiency of the code.
  • While some might miss class inheritance, we have found that Rust's language constructs (enums, match statements, etc.) actually force us to design code in a more scalable way than we would have with a traditional inheritance approach.

• Rust Tooling and Ecosystem are becoming unparalleled for creating multi-platform applications and services.

  • Rust's cross-platform tooling, unit testing, documentation, and its focus on runtime efficiency and safety have allowed the ecosystem to mature into one of relatively high quality.
  • Nothing is perfect, but we have been quite impressed with the quality of many libraries and frameworks (e.g., Axum, Tokio, Tauri, SurrealDB, to name just a few).
  • The fact that major companies, such as Amazon and Microsoft, as well as open-source projects like Linux, have been embracing Rust, really cements this language for the long term and is proof that it has crossed the "just another cool language" chasm.

Also, interestingly, many of our architectural and code design approaches, which seemed somewhat against the grain in other languages and their ecosystems, feel more fitting in Rust.

For instance, libraries are more focused, and even large frameworks tend to split their key components into completely independent libraries, aligning well with our preference for "smaller libs" and "micro-frameworks" kind of code design. Here are a few notable examples from the framework side:

• sea-ql has split its SQLBuilder layer (sea-query) out of their ORM framework (sea-orm).
• Tauri, which we are using in our desktop/device application, has divided its cross-platform WebView (wry) and cross-platform Windowing (Tao) into their respective independent libraries.

And for bigger applications and systems, the Cargo tooling, include Workspace and Features, can really help organize and scale the code relatively well while minimizing custom tooling complexity.

So, all in all, we believe that Rust is a great fit for our architectural approach and, while not perfect, it has somehow been the "programming platform" we have been seeking for quite a while.

What about the learning curve?

Two points on this:

1. Fixed cost, for recurrent returns.
2. A Great Filter for patient developers. (easy == evil in software architecture)

Conclusion on Rust

In short, the Rust language and ecosystem is fitting our architectural approach very well, and we are glad we this new platform (language, tool, ecosystem) to write our production cloud and device applications and share our blueprints with th ecommunity.

Are the Rust10x Blueprints Ready for Production?

As of February 2024,

• Rust10x rust-web-app is the most mature but will undergo significant evolution.

  • It is multi-service ready (with the crates/... code layout), but needs to add the Kubernetes Driven Development layer.
  • There is still a need to expand the data model to make it more production-like (e.g., org for multi-tenancy, space or project to contain Agent and/or Task).
  • It needs to implement the concept of Workers under crates/services/worker-... to perform asynchronous jobs.

• Rust10x rust-desktop-app is currently my focus, for a major code re-layout (from AwesomeApp) and update following the Rust10x rust-web-app code architecture. In fact, many of these libraries could be shared across some projects.

Conclusion

While providing a specific timeline for the various components is challenging, I am actively creating and maintaining these blueprints as I also use them for my own production applications. This approach is part of how we onboard developers onto our various projects. Consequently, although not complete, these blueprints are the real deal, at least in our context.

I hope this clarified a little bit what Rust10x Blueprints is about and its context. Looking forward to seeing you on the Discord or YouTube channel.

Until next time, happy coding!