A quite comprehensive summary. Are there any concrete plans how to proceed?

[zoechi]

Follow up to https://users.rust-lang.org/t/rust-in-enterprise-software-erp-maybe/126430/2?u=zoechi

I was thinking about this for quite some time.

My approach would be to build a low-code development environment for enterprises
and then use that to implement all kinds of ERP modules based on it that can be customized and extended by users and also allow the users to easily build their own modules.

The modules could be offered in an app store to encourage as many as possible to build modules and offer them to others.

Simple things should be simple and complex things should be possible.
Most enterprise requirements for custom modules are quite simple. I think it's most important to offer something that makes it really efficient to build something new and easy to extend it when users understand their requirements better and request more and more features.

There will be hotspots where more advanced development is required because a lot of functionality intersects at a certain point and performance becomes an issue. It's important that the system doesn't make solving this more complicated than necessary.

I'm not sure large scale is a viable target at the beginning. I assume at large organizations it's mostly about making safe decisions like "nobody ever got fired for bying IBM" and a new Open Source project doesn't easily meet such a requirement.

To gain traction I think it's most important to make it easy to install, use, maintain, and extend.
Allowing scalability when users grow is of course important. So, to target bigger organizations it would probably better to target smaller organizations and contribute to their growth.

I think Rust would be the ideal language.
The core could be Rust and then allowing all programming languages that can target WASM to build modules.

For scalability I'd start as Modulith (Modulith vs Microservices, I didn't really check how well this document describes the term).
With clear boundaries it should be easy to split out modules into microservices when scalability makes it necessary, but it would be much easier for initial development.

What do you think?

[casibbald]

Thank you for the response!

I wholeheartedly agree with the concept of: Simple things should be simple and complex things should be possible, as well as the modular approach.

I had thought of a scenario where the backend is built in Rust and facilitates a modular approach where new modules can be added and Wired up in such an easy way.

A single pane of glass UI that can have new components added is a great idea, using the concept of Micro Frontends.

I like your suggestion of WASM, so all front-end UI logic would be built in the backend and compiled to WASM target to be included in the UI.

I am a bit nervous about having any language used for modules (Primarily due to not fully understanding the security implications of such a decision), but this is not me saying it should not be done; just that I don't know how it would be implemented securely.

With regards to implementing new modules and contributing, I think the Odoo.sh build system implementation is well thought out; potentially building on that concept and taking it a bit further would be a good option.

Regarding deployment, I think targeting Kubernetes from day one is a good idea as users can use a Kubernetes platform of their choice, be it K3S or full-blown K8S in a flavour/provider of their choice.

I need to get up to speed with the article modulith-vs-microservices and how we would learn from such concepts.

Looking forward to more discussions!

[zoechi]

where new modules can be added and Wired up in such an easy way

I can imagine various ways like

• APIs for external services, (REST, OpenAPI, Protocol Buffers)
• shared interfaces for in-process calls on the same machine (for example for WASM modules)
• message passing (CQRS, message queues)
• version control vendor branches (quite involved but can enable maintainable customizations of complex code)

I am a bit nervous about having any language used for modules

WASM is sandboxed and prevented from accessing anything that's not explicitely allowed (files, network, system calls, ...) independent of the used source language.
Inside the application WASM modules would be limited to interact only through specified interfaces.

Security implications need to be well considered of course.
There need to be rules in place in the backend about who can read/insert/modify what data that cannot be overruled by business logic.
There might other things be worth considering, like code reaching outside its boundaries in the browser and accessing data or code, but I'm not up-to-date on this topic. This would be the same or worse with JavaScript though.

so all front-end UI logic would be built in the backend

My approach would be to use a lot of code generation from GUI developer tools where the generated code would be mostly Rust and infrastructure code for WASM modules.

WASM could be executed on the backend and the client.

