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).
But I will share my design ideas !