V2 Architecture proposals

Hi Walter & Team,

First, apologies for lack of communication for a long time now, and second in advance for the length of this communication! Walter asked some weeks ago to update my status on the project, and this is effectively my response.


I took on the task of migrating a simple GO generated app to DotNet Core (3.1). Walter helped me generate a trivially simple app (2 entities, one relationship, including auth.) plus the framework dependencies.

The overall plan was:

  • migrate the generated app to get it working on DotNet Core (hereafter Core)
  • update the generation templates to generate working Core project files
  • generate the ported app via the updated generator
  • repeat with more complex generated apps, working our way up to porting the Modeller app…

To migrate the simple-gen-app, I tried these approaches:

  1. Convert to Core projects & work through the build errors - ugh. There are a lot of changes in Core relative to framework, some fundamental such as DI. I started my way through it but I became concerned that we’d end up with code obviously ported from .Net FW, not targeted specifically for Core. So…

  2. Start with a working Core template solution and reverse engineer the T4 templates used by the generator.

I abandoned option 1 fairly quickly (particularly in the light of additional proposals below) which leads to my first architecture proposal: GOv2 generated DotNet Core apps should be based on a solution template targeted to DotNet Core.

Given that DotNet 5 is now GA, this becomes:

Key Proposals & Assumptions

Proposal: GOv2 generated DotNet Core apps should be based on a solution template targeted to DotNet 5.

If this proposal is accepted, the question is then: which template solution? To narrow the field of candidates, I needed some filters:

Assumption: a modern LowCode platform (that expose generated code) must generate maintainable code using current & popular design patterns.

Assumption: Clean Architecture represents current best practice for applications architecture.

The latter is not only my assumption, it’s also supported by Microsoft’s architecture guides. The following provide conceptual overview & reference implementations:

They are all quite similar as you’d expect, but there are significant differences both in detail and maturity. The implementation that appears to be the most mature and actively developed is abp.io - a DotNet Core/5 fork of the mature https://aspnetboilerplate.com/. (It is interesting to note that ABP maintainers extensively rewrote ABP to create abp.io - see https://blog.abp.io/abp/Abp-vNext-Announcement.)

Proposal: GOv2 default generator should target the abp.io framework and starter template

