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.
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
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.
To learn more about instructions on how to install and run a sample
Chameleon website, click here.
Chameleon's pipeline can be described in the following steps:
- The Host receives a web request.
- It fills
chameleoncontext 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.
The idea can be implemented in any modern RDBMS that supports stored-procedures such as
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.
As it was said, the
Host part of
Chameleon is technology agnostic. It can be developed in any server-side technology such as
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.
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.
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.
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:
In order to learn more about
Chameleon middlewares click here
Chameleon is performed by a middleware named
RoutingMiddleware. Routing details and its rules are described here.
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.
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 script is described here.
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.
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
Chameleongreatly 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
Chameleonrequires 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-SQLscript over database.
Chameleonshortcuts 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:
Chameleonhas 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
ChameleonDbdatabase. Nothing else is needed.
Chameleoncontains 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.
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
Chameleonnot only should the database engine perform its routine job (handling data), but also should run business logic.
Chameleonadds or to say better imposes application load onto the database too!
Lazy and Slow:
Chameleonbrings 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.
Chameleonmoves 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
switchstructure) 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
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 patterndoes not apply in this framework.
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.