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:
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…
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:
- GOTO 2019 • Clean Architecture with ASP.NET Core 3.0 • Jason Taylor
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.
I seem to be in the business of making non-trivial proposals for GOv2’s target state, so here are some more:
|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…