Adopting the abp.io starter template as the default generator target would deliver the following benefits to a generated app:

  • Support for clean architecture
  • Support for modules & UI composition (& planned module marketplace)
  • Support for microservices vs monolith (via modules)
  • Support for multi-tenant apps
  • Support for UI themes via Bootstrap 4, and tag helpers
  • Support for repository pattern for ORM / EF independence (https://docs.abp.io/en/abp/latest/Repositories)
  • Support for Dynamic forms (from view-model class)
  • Support for Virtual file system (resources embedded in dll) etc.
  • Support for a code generator CLI (both ABP and satellite initiative https://github.com/EasyAbp/AbpHelper.CLI)
  • Decent online documentation
  • A number of available sample apps (https://github.com/abpframework/abp-samples)
  • Active development community, adding new functions & tech stacks over time, e.g. Angular, React and Blazor etc.

IMO, the above list are all must or should have features for a viable LowCode platform to be useable in production contexts.

Of course, no architecture decision exists without a trade-off: adopting an actively maintained template & ecosystem will make the GOv2 project essentially dependent on ABP abstractions & more complex to manage:

  • GOv2 developers will need to become very familiar with ABP
  • the GOv2 metamodel & Modeller will need to expand to support ABP abstractions, e.g. Modules
  • the default GOv2 generator will need to target a particular version of ABP, etc.

Additional Proposals

I seem to be in the business of making non-trivial proposals for GOv2’s target state, so here are some more: :wink:

GOv2 Product / Architecture Proposal Rationale
Low-code platform name: GoLoCo[de] • Derived from “GO Low Code”, and this idea mentioned in one of the emails recently;
• Play on words (in English at least) for GoLoCo to “go crazy” (and generate code… )
An App Metamodel is stored and version-controlled as a (human editable) text document in a Git repo, rather than in a relational DB (as now) • Generators are not dependent on a centralised metamodel store (DB).
• Metamodels can be branched, merged and version controlled via git
• Generator dependencies are simplified - input: model repo, output: app repo
• Metamodels can be stored alongside their generated apps in one repo:
• Metamodels can be shared via git repo Urls & access grants
An App Metamodel is expressed as text files via JSON Schema, plus custom extensions • JSON Schema is the most popular notation (at least when used for API definitions) - see https://www.postman.com/state-of-api/api-technologies/#api-technologies
An App metamodel can be directly edited and validated via a VSCode extension, supporting intellisense • Modellers who are also developers can work directly in a familiar (open source) dev tool
• Modellers familiar with the GOv2 metamodel need not fire up the Modeller UI, e.g. when they want to make small changes to an existing model
An App Modelling web UI is available at www.goModelHub (or goloco.io say), supporting the GOv2 App Model:

• Editing / Validating / Versioning
• Importing / Exporting
• Sharing / Merging
• Model Publishing / marketplace
• List available Code Generators & versions
• List available DevOps platforms
1. User-friendly UI to support Modellers:
• Architecture settings, e.g. Monolith vs microservices, Angular/React/Blazor etc.
• Entities / Fields / Relationships / Validations
• Modules / Use Cases - Roles, Commands, Queries
• Views / View Models / APIs

2. Model sharing, merging, publishing & marketplace (open source or commercial licence)

3. Ecosystem support for Developers:
• Code Generators
• DevOps pipelines & hosting platforms
An App Modelling API to support lifecycle automation api.goModelHub
(or api.goloco.io say)
• Automation access to www.goModelHub functions
• Central source of truth for App meta-model schema, validation, merge & publish rules.
• Code Generation services
• DevOps integration services
An App Modelling CLI (i.e. API Client) • Command line access to api.goModelHub functions
The GOv2 Modeller web UI need not be generated (by the default generator) • The ability to generate the Modeller UI via the (default) generator is not useful to Modellers
• The Modeller UI application should be designed to maximise Modeller UX/CX, not to prove that the GOv2 App Metamodel is capable of handling complex Apps.
Review the approach that the https://github.com/EasyAbp/ team are using to provide command line code-generation • Their goal seems to be to provide command line helpers that generate code fragments for developers using the ABP framework.
Consider adopting the new .Net 5 Source Generators abstraction for code generation: https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/ • Not sure if it makes sense for GOv2 but worth investigating.

So, that’s it for now - I hope this generates some useful discussion about possible GOv2 target states…


1 Like

Thank you @Garth for this feedback ! There are many interesting ideas and suggestion, thank you very much ! I will comments one by one

I will check this, when I will be working on the port to .NET Core. This is a great pointer. This idea for me was intially to make sure we use the purest C# as possible, the less .NET specific framework as possible (for instance, no EF) so that we could easily write similar code generation templates, let say targeting java or node.js. But this is maybe not so relevant as we want to make the most of the current technological stack we are targeting, so I might review this direction. What is important to have though is full decoupling of front and back, use of APIs to communicate between back and front and definitively multi platform target (especially windows and Linux)

I like it, GoLoCo, good find !
However, I thought about the name, and GOLowCode is for me too limiting for the platform we are building. Indeed, we will go beyond what classical low code platforms are doing, which is : platforms to build mainly data centric applications. Low code platforms can be used to create apps for any business domains, but still limited to data centric applications, thus making low code platforms usable to create a specific kind of applications.

With GoLoCo, we go beyond, thanks to the self reflection of the platform : I am finalizing the rewrite of the code generator, and in this process, I improved the initial design to make sure that an expert user can create his own metamodel and generation templates directly on the platform. Thus the GoLoCo original platform, with the existing metamodel (let’s call it GoLoCo core) can be used to model and generate new low code platforms, specific to a certain kind of applications that could be anything, not just data centric application.

This make GoLoCo a generic low code platform that can be used to model and generate datacentric applications by default, but can also be used to model and generate other specific low code platforms. And these specific low code platforms can in turn be used to model and generate a new specific kind of applications.

GoLoCo becomes a new generation development workbench, this is the next generation of dev platforms, coming after low code and GoLoCo is the initiator of this. I call the approach Generative Code. So for the platform name, I thought of GO-GenCode, GO-Genius, GO-GenerativeCode. But actually GoLoCo could also be a good fit !

I will share more of this on a specific post.

I am glad you mention this ! I thought of the same. This makes perfect sense and solve the complex topic of models version management, and branching, merging. I initially thought of implementing a version management on top of a SQL database but using GIT will bring everything instantly and is widely used and understood by many.

The plan is to integrate on GoLoCo a GIT connector, the same way we have a relational database connector or a DBPedia connector, and use GIT as a database. There are many resources explaining how to use GIT as a database. So then we can model on GoLoCo an application and link entities to a GIT database datasource rather than a relational database datasource. It will this way be possible to still have the web UI modeler working exactly as it today. But also directly modify the model on the GIT repo if we will. Branching, merging can be accessible directly on the platform, the same way it is on github. And for performance it will be all ok as the modeler on a given application model does not have to scale to millions of users but just on the developers who are using this model. This will make GoLoCo extremely powerful and professional.

More on this on a specific post !

Continuation of discussion around putting model on GIT.
Yes probably JSON format, with one folder per entity type, one file per entity instance, and most probably indexing files to have good performance for join queries

Yes, but also directly editable through the Web UI platform, thanks to the GIT entity data source. But I think this is what you say here :

Yes definitively

Yes ! must have

In fact, I believe the GOv2 modeller web UI should be generated. This is to respect the core intention of GoLoCo to be self modeled and self generated. This is what I call the Generative Code approach that will allow all that I said in a previous comment. Please note that @thomas already created a new front metamodel and associated generation templates that is much much more flexible than what we have today and is using todays best practices and frameworks, including vueJS. This still has to be integrated. And it will ensure we can have a proper efficient, ergonomic modeler.

Will check all this ! Thank you