On the backend it would mostly do business logic and data validation.
The same business logic and validation rules are often also useful in the frontend for various things like input validation or auto suggestions, without requiring calls to the server for everything.
With WASM sharing code between client and server would be possible and in my opinion desireable.

I think the Odoo.sh

I haven't looked closer at any of the existing OS solutions for several years. When I last checked I quickly run into things that put me off. I want to catch up but it wasn't high priority yet.

Regarding deployment

When larger organizations or cloud provided are the targets, I don't see a way around K8S.

[zoechi]

WASM modules are still a bit cumbersome, but we are getting there

• https://www.reddit.com/r/rust/comments/1hvaz5f/rust_wasm_plugins_example/
• https://extism.org/docs/concepts/plug-in-system/

[casibbald]

@zoechi
I have spent more time looking at the Modulith doc and pondered what it would all look like.

This brings me to questions like:

• How does the Frontend get partitioned for the Modulith and Microservice backends?
• What front-end tool do we use to wrap the Wasm modules served by the backends?
• If we allow freedom of languages for the backend, is it even a rust project or a hodgepodge of components that could become a maintenance nightmare?

Again I don't yet have answers or opinions to these questions.

[zoechi]

I just stumbled upon https://youtu.be/GOIYREEANEM?si=brzc1CF5c3S59BzM which I found a nice introduction.

[zoechi]

• How does the Frontend get partitioned for the Modulith and Microservice backends?

There doesn't need to be a difference. Just use what the GUI/Web framework supports. I don't have a strategy for non-web GUis. That would need some investigation.

• What front-end tool do we use to wrap the Wasm modules served by the backends?

Any web framework could interact with WASM. I only worked with Angular (2+) extensively, but WASM-to-JS interaction isn't tool or framework specific.

I haven't thought deeply about native apps but it would probably work just like on the server. WASM modules run sandboxed and communicate over predefined interfaces.

• If we allow freedom of languages for the backend, is it even a rust project or a hodgepodge of components that could become a maintenance nightmare?

The project could use Rust for everything. Rust can be compiled to WASM or compiled to binary.
There is no need to use other languages. WASM can just be used for sandboxing.

It's probably still desirable to offer other languages to users who want to build modules in a language easier to learn than Rust.
There could also be one officially supported "easier language" for modules that the project uses. I haven't found such a language that checks all the boxes.

[zoechi]

That's a valid approach for the client application.
I was thinking of WASM more for customizations of business logic and UI for people who want or need a simpler language than Rust.

[casibbald]

Agreed.
Providing WASM modules to call any backend APIs or run logic seems sound.
Then, a lowest common denominator tool for UI that non-rust developers can drive the backend logic.

some example combinations could be:
SolidJS + WASM Module + axum backend
React + WASM Module + axum backend
SolidJS + WASM Module + Loco-rs (wrapper on axum) backend
Flutter + WASM Module + (Variation of above backends)

I think the UI should not be pure rust as this will mean only backend engineers can produce the front end which might lock us up.

[luke-ransfield]

So when are we starting?

[casibbald]

Shall we put together some Top level diagrams to get a sense of how we would put things together? In my mind before we build any “ERP” systems we need to solve: 1. Main system and auth 2. Modularity and how we add new models to the base 3. How do dynamically configure them in if they are running in a separate microservice What do folks think?

…

On Sun, 6 Apr 2025 at 00:50, Luke ***@***.***> wrote: So when are we starting? — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6C3ZELZUEAGQNH4J2C232YBFZJAVCNFSM6AAAAABYGKAG2SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENZTG4YDAOA> . You are receiving this because you commented.Message ID: ***@***.***>

[luke-ransfield]

Sounds reasonable -- how do you/everyone want to go about this?

I'm only chiming in as a enthusiastic volunteer, I don't know how much I can offer at the architecture/high-level design side of things.

[casibbald]

Apologies for the late response, I have been buried in moving house/countries
So, how about we put together some architecture diagrams showing how each of us thinks the system should fit together and upload them for review?
I worry that if we work on the same initial submission, we won't have the creativity of independent submissions.

