Full-stack SQL application

SQL is considered a back-end language. No surprise - declarative data-driven language fits very well into data manipulation layer. But can we categorize languages as back-end languages or front-end languages? It seems now it is getting harder and harder! It gets even more tangled - we've got something called middle-tier too. We can simple define it as "runs at server, but above database". Let's investigate that a little bit further using concrete specific as study cases.


Javascript was born as front-end language, used mainly for animation. It can be run at server - NodeJs! Now it is used as query language by some document databases. Full-stack language, for sure.


Another example - C#. It can be used as highest-level-of-front-end language after compilation (http://bridge.net/), but most usually is used for business logic in the middle-end. Can it be used as database-back-end language? Partially, for sure. We can create User Defined Function, but they are very restricted (read more).


Scala can be used for stream-processing and map/reduce jobs, can be run on JVM as general purpose language, and be interpreted inside you browser. Scala is full-stack language for sure!


We finally got to SQL. It has a special purpose to manage data, designed especially for relational database management systems, right? I've heard somewhere that SQL is turing complete language - and that means you are able to implement anything you want (although it can be tricky sometimes). Regarding my plan to get my SQL skills to higher (usable) level, I've decided to check on my skin if SQL can be indeed used as general purpose language.

[Beware, weird things are about to happen below]

I figured out a design like this:
* request gets to the server
* the request is serialized into XML
* the "Main" stored procedure is called with request as parameter, and returns response

No logic allowed in hosting application. The lightest solution I come up with was Nancy+ADO.NET. That application is indeed doing nothing more than calling one stored procedure. It's like server that calls extension that performs logic (just like in Apache + PHP for example, but here we have got Nancy + MsSQL).

The Router procedure is called, part of the url is dispatched and based on naming convention (...Controller) - appropriate Controller is called. Controller finds an action and the action fills the response output parameter using view function. Full stack from routing(I consider routing as user interaction too) to database. MVC pattern. What else would you ever need? ;)

Full source code

P.S. If you want to evangelize anyhow using phrases like "vendor lock-in" or "DB is not a place for business logic at all" then please... take a break ;]