Virtual Meetup 30/4: Walter Almeida presents a low code platform

Hi everyone,
This Thursday @walter.almeida will give us a presentation on Generative Objects. You can read more below.

As always, everyone is invited. You can join using Zoom:

Join Zoom Meeting

Meeting ID: 278 156 178

The presentation should last ~30 minutes and we would chat about the presentation and any other topic you are interested in for the rest of the hour.

We will not record the event.

Walter Almeida developed the Generative Objects (GO) low code platform over the last 12 years. The GO platform was successfully used to build full enterprise applications for the corporate world. However, Walter is now open sourcing the full technology, in an objective to democratize the access to such essential technology, as an alternative to the private low code actors actually fighting for market shares. The GO platform is based on application modelling and code generation of the full application, from database to user interface. The main objective of open sourcing GO is to empower all of us to co-create applications and envision how we can build a new internet, decentralized and in the hands of all us rather than a few giants. Walter will demonstrate how to create in minutes a web application that leverages open data from and application specific data.

I hope to see many of you and have a great discussion!


If you want to propose a demo or a presentation for the next meetings you are more than welcome!

Thank you all for you time and presence during this presentation ! It was an honour to introduce my technology to you, wishing now for co-creating to make it our technology :slight_smile:

If you are interested in the next step of the project, you can register on the GO newsletter there :

And … Looking forward to talks around low code and DSLs in this forum :wink:


Thanks Walter for the nice demo and for staying around for the many questions!

I have another question about UI modeling: you mentioned you have been working on a new architecture using Vue.js (did I get that right?). If that is correct, my question to you is: does the new approach produce the UI code as a model-to-text transformation based on the model (like you have with the backend), is it a generic client that can build the UI at runtime based on the model for that UI, or some other approach?

As I mentioned during the call, I am a proponent of decoupling things whenever sensible so they can be reused and combined with other tools independently (the more choices you tie together, the less likely it is for a solution to satisfy someone’s use case). It seems to me model-driven UIs are great candidates for being done standalone, decoupled from the technological choices for the rest of the modeling platform: there is already a physical separation between the front-end and the back-end, and the stack for the front-end is quite consolidated (since Javascript won that war). I have been looking into tackling that part of the problem (which is a major gap in my own tool), and if there is opportunity for collaboration in that front, I’d be very interested.

1 Like

@walter.almeida Forgot to include a mention. Please see my comment/questions above.

Thank you @rafael for your interest, comments and useful suggestions :wink:

The new front is same approach as for the back : model to text transformation. There is no runtime interpretation, this is one of the design decisions of GO. However all the different parts of the metamodel are pretty decoupled, parts of the model could be used to generate parts of applications. For instance : generate a GO front that connects to a non-GO back and vice-versa.

Thank you for your interest, you are very welcome to participate. The new front metamodel and generation artefacts were designed and created by @tvillaren, I include him here, he will be of great input. What is the level of participation you foresee ?

1 Like

Thanks for clarifying. One question is how much the technical choices made align with my own technical requirements (I target the JVM and Linux). If the generator is cross-platform (say, .Net Core), and if I can talk to it via network endpoints or files in the filesystem, it probably would work fine (if it required Windows to run, or required a SQL Server, that could be a showstopper).

In terms of collaboration, at a minimum, I may be able to contribute with cross-platform requirements, validate the generator with models generated from my own tool, etc. I have no experience with .Net/C#, but this would be a good opportunity to learn it (as long as it works on Linux).

Looking forward to learning more concrete details from Thomas.

Hello @rafael,

The generator and User Interface metamodels are two separate things.

Regarding the generator, I think @walter.almeida is currently developing a new version, fully decoupled from our metamodels and generation templates, that could be used as a standalone generator (he will correct me if I’m wrong :wink: ).