[casibbald]

I have seen the following example of using Rust & Wasm and SoldJS only for rendering:
https://www.reddit.com/r/adventofcode/comments/zkelkl/2022_day_11_part_1_rustwasmsolidjs_monkey_keep/

The interesting thing is all logic is in the rust/wasm layer, and kind of what I like cause it means the UI layer can be switched out a different framework should we find we don't particularly like the chosen Web Framework.

[zoechi]

I only worked with Angular but I think every framework can work. Perhaps just tailwind CSS and everything else in Rust. I'd also take care to keep UI rendering separate from any business logic.

[casibbald]

The link below is a very high-level representation of how I imagine an ERP that has components that can scale independently based on usage.
https://lucid.app/lucidchart/7154c4ab-f8d1-4f7d-8bb5-82f4858dd867/edit?viewport_loc=315%2C232%2C3071%2C1587%2C0_0&invitationId=inv_d5f0e0bb-a90c-4009-9391-03e504a8c3e8

[luke-ransfield]

None of these are dumb questions; they are all very valid questions

My thoughts were:

The core is not replaceable.
Periphery is entirely replaceable as long as it adheres to core contracts on auth, etc. So, it should be easy to replace the Core General Ledger with a country-specific GL or at least figure out how to make it more international. A GL module could also have its own ability to be extended.

Two manufacturing modules could be interchangeable, as they would run in their own container as long as they meet basic contracts [Microfrontend setup, API contracts]

Nice, this aligns with how I think about it.

Regarding CICD, take a look at the setup for Odoo. I think this may be a valid source of inspiration.

Are you talking about Odoo enterprise / Odoo sh?

Every component should be packaged as a Helm chart, considering microservices, allowing for easy portability between cloud platforms. With helm charts, you can easily pick and choose what you want, bring your own module (build your own), etc. This allows corporations to easily adopt the solution.

One of the reasons I suggested gRPS over rest is that each service can provide its API protocol and even generate clients that can be imported to any downstream component that will use that API, ensuring the API is respected.

I like this, but I'm still slightly confused (probably to with boundaries). A lot of non-developer users are working with things like PowerBI, low-code/no-code platforms, etc. They're not necessarily going to be able to write calling-code, but they are able to deal with REST or GraphQL -- but we can generate REST endpoints from gRPC? Depends on the sophistication of the users. Ideally they wouldn't need low-code/no-code platforms as the platform handles this, but in reality I can see this being a barrier to adoption especially for organizations looking to transition platforms.

I mention the platform because I looked at Odoo. While you can build your modules, it's designed in such a way that it's not trivial to call components, etc. So, I think that providing a facility for an organisation to use the base components and easily add their specialist component (say a dentistry component or some Lab management component) will generate some envy and interest in the solution.

We must move these concepts into a living document or set of ADRs.

Agreed!

[zoechi]

GraphQL is great for the right use case. Like you mention users exploring data or queries that span multiple services. Report designers would benefit as well for less data intensive reports. Where and how GraphQL can be utilized depends on other architecture decisions.

[casibbald]

• Are you talking about Odoo enterprise / Odoo sh?
  Yes, Odoo.sh has a built-in CI solution; however, this is tied into their release mechanism for deployment into their infrastructure.
  This is the primary reason I feel we should not be multi-language in the core or any component that sits in a 'marketplace'. However, corporations that would look to develop their own third-party module would use their own CI anyway.

In the diagram, I show an API-Proxy (IMHO, this should be a GraphQL to gRPC bridge, and then internally within and between microservices, we should stick to gRPC)

Shall we select an ADR template and write the first ADR to decide to use said ADR template? Which reminds me of the following Alice in Wonderland quote:

