SQLPage – Building a full web application with nothing but SQL queries [video]
youtube.com
youtube.com
Project page: https://sql.ophir.dev/
GitHub project: https://github.com/lovasoa/SQLpage
It is built in Rust, and the project website is built in SQLPage: https://github.com/lovasoa/SQLpage/tree/main/examples/offici...
As a data analyst and witnessing the enthusiasm of the presenter makes me want to test this!
Repo (3K stars): https://github.com/evidence-dev/evidence
Previous discussions on HN:
https://news.ycombinator.com/item?id=28304781 - 91 comments
https://news.ycombinator.com/item?id=35645464 - 97 comments
The challenge as I see it with enabling analysts to build websites is that you need to build abstractions to get from familiar (SQL, yaml) - the language of analytics, to new (HTML, CSS, JS) - the language of the web browser
As one of the maintainers of Evidence (https://evidence.dev), one of the things I’ve often considered is how accessible our syntax is to analysts. Our syntax combines SQL and Markdown, with MDX style components e.g. <Component/>
The </> are inherently webdev-ey, and I do think they put off potential users.
On the flip-side, by adhering to web standards, you get extensibility out of the box, and working out what to do is just a Google search away.
Anyway, thanks for the thought provoking piece.
Indeed, making this really 100% SQL-only had very interesting and unexpected consequences. I see people who were initially far away from programming circles creating GitHub accounts just to post on the discussion page.
I'm currently working on some new exciting features. I hope we can push the frontier of what can be done in SQL even further...
``` select 'checkbox' as component, 'Terms and conditions' as label, true as required; ```
I'm thinking "What would the workflow of a sql-enthusiast be, to build that page".
I think they'd want todo this first:
``` select * from sqlpage.components; ```
which would list the `name` of each component. Which then takes me to:
``` INSERT INTO sqlpage.dom SET name = 'checkbox', label = 'Terms and conditions ', required = TRUE FROM sqlpage.components ```
(or VALUES syntax for INSERT)
This would allow you to re-order your dom, update dom entries, etc. Very similar to jsx, but instead of jsx creating in-memory javascript objects, it's sqlpage's sql creating rows in a postgres table. Then the SQLPage virtualdom gets transformed into actual html.
Just a thought, :)
The "select 'checkbox' as component" is just an example, but nothing prevents you from creating a my_form table and writing it as "select * from my_form" instead.
You don't need any special feature from SQLPage for that.
this would be a convincing feature for me
Instead of using proper <component>s you're using "select 'Label' as text".
No. Even if the guy is sympathetic, keep presentation separate. If it had markup mixed with SQL queries, ok, sure.
But this is going too much in the other extreme direction.
I not just would like but need to have control over my presentation. And with doing pseudo SQL queries this is too complicated vs regular markup or something like vue etc.
Only upside of this is performance and/because it's SSR
Why is separation of concerns a good thing in general? Mainly because of three things: maintainability, scalability, and collaboration.
However, there are cases where strict separation of concerns is impractical, and people are ready to sacrifice these for simplicity and speed of execution.