Considering Forking and Rewriting SQLPage: Why and Exploring Options

[Ajotah98]

Hello SQLPage community and contributors,

I've been a keen observer and admirer of SQLPage for its innovative approach to building web applications directly with SQL. The speed and efficiency achieved with Rust are truly impressive.

However, I've also been considering some potential limitations that might be hindering wider adoption and community contribution. These are primarily:

• Learning Curve of Rust: Rust, while powerful, has a steep learning curve, which might be a significant barrier for many developers who could otherwise contribute to and benefit from SQLPage. This complexity could be limiting the growth of our contributor base. Just checking the Issues tan gives us an idea of why I'm writing this.
• Limited Database Support with sqlx: The current reliance on sqlx restricts the number of databases SQLPage can natively connect to (currently PostgreSQL, SQLite, MSSQL, etc.). This excludes many popular databases like Oracle, Snowflake, and others, limiting the tool's versatility for a broader audience. The best approach for this nowadays is implementing new connectors into sqlx-oldapi, which is only used here as I'm concerned.

---

To address these potential limitations and foster greater community involvement and wider database compatibility, I've been contemplating the possibility of rewriting SQLPage in another programming language with a more extensive ecosystem and a gentler learning curve.

My primary concerns with such a significant undertaking revolve around potential performance loss compared to Rust. With that in mind, I've been exploring languages that offer a balance of a more accessible development experience and reasonable performance, ideally with some similarities to Rust's programming style (e.g., semi-functional paradigms, good pattern matching).
Some of the languages I've been considering include:

• Python: Boasts a massive ecosystem (database connectors, templating), a relatively low learning curve, and excellent pattern matching (from version 3.10 onwards). However, performance might be a concern compared to Rust, and its dynamic typing has trade-offs.
• Kotlin: Runs on the JVM (access to Java's extensive ecosystem, including JDBC for broad database support), has a more concise syntax than Java, excellent pattern matching (similar to Rust's match with when), strong support for functional programming, and good performance. Its adoption in the backend is growing.
• Java: A mature language with a vast ecosystem (JDBC for almost any database), strong performance, and mature web frameworks. However, its syntax is more verbose, and it has less inherent support for functional paradigms and pattern matching compared to Rust or Kotlin.

---

Considering the need for a good templating engine ecosystem similar to Handlebars (or easily implementable helpers), and efficient I/O and concurrency for the web server, I've also looked into the availability of Handlebars implementations or flexible alternatives in these languages. While Handlebars adoption isn't as widespread outside of JavaScript, languages like Python (Jinja2) and JVM languages (Thymeleaf, FreeMarker) offer powerful and flexible templating engines.

I would love to hear your thoughts and opinions on this idea. Specifically:

• What are your perspectives on the current limitations of SQLPage regarding Rust's learning curve and database support?
• Do you see value in exploring a rewrite in a more widely adopted language?
• What are your thoughts on the potential language options mentioned above (Python, Kotlin, Java) or any other alternatives you might suggest?
• What are your concerns about a potential rewrite, such as performance implications or the effort involved?
• How do you think a rewrite in a more accessible language could impact the adoption of SQLPage by new users and potential contributors?
  This is intended as an open discussion to gather different viewpoints and assess the potential benefits and drawbacks of such a significant undertaking. Your input is highly valued!

Thank you for your time and contributions to SQLPage.

[ccothrun]

I've considered a copy of SQLPage in another language as a learning exercise but never as a proper fork. I think @lovasoa's vision for SQLPage and his focus are on the correct path, though I do agree that the database limitations are a concern. I'm largely positive about Rust for the correctness and safety, though I'm only a beginner in the language.

Python would be a great candidate for the ecosystem. The performance concerns for 99% of users wouldn't matter, I'd consider it a success if someone built something useful enough in a hypothetical Python SQLPage to have legitimate performance concerns. I'd be more worried about packaging, even with the uv tool there's an extra step beyond unzipping a folder for people to get a running application. I was musing on something like SQLPage as an embeddable component for something like Django or FastAPI to allow building lowcode components in an existing app.

We're a Microsoft shop so I considered C#. LINQPage anyone? Dotnet remains a Microsoft-centric ecosystem though, even though the crossplatform support is great the cross-platform ecosystem isn't catching up.

We (at work) recently cracked the door open for Node apps in Javascript so that crossed my mind for a learning deep dive. Dynamic language (what about Typescript?) issues and ecosystem churn are negatives.

Golang seems like another good candidate for a compiled single-file executable performant language and lots of packages.

Overall though I think any language choice is going to attract a few developers and turn away more, we just all have our opinions and preferences for a language. Developers also like their known tools and abstractions so we have people building big piles of code over lightweight abstractions like Flask or Express instead of considering something like SQLPage that is further up the abstraction ladder.

I think bigger factors for overall SQLPage success are:

• Quality web components, most component development doesn't depend on knowing Rust.
• Component features for quick development
• Simple local development and relative ease of deployment

The database support issue is a hurdle to wider adoption as people put useful data in a wider range of RDMS and related tools. I know ODBC support is planned for @lovasoa's fork of the sqlx library which will open up a wider range of databases. I'm also curious about using ROAPI or running a Postgresql instance and using FDW to connect to a wider range data sources. I think quite a bit more flexibility to explore here before a fork makes sense simply for database compatibility.

There may be value in building out the SQLPage concepts in other code ecosystems that would benefit from adding a relatively lightweight high level declarative code and templating system.

[Ajotah98]

Thank you very much for your extensive response!

Regarding the languages to use, I had also considered JavaScript/TypeScript. In fact, although I didn't include it directly, I believe it would be the preferred option along with Python if we want community contributions. However, I really think that the JavaScript ecosystem wouldn't benefit as much from having "another framework" (even though SQLPage doesn't try to be one nor is it close), and I believe its adoption wouldn't be as beneficial.

Regarding your comment about Python, I don't quite "see" why it couldn't work as SQLPage currently does: with proper packaging, I believe it could be achieved by simply unzipping a folder, although logically it would be more tedious to implement that packaging system.

Regarding Golang, it also seems like a great option to me, but I didn't include it because I'm not familiar with its status regarding full database connectivity.

Regarding the real problem that encompasses SQLPage (and in general, applications created with asynchronous Rust): The lack of more database management system options. Honestly, the idea of doing a fork and redoing SQLPage comes from (in my personal opinion) two factors:

• I want to connect SQLPage to Oracle databases (which are what I work with daily), without having to create an ODBC connector (which is currently not implemented) or set up workarounds like Postgres FDW.
• To do this, I tried to connect the rust-oracle crate in SQLPage, in its 'database' module, but there are many problems here, not only because to do it properly it should be done within sqlx, but also because the crate itself has a synchronous nature, completely unlike sqlx or SQLPage. Furthermore, I'm a complete novice in Rust (a "skill issue" as the language experts would tell me), and making it work minimally for this very specific and complex case of adapting a new database driver in a mature library like sqlx is a huge effort (in fact, I believe that even with deep knowledge of the language it would be highly costly).

Given these circumstances, perhaps some might think I'm crazy, but from my point of view, I see it as simpler to reimplement the entire application (which, strictly speaking, is much less complex than the Oracle connection OCI protocol) than to implement the driver in sqlx-oldapi.

I hope this provides more insight into "why" I consider it this way as an individual, as well as why I see it reflected in the Issues that appear on GitHub.