Storing the code in the database or collect the code brick by brick

This article is written by Napolsky . For a known reason, he could not publish it. If you liked the article - encourage the author in a known manner.

In this topic, I will talk about one approach I developed in web programming, the heart of which is storing code in a database. A few notes on the following text:

• Under the phrase "page code" means the executable (php) code
• In all matters relating to performance, there is a net page generation time, without the use of accelerators, caching systems, and so on.

How it all began

In order to understand, and “why it is actually necessary,” we will quickly go through the path that led me to the storage of the code in the database. It so happened that I started my way in web programming not by writing any scripts or modules for existing systems, but immediately by writing my own website engine from absolute zero. At this point, I had two years of programming experience in C ++ and, of course, tried to build my own web engine on OOP (though at that time PHP had one name from PHP :)). Within reason, I really love my “bikes”. Especially big ones. And before using a ready-made solution, I always ask myself: “Is it possible to write better?”.


In general, the writing of their bikes is very useful, especially for novice developers (when the first place is to raise professionalism, and not to write code in the allotted time and budget). Only writing your own solutions gives an understanding of how something is arranged from the inside at the lowest level. And this in turn gives an understanding of the complexity, resource intensity, speed of various approaches, which ultimately results in the choice of the right tools for solving the problem. For example, at the university we were forced to write our pushbacks for arrays, so that we would not forget that something much larger could seem to be hidden behind simple and trivial things.

The result was an engine built according to a rather classical scheme: folders with classes, modules, templates, and so on. Well, respectively, the endless inclusions of all this when generating pages. And since the rationalizer lives in me, as in many programmers, I was worried about the costs of this approach. In particular, most of all I didn’t like the fact that I had to plug in a lot of “unnecessary” code (“dead” code that will not be executed on the page) for pages (for example, the entire library, when this page only needs one function her).
')
Have you thought about the number of "dead" code on the page? In fact, its amount is usually 7-15 times the amount of code that will actually be executed when the page is accessed. Take for example a class of comments. It will have the render (), delete (), edit (), add (), compress (), answer (), and so on methods. At the same time, only 1 of these methods will usually be called for 1 script execution (delete delete, edit - when editing and t d), and the rest will not be called. So consider how many such extra code runs on the page.

At first, I tried to optimize, “cutting” and “gluing together” large libraries or classes to the needs of different pages, thus reducing the number of inclusions and dead code. But this, of course, is a dead end road. Time went by. Projects written on this engine (the kingdom of heaven :) they became more and more. Along with this, the number and size of the connected code grew, and with it the time of page generation. I began to think more and more about how to get rid of the "dead" code. And then I was visited by a bold, even crazy thought. What if…

The birth of an idea

But what if you divide the code into as small independent parts as possible so that you can only collect what you really need on the page? That is, to separate all functions, classes (ideally, and methods of classes), and so on. Thus, we will get many many small "bricks", from which we will later fold the page. Thus, it will be possible to completely get rid of the "dead" code and inclusions . I was really excited by this idea, but there were more questions than answers: how to do it, would it work, what pitfalls await in implementation, how fast is such a system? In short, so far I have not had any idea how to implement it and how it will work. But try, of course, worth it.

Warrior's way

The ideology is that by breaking everything into as small pieces of code as possible, we can collect anything from them. There was no question of how to store code “bricks” - since they were not code, but were essentially data with a set attributes, the only possible option was to use db. I will try to show the principle of operation of such a system as simply and abstractly as possible, only by conveying the essence.

1 Storing bricks

Everything is simple and clear: each individual function, a class (and even a class method is better), a module controller, a module presentation, and so on are a separate line in the database. For example, in the simplest case, the table can be of the form id | code | name | componentType (where componentType is a type of brick (function, class, module ..))

2 Storage dependencies

Since the code of one brick can cause another brick (for example, function-function type, module-function dependencies, or even page-module dependencies), you need to store replications. This can be done using the replication table, which, in the simplest case, has the form id | parentId | childId . Thus, we solve the problem of proper collection of “bricks” for nested structures:

function A()
{
B();
}


, «» B. B.

3

, , ? , , , «» . Codegen. , «». : . «» . : 1 , .

. , Codegen, , ( eval ).

:
—
— «»


:

• 12000-14000 1500-2000
• 16-22 0
• 0.25-0.3 0.04-0.05 (~600%. , . )

.


- IDE. . , / ( ). , . . ( , ..) . , , IDE .

- . . , - eval, .

-. , . , .

:

,

, , . , — .

/backup/update

… sql( ) , .

,

. .

, , , , «» on site

( ) . .


— . . , «» , .
— . , .
— . , , . , .
— . , codegen, . , . : - ,

if(!$user->isAdmin()) {ErrorLog(' '); return;}


_CHECKADMIN


. .

, , . , , . , , , : . -, «» . , , . , , CMS, .

P.S. , .