[kwlug-disc] SQLPage can be more SQL-y

[Mikalai Birukou]

> {as a follow up to SQLPage presentation}
>
> SQL is a structured language. Both parts are important: structured and
> language.
>
> If you ever had to construct programmatically queries, you'd think that
> building an SQL query was designed for this process. May be someone can
> point at architecture discussions and history.
>
> Now comes a ingenuously simple idea: instead of erasing structure that
> comes from query results, feed it directly into structure of
> automatically generated page, be it html, json, or future may want a
> gRPC, etc.
> SQLPage's magic and wisdom is in cutting it straight. Sailing with the
> wind, not against it.
>
> On the language side, though, many of us where confused. And rightfully
> so. How does it look to an English speaking person: select, select,
> select. Besides, being a marker that has some meaning for computer,
> "select" implies common select/take action. And subconscious mind gets
> confused: why choisir has a meaning of display?
>
> SQLPage adds a display of data. That's it.
> All respectable SQL databases have their own additional words added to
> common SQL, like "SHOW" in MySQL, and so on.
>
> Imagine file for json endpoint is
> RENDER JSON FROM ...query...
>
> Or, how about for html
> RENDER HTML _html_component_tag_ WITH ...select_query...
> RENDER HTML _html_form_tag_ WITH ...select_query... DO ....
>
> These kinds of extensions will make SQLPage more SQL-y, like Postgres' DO.

In the interim I did comparison of example code and possible extension 
for sql rendering commands, in github discussions: 
https://github.com/lovasoa/SQLpage/discussions/310#discussioncomment-9402052

I think I am writing commands specifically to expose data flow, as an 
important aspect of business logic that can't be hidden be the framework.

> Side note 1: Of course, one can't ask for this at the very early stage
> of a project. I wonder whether it is easy or non-trivial to add these
> extensions to parser that is used in SQLPage (disclaimer, haven't
> checked code in details).

SQLPage actually uses sqlparser rust crate that generates AST from SQL 
commands. When there is time, I hope to just add new commands. Then, 
compile it to WASM and expose for npm and deno, to start mix and match. 
Cause SQLPage is just one possible mix of few things that go into making 
website platform. SQLPage is like a framework, that has no events, as in 
server events, and refresh of pages is all one has. But idea is awesome. 
This should be a library to parse SQL, extract from it data flow parts, 
and return in a form of do this, use SQL for db there, do that. Then 
users of this lib can do whatever they wish. And this hell breaks loose 
best in node|deno lands.

SQL to AST libraries in npm are JavaScript, not TypeScript. And one 
needs computer/compiler help in precision work.

> Side note 2: If someone insist that ultimately world is made of
> select's, we should remind them, that it is made of lists, and this
> direction of design has also traversed.
We articulated it: overloading operators. SQLPage is overloading select 
with meaning of rendering.