Abstract

Chameleon is an innovative idea and MVC web framework implemented as stored procedures and functions targeting modern RDBMS databases. It brings back-end codes into database and also performs the entire request pipeline right inside database.

Usage

Chameleon can be used for establishing any online website, such as a CRM, a personal or corporate website, online shop, directory listing or any conceivable web-based business. It is also a good fit for creating web apis. Using Chameleon it is tremendously easy and fast to create REST APIs.

Usecase I: Web API

One usecase that shows Chameleon smoothness is creating web APIs.

In today world, web APIs are an essential part of any online business. Agility is also a key factor in the market, so that the business can continue its pace as fast as possible.

By bringing back-end codes and request pipeline inside database, Chameleon provides the fastest agility and experience for both developers and stakeholders.

Usecase II: On-Premises Application

Chameleon is also a good fit in creating on-premises web-based applications.

Getting Started

To learn more about instructions on how to install and run a sample Chameleon website, click here.

Idea

Chameleon's pipeline can be described in the following steps:

The Host receives a web request.
It fills chameleon context tables using request details (url, body, headers, cookies, form data, etc.) and passes execution to a central stored-procedure inside database.
The rest of the pipeline continues insdide SQL Server until a response is provided.
The result (response body, headers, cookies, status code, etc.) is sent back to the host.
The Host writes result onto Http response.
Done!

The idea can be implemented in any modern RDBMS that supports stored-procedures such as SQL Server, Oracle, PostgreSQL, etc. Moreover, its Host is technology-independent. It can be developed in any server-side technology.

At the moment the idea is implemented in SQL Server 2016+ database. Implementing the idea in other RDBMS engines is also ongoing.

Boilerplate

Host

As it was said, the Host part of Chameleon is technology agnostic. It can be developed in any server-side technology such as Java, ASP.NET, ASP.NET Core, PHP, Python, NodeJs, Go or any technology that has a SQL Server database driver.

The Host is just a tiny web application that sits between client and database and has the single job described before.

Currently, an ASP.NET Core 6.0 host is implemented for Chameleon that yet is enough to test Chameleon. Developing Hosts in other frameworks is also in progress.

To learn more on how to install Chameleon and host a sample website using ASP.NET Core click here.

Middleware

In web frameworks a middleware is a piece of pluggable code or routine that participates in request pipeline. It can manipulate the request, provide the response or end the response based on the logic it is aimed for.

In Chameleon, middlewares are implemented as stored-procdures. Chameleon comes with a set of pre-written middlewares that form its pipeline. A few of these middlewares are listed below:

StaticFilesMiddleware
CookieAuthenticationMiddleware
CorsMiddleware
RoutingMiddleware
MvcMiddleware

In order to learn more about Chameleon middlewares click here

Routing

Routing in Chameleon is performed by a middleware named RoutingMiddleware. Routing details and its rules are described here.

Views

Chameleon employs view-engines in order to return views (the V part in MVC). By default, it uses a view-engine named Gila (pronounced Hila). In order to learn more about Chameleon view-engines and Gila, click here.

Installation

Installing and using Chameleon is quite easy. There is an installation SQL script that creates a sample databse named ChameleonDb and installs Chameleon in it.

install.sql

Details of install.sql script is described here.

Execution

After installing the database, you need a Chameleon Host. You can download and use Chameleon.Host.AspNetCore6 Winx64 which is a ASP.NET Core 6.0 application. After downloading Chameleon.Host.AspNetCore6 Winx64, extract it in a folder and run its main executable file. It listens requests on port 5000. Then, open http://localhost:5000 in your browser.

You can also download Chameleon.Host.AspNetCore6 source-code at Chameleon.Host and compile it for other platforms.

Chameleon.Host.AspNetCore6 can be run independently as a stand-alone application or using a web-server such as IIS. You can create a website inside IIS and put Chameleon.Host.AspNetCore6 files in it.

API

