Recently, I have been looking for a flexible information manager or a data-centric rapid development platform. While learning Fossil SCM, I noticed its ticketing system SQL-based configuration feature. At some point, I even attempted to figure out if I could hack Fossil to put other data in the ticketing system. But then I hit an obstacle in the form of the built-in Fossil safety features and set this idea aside. Instead, I started looking for a dedicated open-source platform for rapid application development based on a similar concept of SQL-driven development and found SQLPage.
SQLPage is a relatively young but, IMHO, interesting open-source project positioned as a rapid web prototyping platform. It generates static HTML on the server from SQL code incorporating statements for database data retrieval, GUI definition, and flow control via HTTP redirects. SQLPage natively supports several RDBMSs, including SQLite. It follows the single executable design, which, similarly to Fossil, integrates SQLite and a web server, with precompiled binaries available for several platforms, including Windows. Starting the SQLPage server is as easy as starting the Fossil server, though SQLPage does not attempt to find an available port, which should be specified in its compact config file.
The SQLPage source repository is hosted on GitHub and primarily developed by its founder, with a few external contributors. At the same time, the development process is active, and the developer is very responsive and open to sensible contributions.
The primary development language is Rust. The project uses sqlparser-rs and Rust binding for SQLite. As far as I can tell, SQLPage keeps well with SQLite updates (the last time it updated to the latest SQLite release with a one-month delay, which is pretty good, IMHO). SQLPage uses a Bootstrap-based Tabler UI kit and the Handlebars templating system (with custom extensions) for HTML rendering. The Handlebars templates are included in the SQLPage GitHub repository and can be further customized, if necessary, or used as templates for developing/defining new GUI components. SQLPage incorporates a markdown renderer, and the code highlighting feature is available through standard JavaScript libraries. Depending on specific project goals/requirements, pure SQL code may be sufficient, but JavaScript and CSS libraries/modules may be activated and used for tweaking the result. Among its notable features is its powerful "table" component, which provides a per-column sortable and full-text searchable rendering of arbitrary record sets out of the box (no custom settings are necessary).
The primary development language accepted by SQLPage is SQL, with a few useful extensions. SQLPage supports a standalone SET statement, allowing evaluation of [apparently] arbitrary SQL expressions and queries and assigning a scalar result to local variables, which can replace any SQL literal values in the following code. SQLPage also provides several specialized "pre-SQL" functions, which can be part of the code and are evaluated and replaced along with the local SET variables (and POST/GET parameters referenced in the code) with corresponding literal values before passing the SQL to the database engine. Among those functions, three provide access to external files: one enables evaluation of separate SQL modules (returning results to the calling code), and two others make it possible to read text files and binary files as data URLs. SQLPage can also seamlessly serve files from a virtual file system hosted inside the database, which is particularly beneficial for small files, such as images and small modules.
The use and interpretation of SQL statements (or rather the returned results) is somewhat unconventional, as the code intermixes statements retrieving data and defining the GUI and flow control. Frequently, two or all three of these components may be parts of the same statement. It takes some time to get used to, but I do not find it too difficult. At the same time, the developer needs to pay attention to structuring the code and use plenty of comments because, otherwise, it tends to appear as a wall of SQL.