`Begin at the beginning, and go on till you come to the end: then stop. '

This discussion has led me to believe we should first forcus on building an "Application authoring platform", said platform should not have 'ERP' components in it, such that a power utility company could pick this up and run with it for their own application by adding their own modules.

So this could be the second ADR

[zoechi]

• Are you talking about Odoo enterprise / Odoo sh?
  Yes, Odoo.sh has a built-in CI solution; however, this is tied into their release mechanism for deployment into their infrastructure.
  This is the primary reason I feel we should not be multi-language in the core or any component that sits in a 'marketplace'. However, corporations that would look to develop their own third-party module would use their own CI anyway.

I also wouldn't "officially" support any language.
Perhaps Rust and one additional "simple" GC language like Python, Lua or similar as official plugin language. Everything else on their own risk.

In the diagram, I show an API-Proxy (IMHO, this should be a GraphQL to gRPC bridge, and then internally within and between microservices, we should stick to gRPC)

Oh, I missed that. Sounds good.

Shall we select an ADR template and write the first ADR to decide to use said ADR template? Which reminds me of the following Alice in Wonderland quote:

I use a very simple one in combination with adrgen but anything works for me.

# {title}

Date: {date}

## Status

{status}

## Context

What is the issue that we're seeing that is motivating this decision or change?

## Decision

What is the change that we're proposing and/or doing?

## Consequences

What becomes easier or more difficult to do because of this change?

`Begin at the beginning, and go on till you come to the end: then stop. '

That always turned out to be the right approach :D

This discussion has led me to believe we should first focus on building an "Application authoring platform", said platform should not have 'ERP' components in it, such that a power utility company could pick this up and run with it for their own application by adding their own modules.

I guess as soon as there is some basic functionality, we will start building components to see how well it works.

So this could be the second ADR

Can we just start a new discussion, perhaps an issue, about what ADRs to create?

I would have started with one ADR for each Node in #2 (comment) except some leaf nodes which are just possible options for the parent node.
If you want them more coarse-grained, I can work with that as well.

I guess we want a separate repository for ADRs?

[casibbald]

Regarding another repository,
I am inclined to use this repo for all the thought processes, since the discussions are on this one.
I placed an ADR template this morning, please feel free to add a PR to modify to trim the template.

Feel free to start new discussions, it is a public repo and we can foster inclusivity!

[zoechi]

I tried to come up with a list of high level decisions just to get started.
Some might already have obvious decisions.
Perhaps we can extract topics to start specific discussions or even start documents like ADRs.
We can add this as file to the repo so everyone interested can add or modify with PRs.

mindmap
  root((Rust ERP<br>Architecture))

    Frontend
      Programming language
        Rust
        TypeScript
        Javascript
      Microfrontend
        Granulatity
          Routing
          Communication
      State Management
      i18n/l10n

    Backend
      Programming language
        Rust
      Microservices
      CQRS
      Authentication
        External
          Okta
          Authentic
      Authorization
        RBAC
        ABAC
        PBAC
      Database
        PostgreSQL
        Multiple databases
      GDRP

    Communication
      Client-Server
        gRPC
        REST
        GraphQL
        WebSocket

      Microservice-Microservice
        MessageQueue
        gRPC

    Customization/Modularity
      WASM
      Microfrontend

    CI

    Deployment
      K8S/Helm
      Nix

Loading

[casibbald]

I recently got started with thrashing out an auth endpoint that would sit on top of Loco Frameworks routes as a middleware:

https://github.com/microscaler/seasame-idam

[casibbald]

@zoechi
@luke-ransfield
I spent the day building an Openapi 3.1.0 dispatch router that is coroutine-based and not using Tokio.

https://github.com/microscaler/BRRTRouter

Target is 1Million matches a second per CPU core. It should give us what we need performance-wise

[luke-ransfield]

Apologies @casibbald have been out on holiday -- this goes over my head but will jump in over the next few days and try and wrap my head around BRRTRouter and Seasame

[casibbald]

