💥Pionia framework🚀 - initially a "hobby project"!

Pionia framework started as my hobby project, but now, I really can't tell where its roads are leading!

I started Pionia to just challenge the status quo. I saw that some things are just made in the name of "standardisation" yet we don't need them.

Now Pionia is one of my favourite frameworks and I intend to put everything I would wish for a cool framework to have.

On its official docs, I defined its road map and how far it still has to go. Whereas I may be slow in achieving all the features defined, someday, all of them will be achieved.

In the start, I used to post articles comparing Pionia with most PHP frameworks, but that was all wrong! Pionia shouldn't be compared with any since its pattern - moonlight is like no other! Well, some say Moonlight is close to GraphQL, which I don't deny by the way, but it's a bit better!

That said, the following targets have already been achieved!

👉 Fully customisable security in terms of authentication and authorisation. Pionia approaches RBAC the same way Spring Boot does while borrowing the concept of authentication backends from Django. Our authentication backends work in a chain format, when one authenticates the user into our context, we break the chain and ignore the rest! This implies you can create an authentication backend for your mobile app different from the one of your Web apps, it's that cool!
Authentication and authorisation is done on the service level or action level.

Remember, services in Pionia are just PHP classes that group together related business logic(actions) e.g. AuthService and actions are just php class methods that perform a single unit of work such as login

👉 Fully customised database management.
Pionia, like Spring Boot and other cool frameworks of Yii and Express, can be used with 0 Models(no model layer), but unlike these frameworks, there is even no support for that layer at all. Whereas a few somehow "lazy" 😒 developers will claim that this is a bad😠 approach, but it's the best part. Most frameworks become slow while hydrating query results into model classes, especially in instances of selecting multiple records, Pionia will never face that. It won't even need to cache queries, because the only reason why queries are cached is to avoid model hydration as much as possible! Pionia comes shipped up with Porm(which is also maintained by the same team) that will enable you to perform all queries you need even complex ones without breaking a sweat. Pionia has also inbuilt mechanisms to query multiple databases at ago and also paginate your data smoothly!

👉 This one comes from a common saying, "Too many cooks, spoil the soup". Pionia believes the term controller has been misused. There should always be just one controller - looking at your project as if it's a car, you can't have multiple steering wheels! So, the only controller in Pionia, you as an end developer won't even interact with it since it's just one and Pionia decided to take care of it! This also implies that we have a single endpoint(well, this is also per API version).
Now, I would like you to take a moment and imagine your Laravel code, doing the exact staff, but with no controllers, no models, no routes(different approach for this too), Just one switch(Pionia-specific concept) for your entire API version and one endpoint!

routes.php

$router  = new PioniaRouter();

$router->addSwitchFor("\app\switches\V1Switch", "v1")
        ->addSwitchFor("\app\switches\V2Switch", "v2")
        ->addSwitchFor("\app\switches\V3Switch", "v2");

switches/V1Switch

class V1Switch extends BaseApiServiceSwitch
{
    /**
     * @inheritDoc
     */
    protected function registerServices(): array
    {
        return [
            'service1' => new ServiceOne(),
            'service2' => new ServiceTwo(),
        ];
    }
}

👉 Developer Performance matters✊️✊️. I believe developers should be able to roll out an API in just hours or minutes, Pionia believes too! This is a concept that is very common in Django Rest Framework using their generic views. Pionia also ships in Generic Services. These specifically help you to create(with uploads in mind), delete, retrieve/details, update, list, and list(paginated) without even writing 10 lines of code. These also work well with relationships(without models btw). Every time I have tried to pull off an API, these have always been my go-to. They also support full customization using hooks. Every action can be customised by you!

Pionia tends to make php development that easy just as we already see in frameworks like Rails and Django.

Developers also usually face the problem of a huge, growing and hard-to-inherit codebase. Pionia solved this too. This is solved by the concept of services, the only part of Pionia that Developers will always play with, while Pionia takes care of the rest of the other parts!

👉 The middleware concept is great. Pionia believes that Developers should find it easy to intercept every request and response, and do some logic or checks.
So, we support middlewares too! But how we write them, is surprisingly simpler, unlike most frameworks, well, we don't approach the same way in the first place, so we can't boot them on the routes(which was usually confusing to many devs), here, these are just classes in the middlewares folder, registered in our "settings.ini" under the middlewares section. And that's it! You can now maybe encrypt and decrypt all your requests before they even hit your authentication backends or do anything you wish, anything, anything on both the request and response!

[middleware]
; you middleware here

👉 Frontend integration should be easy, for crying 😢 😭 out loud!

Whatever is happening in the current front end these days is strange! SPA were supposed to be a good deal! The problem came when Developers wanted to write Frontend logic on the backend! Am one of those few nerds who believe Javascript should never be written on the server no matter the performance gains, it's not worth the consequences!

A library called jet-fetch which is a simple wrapper on top of our normal and elegant fetch API, has been put forward but majorly with one unique feature on top of having JWT authentication in mind, querying moonlight backends. Pionia is one of them, so using this library, just write your normal Vue, react, angular and query your backend well.
Developers who overused server-side rendering have also struggled when it came to integration with multiple frontend architectures in the same API, like serving your mobile, web and electron apps with the same API.
So, Pionia believes Frontend should stay that way, and the back end should stay in its lane too!

Just because you can doesn't usually mean you should!

Pionia is also putting measures to serve your front end by your backend in production. This means, that after completing your frontend, you build it, drop it in a certain folder in your backend, and then you just host your backend!

This is already seen in Spring Boot Java; yes, it's coming to PHP.

👉 API versioning can be done better.

In Pionia, we believe that API endpoints should be something like "https://mydomain.com/api/version/", and that should be just one in your entire app. This implies that version one can be /api/v1/ and version two can be /api/v2/.

This is exactly what Pionia does. In our routes.php you will find a method called addSwitchFor which determines the switch class we are pointing to and its version.

use Pionia\Core\Routing\PioniaRouter;
$router  = new PioniaRouter();
$router->addSwitchFor("\app\switches\V1Switch", "v1");

The above tells Pionia that all traffic coming through /api/v1/ should be routed to the MainSwitch.

Look at switches as your normal home electricity switches, all those electronics connected to that switch are flipped whenever the switch is flipped. Turning the switch off cuts current from all the connected electronics and the reverse. The same as in Pionia, only those services registered in the given switch are managed and considered when that switch is called. Here, calling the switch is like flipping it to one state.

This implies, that to roll out a new API version, you only need to register a new switch and register it in the routes with the version that shall reference it. Also, this implies that the entire service can be registered in multiple switches! The frontend team only changes the version on their base URL, how cool 😎 😀 is that! If you're using jet-fetch this is already taken care of for you!

import { Jet } from 'jet-fetch';
const rocket = new Jet({
  baseUrl: 'http://localhost:8000/api/',
});

const res = await rocket.moonlightRequest(
{ service: 'yourService', action: 'yourAction', ...anyOtherData }, 'v2/');

I can spend the entire day trying to discuss all the special features of Pionia and the entire moonlight ✨️ pattern, but if you have noticed all the mentioned features, they are concepts that have so far gone wrong with our current backend development especially when it comes to API Development.

If there is anything you would wish for Pionia(Moonlight) to address, anything you feel has already gone in a weird direction, please mention it in the comment section below.

If you're looking for the docs of Pionia, which are only 40% complete(🫨🫨), you can find them here

You can also join us on X and share with us your experience