Chameleon includes a group of stored-procedures and user-defined functions that form Chameleon API. To learn more about this API click here.

Pros & Cons

Pros

Agility: Chameleon greatly helps agility, since it shortcuts CI/CD pipelines. Changes are applied to application instantly by running just SQL scripts on the database. Nothing else is needed.
Universal Language (T-SQL): Using Chameleon requires learning no other library, language or framework. The only thing required is knowing T-SQL.
Smoothness: Updating part of an application could be as smooth as just executing a T-SQL script over database.
Lean CI/CD: Chameleon shortcuts CI/CD pipelines, since there is no compile, build, deploy in it. Updates are as easy as executing a T-SQL script over the database.
Small Learning Curve: Chameleon has a small set of SPROCs and UDFs. Its main purpose is to link developer to the request. The rest is handed over to the developer on how to implement business rules and provide the response.
Easy installation/Setup: Developer just needs to install a ChameleonDb database. Nothing else is needed.
Backup: Since Chameleon contains data, application and business, backing up the database equals backing up the whole application with everything it has.
Security: If database is already secured (and it must be and probably with a master-key at best), everything is safe. No one could lurk into the application surreptitiously.

Cons

Resource Intensive: Database is a hefty resource. So, its connections should be used scarcely and cautiously. Developer should close a connection as fast as he can after it is opened. In Chameleon not only should the database engine perform its routine job (handling data), but also should run business logic. Chameleon adds or to say better imposes application load onto the database too!
Lazy and Slow: Chameleon brings business logic right inside database. The best practice in using database connections is treating them like countdown bombs. When you open a connection you are like turning a bomb's timer on. You should perform your job and close the connection as quick as possible. It is because database connections consume great amount of resources.

Moreover, the number of connections a DBMS supports are limited. So, connections should be closed quickly, so that they return back to the pool and another client can use them. Chameleon moves opposite direction of best practices. Bringing application code inside SPROCs, imposes application's lift over the DBMS, heavily wastes connections and resources and brings DBMS onto its knees.
Ugly language; No OOP: The same thing offered as benefit, i.e. universal language, can be deemed as a drawback. Microsoft's T-SQL is in reality a programming language, no doubt. But, it lacks high-level programming features available in other languages like C#, Java, Python, NodeJs, PHP, etc.

It is not an OOP language, its features are not comparable to full-fledged languages, it has low modularity, low conditional structures and loops (no for, do/while, switch structure) and no mechanism to pack a group of variables, to name a few.
No Async: another drawback is lack of asynchronous execution. Executing I/O bound operations like calling a third-party API, should be performed asynchronously to avoid wasting resources. T-SQL does not support async/await operations.
Difficult debugging: Complex algorithms and business logics do require debugging/tracing and advanced toolings that IDEs provide. SQL Server's debugging feaure is poor. Bringing business logic inside database results in greater number of headaches and no-sleep nights. Lack of high-level languages' features makes the situation worse. The person who dares transfer all application code inside SPROCs is either brave, or ... is shooting in the foot!
Difficult TDD: Although TDD does not force a specific language and it can be carried out in SPROCs and UDFs as well, no TDD tooling supports the programmer with application's business logic implemented in T-SQL.
Security Compromisation: If an attacker can access database's password, he can nearly gain access to all the house, since both data and business are located in the same place. The Gatekeeper pattern does not apply in this framework.

Bottom Line

No framework is out of shortcommings. Chameleon is no exception.

Surely, not all things can be carried out in a SPROC in the database. For exmaple, sending email, SMS, calling third-party APIs - while they are supported by Chameleon- are challenging to be performed at database side.

Chameleon may be suited best for monolithic, small to mid-scale, web applications with low traffic load.

It must also be noted that, it is possible to use Chameleon for a portion of a website, not all of the website or web application.

What is important is that, the idea of Chameleon may shed light onto a new kind of web applications that are offered as a single package (a database) and are easier to be developed and maintaned.

About