Hey Luke, No worries. I have just been looking at putting something together that will enable rapid progress with building APi’s BRRTRouter is a sub component to be used by a new API solution. A take on FastAPI and Loco See: https://github.com/microscaler/photon This repo just discusses a vision at the moment.

…

On Mon, 26 May 2025 at 00:48, Luke ***@***.***> wrote: Apologies @casibbald <https://github.com/casibbald> have been out on holiday -- this goes over my head but will jump in over the next few days and try and wrap my head around BRRTRouter and Seasame — Reply to this email directly, view it on GitHub <#2 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6C37YYUWERTCWDMTTFUD3AI3C3AVCNFSM6AAAAABYGKAG2SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMRWGYYDIMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[casibbald]

@zoechi @luke-ransfield I have been looking at options for the UI element of dashboards for web applications.

Below is an interesting ChatGPT comparison - MBOI !

Comparing Leptos (Rust/WASM) vs. SolidJS for Sesame‑IDAM Admin Dashboard

[zoechi]

I dug into Dioxus recently. I already tried it a year or so ago and failed miserably at the very beginning because of build errors about missing dynamic libraries and version conflicts on Linux.

A lot of work was put into it since and it improved quite a lot. Even documentation got much better.
A new version (0.7) is in alpha and they seem to prepare a component library for the release.
I haven't tried 0.7 yet, but the 0.7 component library code is a great resource for learning about state management with their signals.

The signals seem to be common in React-like frameworks and from what I heard are now even in Angular, but I haven't worked with any React-like frameworks myself yet and also not in Angular since they were introduced there.

I did a bit of research about how Micro Frontends could be accomplised. There is for example a package to build Web components from Dioxus pages that should make it possible to load parts dynamically, but I haven't done any tests. I'll look into this again later.

While some limited areas require conditional compilation, using the same code for desktop and browser is working well. I haven't tried mobile yet, but it should be mostly like desktop with just a single window.
I follow someone on YouTube who makes videos about his experience building an iOS app using Dioxus. He was struggling to get a custom app icon associated with the app, but otherwise it seems to work well for a simple time tracking app. So while it doesn't look perfect yet, it seems to work and just needs some more polishing.
Building a WASM based web GUI is working really well with Rust and Dioxus. I expected more issues.

I find it helps productivity a lot to be able to use the same language for frontend and backend, especially because of the Rust tooling which I prefer to npm & co. Not even starting about the benefits from sharing code between client and server.

The small set of available GUI components and libraries compared to JS/TS, requires to rebuild a lot from scratch which vaporizes the gains at least in the short term.

I'm still learning about more advanced use cases, but I can definitely imagine building everything using Dioxus and I really enjoy working with it.

If cross-platform isn't a requirement, then there are certainly other frameworks worth looking into.

I explored how to build client code to minimize dependency on a specific GUI framework, so that its as simple as possible to switch to a different GUI framework in case something better emerges for a specific platform like mobile, but here I need to build more concrete application code to be able to come to a final conclusion.

I had brief looks into the projects you created, but I don't really know what feedback to provide, this is why I didn't respond earlier. I'm currently really focused on finding the limits of building GUIs with Dioxus.

[casibbald]

So I am close to having an OpenAPI first designed request router ready for rust. You feed it an openapi document and it generates routes and handlers for you along with a corresponding side crate where you implement your core logic. Along with that I am working on a new wrapper that helps you rapidly scaffold out OpenAPI documents. I have spent a little bit of time playing with LLMs that can be used to train them to help you generate or scaffold your OpenAPI document etc. The objective is to enable a developer to rapidly y build out components and with these tools rapidly build out any systems. I still have a lot of stuff locally, will try get everything a little more polished and will push what I have

…