I can elaborate on the new UI metamodel though :slight_smile:
The UI metamodel we developed for this new version is based on the CAMELEON Framework and IFML.
More particularly, not only is it decoupled from other part of GO metamodel it consumes (such as the entity-relationship model used to bind UI to the underlying data), it also respectes the 2-layer separation describes in CAMELEON, providing:

  • an Abstract User Interface (AUI) layer, to describe the available interaction means
  • and a Concrete User Interface (CUI) layer, describing the web widget we provide through Generative Obejcts.

The Final UI layer is indeed a VueJS set of components, where each WebComponent corresponds to one element of the UI metamodel.

Let me know if I can add more details.

1 Like

Thanks, Thomas! I am quite curious about your metamodel. Glad to hear about how the different elements of your architecture seem quite decoupled!

What are the plans for releasing the UI metamodel? As a separate github repo? It would be nice to see as well an example of a UI model and the corresponding UI code.

If necessary due to some technical restriction, I would consider implementing another generator for the same metamodel. For instance, one less orthodox approach I have been playing with is generating the front-end HTML at the time the back-end is being deployed, based on a UI model derived from the application own code as soon as it became operational (example).

1 Like

@rafael, about the code generator, as said @tvillaren, I am indeed planning on designing and building a new one, fully decoupled from our metamodel and platform, to make it reusable in other projects. I am planning to build it from the start in .NET Core, it will therefore work on Linux. I am planning myself on moving out of Windows :wink:

The rest of the platform is also in .NET, but not using any heavy Microsoft specific framework, it is almost only pure core C#. Therefore can be moved to .NET core, or even to other languages like java (with a bit more work)

And then everything is exposed through APIs, therefore, you can talk with GO and the generator, through API calls.

As for the database : we are using NHibernate, so other databases like mySQL, MariaDB or Postgres are possible. We already used mySQL for other projects, never used Postgres. So there is a need to do some prior test to make sure all works fine + the devops / auto-deploy tool and the engine that generates the database upgrade scripts will not wok as is. However the design is done in a way that we can definitively add full support for other database engines !

I have also the plan to remove NHibernate for more light weight data access code. We indeed have all the information regarding the application through the metamodel and therefore have everything to generate ourselves an application specific data access layer.

You can also extend and have other datasource provider, to a nosql database for example. I am finalizing one for SPARQL End Points.

I will create another topic about the new code generator design.

Yes we will release the front metamodel. It is all a question of timing, communication, and see what governance / open source license to apply.

Let’s keep updated ! A good starting point is indeed the code generator design. As I need this piece to fully open source GO and replace the existing generator. I hope I/we can do this in 2 months. And as it always takes more time than planned, it is probably a work that will take until the end of summer.

If we have a path to collaborate, we could still share the code base and work together on it.

To be followed !

1 Like

I am planning to build it from the start in .NET Core


As for the database

I have also the plan to remove NHibernate for more light weight data access code.

Walter, maybe it is what you were alluding to here, but do you foresee the new generator will assume the presence of a database at all? Or would it be able to to work based on some input object, no matter wherever it was obtained from? That would allow people to use it based on existing models they currently obtain from other sources, such as files in the filesystem, produced on-the-fly from running code, etc.

I will create another topic about the new code generator design.

Thanks - sorry for replying here, while the topic is not created. I understand, that code will not refactor itself! No rush.

Yes we will release the front metamodel. It is all a question of timing, communication, and see what governance / open source license to apply.

Cool, looking forward to seeing it. I took a stab at designing one, but I don’t spend a lot of time thinking about front-end abstractions (I have always focused on backends and APIs), so I didn’t get very far in that front. That is why I was eager to see the object model for the UI asap.

On the timing front, yesterday I learned I will be starting a new contract in June full-time (something I haven’t done for 8 years), so I am not sure how much time/energy I will have left to work on OSS projects from then on. Also, just to be 100% clear, as I may have been giving a different impression, my intent is to become involved on specific areas/occasions, where there is alignment and opportunities for integration with the stuff I have been working on (besides general unsolicited feedback), and I will be able to understand what those areas will be as you guys start to make some of your work available.


