Just one more experiment!

When we need to return data to be displayed on the UI as DTOs we are going to read from multiple repositories unless for trivial UI. For example forum posts can have author (a user) and comments. Comments can have author too.

{
      posts: [{
        title: "Efficent DTO",
        author: {
          name: "Marco"
        },
        comments: [{
          author: {
            ...
    }
    

In this context, no matter the technology we are going to use, the N+1 problem will pop up. For instance with:

• ReST API: we execute a request for the list of posts then N requests for the User resources.
• ReST API + hint, like /posts?with=user: now we have only one ReST request but probably on the server users are loaded one by one from their repository.
• GraphQL: without data loaders you still have the same problem, the user of a post is resolved for each post.

The last example is not accidentally: when I faced this problem I thought at first to resort to GraphQL and this is why my idea comes from it. However I did not have dynamic queries but static ones, read "several endpoints that return always the same JSON", hence I did not want to adopt en engine to parse, for a given endpoint, the same query over and over again.

I found that what I needed were batched loaders and data loaders, something that every GraphQL implementation have as associated library. In our example for every post DTO resolution the load of the user is delayed until we have the complete list of the users to load (same for comments and users of comments) so we can batch load users.
Other sulutions, illustrated below, do not scale, at least in my use cases.
The library that implements the above algorithm, without GraphQL, is graph-loader.

Describing a language editor can be repetitive, for instance when you have to define expressions. expression '+' expression and expression '*' expression is a typical example. From the grammar file that describes the language structure it's possible to recognize repetitive rule structures and build an editor in a consistent way.

The PE project defines a grammar and generates AST in a way not related to any projectional editor. PE4MPS project imports the generated ASTs into MPS generating for example from this rule:

Graph:
      strict=STRICT? type=GraphType name=string?
      statementList<indentList('{', '}')>=Statement*
    ;
    

this MPS editor:

There are several strategies for code generation. The one used by MPS could be called no code generation strategy. In fact the suggested implementation for code generation is first to transform models in your language to models in the target language, or if you prefer first to transform AST representation of your program into AST representation of target language. Then models from a real language, for example Java, are translated to text. This means that only construct, like if-then-else, of language that one can compile or execute, like Java, have a place where one say how to translate them to text, in MPS called TextGen aspect.

MPS gives you for free a language called baseLanguge that transform seamlessly to Java. Whereas one of my target languages is Javascript, so I created this new MPS language. The new project is hosted on github.

The idea to sketching UI, or other types of drawing, using text file is not new. Text can be embedded into text files so a whole document can be defined using only text. This is the approach used by Sphinx, with it you can use reStructuredText to define your HTML or PDF documentation.

Sphinx is integrated with PlantUML so you are able also to define UI, UML diagrams, charts using text.

The subproject used by PlantUML to define UI sketch is called Salt. What I do not like about Salt it's that it uses lines, curves and text to draw a UI sketch. This way the result is not realistic.
And ok... I would like to exercise with ANTLR.

Markdown is today used in several place including this blog.
ANTLR is also used, almost, everywhere where you need a parser.
So to learn ANTLR I have chosen to try teach ANTLR how to parse Markdown syntax. This task has been much more hard then I expected.

Now that I can write posts in HTML and in Markdown what is missing to create the smallest static web generator we can imagine?