How I Wrote My Own Framework

Written in TypeScript and leverage Dependency Injection

Due to already having experience with TypeScript and its use with Angular, I chose to write the framework in TypeScript. I leveraged the experimental support for decorators to create a simple yet powerful Dependency Injector that parsed the constructor parameters and, combined with the 'reflect-metadata' library, can determine the requested providers, and apply them as needed. One challenge that arose for dependency injection was circular dependencies and the Typescript compiler’s inability to determine the requested type at compile time, so a new decorator, called Forward Reference, was created to allow the framework to fetch the type at runtime instead.

As of the current release, the server class is the only aspect of the framework that is not handled through dependency injection. The primary purpose of the class is to bootstrap the dependency injector and create the HTTP (s) request listeners, which means the code base is highly malleable. If a particular aspect does not suit a project, we can simply replace it. For example, if a particular session storage adaptor is not supported out of the box, a quick replacement can be provided to the dependency injector, and that will be used instead.

Several existing frameworks separated out the routing and controllers

During the experimentation of several existing frameworks at the time, the practice of separating out routing and their controllers into separate files was an annoyance. It didn't match my goal of an MVC pattern, and so I once again turned to decorators allowing the controllers to declare the route(s) for their methods. This simplified the code base and helped improve the developer experience in finding methods within controllers for troublesome routes.

Over time, repeated code, such as typical CRUD operations, were abstracted away to the framework, and 'helper' decorators were provided to perform those tasks reliably every time.

All this combined to produce controllers that did what they were intended to do, receive requests, handle the data, and return a response.

Continue supporting MySQL for existing projects and models required to be active records

This was probably the most challenging aspect to get right, and the abstract model class went through several iterations before the current version was finalised. One of the key features I liked most about Yii 2 is the support for active records and strict data validation. I felt I must replicate this thoroughly to ensure the security and usability of the framework. Once again, I leveraged decorators to help build a model and its columns to provide TypeScript with complete typing whilst under the hood adding all the required functionality to create a reliable active record.

The next step was to ensure data processing, such as loading from a network request or saving to the database, would only occur if the current model passed its validation rules. By declaring rules on each model's class definition, the developer can ensure only allowed data is loaded into a model and prior to saving, the model passes those same rules. This help ensures that combined with query parameter usage, common attack vectors are protected against automatically, such as SQL injection. As a default, the framework will revert to security first. Therefore, only columns for which validation rules have been declared will be loaded into the model, and all other data is simply ignored.