On Sat, 7 Jun 2025 at 16:44, Günter Zöchbauer ***@***.***> wrote: I dug into Dioxus recently. I already tried it a year or so ago and failed miserably at the very beginning because of build errors about missing dynamic libraries and version conflicts on Linux. A lot of work was put into it since and it improved quite a lot. Even documentation got much better. A new version (0.7) is in alpha and they seem to prepare a component library for the release. I haven't tried 0.7 yet, but the 0.7 component library <https://github.com/DioxusLabs/components> code is a great resource for learning about state management with their signals. The signals seem to be common in React-like frameworks and from what I heard are now even in Angular, but I haven't worked with any React-like frameworks myself yet and also not in Angular since they were introduced there. I did a bit of research about how Micro Frontends could be accomplised. There is for example a package to build Web components <https://developer.mozilla.org/en-US/docs/Web/API/Web_components> from Dioxus pages that should make it possible to load parts dynamically, but I haven't done any tests. I'll look into this again later. While some limited areas require conditional compilation, using the same code for desktop and browser is working well. I haven't tried mobile yet, but it should be mostly like desktop with just a single window. I follow someone on YouTube who makes videos about his experience building an iOS app using Dioxus. He was struggling to get a custom app icon associated with the app, but otherwise it seems to work well for a simple time tracking app. So while it doesn't look perfect yet, it seems to work and just needs some more polishing. Building a WASM based web GUI is working really well with Rust and Dioxus. I expected more issues. I find it helps productivity a lot to be able to use the same language for frontend and backend, especially because of the Rust tooling which I prefer to npm & co. Not even starting about the benefits from sharing code between client and server. The small set of available GUI components and libraries compared to JS/TS, requires to rebuild a lot from scratch which vaporizes the gains at least in the short term. I'm still learning about more advanced use cases, but I can definitely imagine building everything using Dioxus and I really enjoy working with it. If cross-platform isn't a requirement, then there are certainly other frameworks worth looking into. I explored how to build client code to minimize dependency on a specific GUI framework, so that its as simple as possible to switch to a different GUI framework in case something better emerges for a specific platform like mobile, but here I need to build more concrete application code to be able to come to a final conclusion. I had brief looks into the projects you created, but I don't really know what feedback to provide, this is why I didn't respond earlier. I'm currently really focused on finding the limits of building GUIs with Dioxus. — Reply to this email directly, view it on GitHub <#2 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6C33SDRVS32HBB64H3TL3CLUENAVCNFSM6AAAAABYGKAG2SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMZZG42DONI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MJTham]

As an IT who supports ERP for few years, I like the market store idea. And Rust deserves a good ERP.

Any action plan or a board to keep track the progress and any discord channel?

[casibbald]

I have almost completed the following base components: - web request router - database pooling system - auth system (need much more work) Once these items are done, we will be able to work on the actual ERP system built using these items. I have used these items to test out building large enterprise systems.

…

On Sat, 16 Aug 2025 at 03:34, MJTham ***@***.***> wrote: As an IT who supports ERP for few years, I like the market store idea. And Rust deserves a good ERP. Any action plan or a board to keep track the progress and any discord channel? — Reply to this email directly, view it on GitHub <#2 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6C35Z6KJULB3WAVH5HTL3N2KBTAVCNFSM6AAAAABYGKAG2SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJSGMYTMMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[casibbald]

@zoechi @MJTham @luke-ransfield

After a few months of focused work on getting the OpenAPI foundation for building RERP, we are getting very close:
https://github.com/microscaler/BRRTRouter

Take a look, clone and have a play.

I need to spend a bit of time tidying up the repo and building a documentation site.

The framework comfortably handles 60K+ connections per second on my MacBook, and I am networking-bound internally.

I have had suggestions that running it on a larger Linux box might yield higher numbers, but I am content with these for now, considering most deployments would be scale out rather than scale up (Apart from Backend for Frontend deployment scenarios)

[casibbald]

@zoechi @MJTham @luke-ransfield
After a very long boilerplate development process, we have the basis of the way forward.

We have the base accounting module in development.