Update
Pretty much about a month since last update (codewise) and sorry for the low update rate but the previous weeks have been very time consuming and I've skipped reporting. Also, I'm upgrading my dev infra and I'm now using macOS with M1 chip. This has pushed new development in docker multi-arch builds (which I haven't announced yet) and that also took me time from V4.
But enough chatter, here's the ongoing development report for Chevereto V4.0!
Multi-architecture
Support for different CPU instructions is now a thing for V4.0 and our official Docker
imaginery will be amd64 and arm64v8 compatible. More architectures will be added based on demand, on usage requirements. Why I picked those by default? I run machines with these so I provide support for what I use. In any case, feel free to suggest other architectures 😊.
Routing definition
For V4.0 I will introduce a new routing spec for declaring routes in the system. Remember the
route.json.php file? That's part of the routing system, in which case that file define all what
/json does. That system is being replaced with an endpoint to controller logic.
Wow, sounds great... But is better if you see it, we go from this:
To this:
Routes are now defined on file(s), and it allows to easily declare route endpoints (a path + HTTP method + a Controller for that method). This makes way more easier to understand how the system works, if you have ever tried to find something in V3 you will surely welcome this change.
With this we now can easily create new routes, or move something from one path to another.
Controllers
The Controller is in charge of defining parameters for client requests made to the application. The file below is V4's representation of
route.api.php taking input parameters.
The controller layer defines what it does at
getDescription, the
__ you see is our new translation system, that stuff is replacing the old
_s, _se, _n, _ne gang used to declare translations, the new system is more flexible (will talk about that on another update).
If you pay attention to
getParameters you will notice that
format parameter takes a regex, that enables already a filtering layer for incoming requests.
As you may see there's a lot of PHP 8 (I like to call it
The Ocho) on V4. Besides the clever usage of named arguments, there are attributes which in the case of the controller example above it links to a
Workflow provider.
A
what provider??!
Workflow Provider for Controller
At line #24 in the code above there's the relationship attribute that links to the
UploadPostWorkflow, this is a simple class that using
getWorkflow() provides a set of default instructions (Actions) to carry in sequential order:
I think that the logic is very expressive, you get all the steps in order and a very descriptive instruction set... What I wanted to achieve is to allow anyone to easily understand (therefore extend) what the system does. The new logic starts from the very basic elements, and easily drives you towards exactly what the system is doing.
Actions
There are also actions, in fact... that's the actual logic. Here's how the system goes: Routing > Controller > Workflow > Action.
Actions are the most basic form of functions in the system, it defines parameters and arunnablee logic that's all. These exists in a deeper level, is not a "surface" element as Controller.
What I'm achieving with actions is that I'm creating disposable sets of useful "things" that the application can do. Nothing stops you from creating your own routes, map to your own defined workflows, use the default actions or provide others, is really flexible.
Progress status
Being honest, I'm quite delayed for the September goal but I will get a better idea by the end of this month. There's a lot of new development (specially in routing) which is allowing me to gain more speed and that was introduced just 2 days ago.
I will dare to say that V4.0 is 20% done and likely I will take some shortcuts because I really don't want to delay this any further.
Hope you like the heads up and thanks for your support and patience!