Indeed the idea is to have a agnostic generator, as a service, not making any assumption on where the models or generation templates are coming from. Not sure how I will design it yet though :slight_smile: But I will share my design ideas !

Yes, this is great, whatever you can / want to do is well received ! Also, an important contribution is on design level, to brainstorm together design decision, such as on the code generator for instance !

The objective is to build tools that could serve the most people and needs.

1 Like

Thanks @walter.almeida for the presentation and everyone for their insightful questions.
As I’ve said towards the end of the event, I’ve been working at an open-source tool with some similarities to GO, for many years as an employee, then as a freelance, and lately as a hobby in my spare time.
The interesting thing is that I see both similarities with GO and opposite routes/design decisions. This could be the topic for another meetup, by the way, if you’re interested.

So, Portofino was born, before I was hired, as a closed-source, model-driven RAD tool (“low code” didn’t exist at the time, I think), that was able to meta-model itself, stored models in a relational database, had internal DSLs for stuff like workflows and validation, and was targeted at building boring data-driven applications. So, very similar to GO, only smaller in scope and built with technologies that today would be obsolete (its latest incarnation, Portofino 3, used Struts 2). However, by design it only interpreted the model; it didn’t do any code generation. This was, I think, around 2005-2010.

I was hired shortly after the decision to rewrite it. Portofino 4 departed quite a lot from its earlier philosophy. The problems that the company found with it were:

  • Nobody was able to write customizations except the company’s developers. Bear in mind that their business model had been selling licenses for much of its existence, so this was a problem. They didn’t live off consultancy yet.
  • Integrations were hard. In particular, most often customers did not have the luxury to be able to start from scratch with an empty database schema. Usually, applications would be a part of a bigger system and had to integrate with other application’s schemas. Again, bear in mind that this was before service-oriented software was as easy and as pervasive as it is today. SOAP was the state of the art.
  • Users rarely work with raw entities in mind; rather, they work with what we then called “use cases” in mind, or better, scenarios built around filtered collections of entities. For example: “the last 20 tickets opened by me”, or “open projects that I’m a member of”. This means that it’s limiting to have one entity correspond to one page. The same entity might be consumed from multiple pages. As a consequence, navigation cannot be easily derived from the model.

So, we decided to rewrite it with reverse-engineering, easy customization, and a concept of “page/navigation” which is separate from “entity”, as key design goals. Thus it went from “low code” to “well, actually, you’ll have to write some code, just not as much”, and from being strictly a model interpreter to being a mixed interpreter and generator – the built-in classes interpret the model, but the tool generates a stub for each page/view that the developer creates, and that stub can be edited to introduce new behaviour or to override the built-in one. Behaviour is mostly coded in the Groovy programming language, and not in a DSL. This is very powerful and flexible, but for some aspects, particularly authentication and authorization, the barrier of entry is pretty high and a DSL would be better.
However, simple validation constraints are expressed by placing annotations on the model itself, custom relationships are encoded in the model as SQL-like queries, and forms are defined using an ad-hoc language based on XML (but form models can also be easily built and manipulated programmatically).

So it’s interesting to see how from similar design principles and goals you can end up going fairly different directions. And perhaps, with GO going open source, some kind of cross-collaboration would be possible (although Portofino targets the JVM and GO the CLR).

1 Like

Thank you @alessio.stalla for this presentation.
Do you have a link to this project so that I can check ? I cannot find it … Thank you !

1 Like

It’s here:
Version 5 is REST + Angular UI. Most of the documentation still refers to version 4, though. My time is limited and nobody else is contributing to it at the moment.

1 Like

thank you @alessio.stalla, I will check this

1 Like

Hello @rafael !
The open sourcing of Generative Objects is progressing, please check here for some more details : POC for Low code platforms and DSL integration

You can join the new forum for discussions around the code generator and the new front model