Introduction to Ilmiont NET
One year ago, I began a project that has evolved into my most significant effort since I took up web development. To act as a base for future APIs and services, I set out to create my own Model-View-Controller (MVC) framework, using vanilla PHP. The result is Ilmiont NET, the underlying framework that powers the CMS behind my blog.
My reasons for building from scratch what existing solutions provide in minutes are complex so I'll detail them further in a future post. Today, I'm more interested in providing an overview of Ilmiont NET, introducing its features, layers and implementation. This article assumes some prior knowledge of backend web technologies but doesn't go in-depth on any language-specific details.
MVC & COR
Ilmiont NET is based on a traditional MVC stack. For those unfamiliar with this terminology, MVC stands for Model, View and Controller. It's a structured way of writing applications that simplifies the process of taking input from the user, collecting information from a database and presenting it in some way.
Controllers prepare data to pass to models for execution against the database. Models represent individual object types in the database. Views are outputted to the user, using information supplied by the models. This approach affords consistent separation of concerns, enabling you to build more structured applications. Keeping your logic separate from your presentation lets you place a larger focus on object-oriented programming and facilitates greater modularisation of components.
For Ilmiont NET, I took the traditional MVC formula and revised the terminology to something more self-explanatory and appropriate for what I wanted to create. I still use controllers and they have largely the same purpose as in traditional MVC. Models, however, are renamed "objects" and views become "renderers." This creates "COR", or Controller, Object & Renderer.
The links between the three components are similar to those in traditional MVC, albeit again with some deviations. Controllers contain the majority of each endpoint's functionality and are publicly accessible to the request router. They access data from the database through the Objects, and then pass this information to Renderers for output. The major difference here is that the models and views cannot directly communicate, further separating the logic/data and presentation layers.
Framework or Hosting Platform?
With the methodology tidied up, I can introduce Ilmiont NET's core functionality. Ilmiont NET is a self-contained web-app hosting platform, comprising a full request routing, data handling and renderer parsing stack. It's built on top of PHP5 and is designed for Apache2, although it could run on other servers.
Unlike a traditional application "framework," Ilmiont NET is not included by the projects that are built using it. Instead, Ilmiont NET is installed on the server as a basic hosting platform. A management interface is provided, enabling administrators to install apps on top of Ilmiont NET. These are written in PHP, using the COR approach explained above, and can access Ilmiont NET features through function calls.
Once an app is installed, such as the Ilmiont CMS content management system, it is automatically accessible using Ilmiont NET's system routing engine. Each controller defined by the app becomes an endpoint with the public methods of the controller accessible to outside requests. In this example, visiting "ilmiontnet/ilmiontcms" will already resolve to Ilmiont CMS' default controller.
This makes it simple to build a new API or service. You define your controllers, database objects and HTML templates, create a JSON file telling Ilmiont NET which files to install on the server and whether a database is required, and immediately your web service is accessible. There's no need to worry about including a templating engine, database abstraction layer or request router - this will all be handled automatically.
Ilmiont NET also provides a single configuration interface for system administrators to configure server settings from. Additionally, the global users table provides apps with a one-line approach to restricting user access, without the need for each new service to implement its own authentication layer. Much of this will be expanded upon in the future.
While this introduction may not be the clearest, or shortest, I hope it begins to outline how Ilmiont NET operates and what it is. However, the version I've discussed today is just an early alpha, finally prepared to a state where it can support the Ilmiont CMS app and hence this website. I'm planning a major architectural overhaul to take place in the coming months that may dramatically transform Ilmiont NET's operation, although I've yet to finalise anything.
In particular, the platform may begin to head back towards being a pure PHP framework, included by projects that use it. While the server platform approach is good, it introduces problems around dependencies when Ilmiont NET is updated and apps don't support the new version. There are pros and cons to both approaches and I'm currently trying to find a middle ground between the two.
I've learnt a lot by building from scratch what most people wouldn't even consider creating. The first iteration of this product is far from complete though and there's a still long way to go before Ilmiont NET will see a public release. I'm committed to getting this technology to a state where that's possible however, even if it is likely to be years down the line.