Ubiquity Guiding Principles

[n0nag0n]

Hi @jcheron ,

So I know that ubiquity is ridiculously fast, but I wondered if you had a set of guiding principles that you use when you develop PHP code? I've seen this page, which seems to be geared more towards how people implement your framework, but I was wondering what you do when you develop your own framework? What lessons have you learned and what habits did you have to break in order to achieve the level of optimization that your framework enjoys? I also noticed your php benchmarks tool which is awesome!

From what I've gathered, it feels like a couple bullet points would at least be:

• Use as little data or strip out as much data as possible when dealing with.......anything
• At least with your routes, those are not dynamically interpreted, but you instead generate a cache of them. What did you learn as you optimized this?

Anyway, TIA. I'm sure you have a wealth of knowledge to share and I (and the world in general) would love hearing what you have to say :)

[n0nag0n]

BTW I've done a little of my own benchmarking in certain cases with classes vs arrays https://stackoverflow.com/a/64157551/721019. I also have found that foreach() in general is faster than something like array_map(function($value) { return doSomething($value); }, $values);

[jcheron]

Hi @n0nag0n
I will take the time to think about it, to answer seriously.

I have the impression that the secret, which is not a secret, is based on obvious.
The Pareto principle applies in many situations.
80% of the operations carried out in a development require only 20% of the functionalities of a Framework.
It is therefore necessary to pay particular attention to these 20% that are particularly solicited. And not to accept any performance degradation to integrate marginal functionalities.

Among this 20%, in a web application, we find the routing system that allows URL resolution.
The objective is to achieve this resolution as quickly as possible.
Rather than a long speech, it is better to have a schema:

Ubiquity routing

Nothing but simple things :
For the framework start-up:

• few file inclusion (composer autoloader + config & services files)
• few objects instanciation (only for the CacheSystem and the controller used)

This start-up phase does not need to be done at each request with async platforms (Swoole, Workerman, Roadrunner, ngx_php...).

URL resolution:

• The URL resolution is usually done by direct access to the cache, or by search in case of URL with variable parts.
• Most of the requested methods are static.
• Some methods are based on the principles of functional programming and have recourse to memoization.

[n0nag0n]

[jcheron]

And while you're eating your popcorn on the sofa, let me pick up another important mechanism:

the execution of an action

Here again, only simple things:

• Using inheritance and overriding (initialize, isValid, finalize... from Controller base class)
• Injection of dependency limited to controllers
• No middleware or other complex and expensive injection
• No route access to the execution context

There is a snobbery effect in the world of PHP developers, and some people think that such a simple design is synonymous with bad practice or bad design.
I am obviously not of this opinion and am hostile to the race for superfluous and expensive designs.
They make the developer forget that the quality of his application depends above all on the quality of his own design, not on the technology he uses or his ability to handle it.

You don't need to be an engineer to use an MVC framework.

[n0nag0n]

Nice diagrams :) So then would you mind explaining how you handle things like middleware (and injecting what you need for the middleware)? Also when you say the routing is parsed from cache, what do you do with dynamic routes (/companies/123 vs /companies which is static)? I see you separate them out, but then do you just use a regex to figure out your exact route or do you use another method?

[n0nag0n]

And how aggressive are you with your object creation and what is in the object? For instance you have the URequest object which will be used on every request. Do you pass that object around in Controller::initialize()? Looking at the framework it looks like you do. And when you pass it in do you pass in as few properties as possible (almost whitelisting them into the object)?

Also a pattern I notice in looking through your code for instance is with your View class, you don't actually inject anything. You just have a startup class that holds your View object that you then call into your View class when rendering out something. Out of curiosity is this because you noticed that passing in objects to classes was a performance hit?

[jcheron]

Request

URequest is a class that I call Wrapper to the elements linked to the query ($_POST, $_GET, $_REQUEST ...)
It's a utility class that only has static methods. So there is no instance of URequest.
By choice, Ubiquity does not implement PSR7, so no Request and no Response objects.
It's not so much the weight of the objects that is problematic, but the cost of switching from PHP super global variables to Request and Response objects.

Routing

While waiting to complete the middleware part, I come back to your question about routing.
For dynamic routes (with variable part), the resolution is done by examining each of the declared routes and comparing them with regular expression.
This part needs to be improved, since the complexity is here in O(n).
For the moment, I plan to structure the cache of the routes according to the fixed part :
rather than having this kind of thing:

[
    ['bar/(.*?)'=>route def],
    ['bar/foo/(.*?)'=>route def]
]

I'm considering this:

['bar'=>[
           '(.*?)' => route def,
           'foo' => [
                         '(.*?)' => route def
                      ]
            ]
]

As you can see, there is still work to be done in terms of optimisation.

Middlewares

On this subject, the answer is more complex...

To be continued