DEV Community: Tumusiime Ezra Jnr

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

Tumusiime Ezra Jnr — Fri, 26 Jul 2024 07:28:40 +0000

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

Another framework, Arrrgggg!!!

Tumusiime Ezra Jnr — Wed, 10 Jul 2024 07:07:46 +0000

Another PHP framework? Arrrgggg!!! More like, why not?

Pionia framework has the answer for this. Pionia trims off the unnecessary concerns of developing apis and you stay focused on only your business logic.

It also somehow meets both configuration and conventions in the midway.

Imagine scenarios where an api is done with in 20 mins, well, in python and Ruby that's not an imagination, but in php it was, but not anymore.

Frameworks like laravel are really good for fullstack applications and they shine that way. But if you intend to only pull off an API that will be easy to integrate with your frontend, then Pionia is your answer.

Why so?

Single request format.
The server won't have to keep switching protocols to watch your requests. Everything is POST and with the $data key in your actions, all your request data is there. You pick what you want, or mark required the data you need.
Single Response format whether on failure or success! Really? Is that even nice? You may ask!

Yes it is, this is how. We introduce the concept of returnCodes for Status Codes. We maintain the same Status code 200 OK for all the requests that hit the application server, and as you already know, when a request returns 200 OK, tools like axios give you access to the returned data, now in the returned data, you get to set your own returnCode, you can maintain the existing http codes but you're also open now to even define your custom ones.

Thus the frontend does not need to read errors from the catch block of your http, but in the same try block, everything is there!

Now, I don't know if it was only me, but reading errors in axios was not my favorite part, but now, with Pionia, it is because it's not any different!

As you see the first two points, they have a new advantage they introduce, the fact that both the request and response are the same throughout, then it means one endpoint is enough for an entire app! Now, this is not an innovation, it's just an implementation. We have already seen API Gateways and Graphql tending to this path, and how about a framework that has it as the default behaviour.

After implementing this, we didn't need routes and controllers in Pionia, but also a new concept of Switches was introduced. Switches read the service and action defined in the request and point the entire traffic directly to that service(php class) and action(class method).

This is great, it implies that in your app, your entire logic has reduced to just your services. So like that, we have achieved developer performance since you focus on only services not forgetting maintainability too! Your code is easy to inherit since even the new dev will only have to look at services.

Generics in Pionia are another concept to get you started in seconds. These, if well used, can even reduce your time to pull off an API from minutes to even seconds.

Battle-tested components. We also believe that if something is working well, then don't reinvent it. That's why Pionia at it's core stands on the shoulders of giants like symfony and Nette. Our code generators are powered by Nette, our tests are powered by phpunit, our logs are powered by Monolog, our request sanitisation mechanisms are powered by symfony. This implies that most of the components working in Pionia are battle-tested to work with complex projects without breaking a sweat😓

Pionia also does more than this, it gives us a new approach to look at RBAC in php which is inspired by the combination of spring boot and django bytheway. This includes use of authentication backends that will set the ContextUserObject. So, no matter what you want to use, you're totally free! As long as you set the context user object. The framework being fully restful also expects your authentication to be stateless or sessionless. So anything you have in mind should work with Pionia framework!

Middlewares are still here. That means you get perform great staff like request sanitisation, encryption and decryption using our Middlewares!!

On program performance in abit, Pionia removes the model layer! Whyyyyyy?? Another great thing gone!! Damn framework!!! You may say!

But Rest applications are meant to return json data. This can be an array or object. Php as php knows both datatypes and gives you various ways to interact with them. So, when you query your database and get back your results, they are in one of the above formats. This is the normal underlying PDO. However, when you have models, then you do something called model hydration. This is where the above arrays and objects are mapped to a certain class. With objects, this might not be a big problem, but with arrays of objects, this is really expensive!

So, Pionia also knows that you need to easily query your database well, so, it has a tool called Porm. Porm can help you query any database supported by PDO and return the results in the format that is ready for exposure as an API.

This also has another added advantage. It implies Porm can work with all your already existing databases. We believe backend developers should focus on that and database engineers should focus on that! And yet, with this QueryBuilder, backend engineers can query any database whether new or existing and to make it more fun, multiple databases at a time!!

This should be just words, head over to https://pionia.netlify.app and see for yourself.

We welcome all contributions, criticisms sponsorship as that's how we shall grow!!

Have fun 😁

Getting started with Pionia Framework

Tumusiime Ezra Jnr — Sat, 06 Jul 2024 19:30:29 +0000

For this specific article, I will save you from the backgrounds and inspirations of the framework. You can always find those in the official framework documentation here.

However, let's get to work and draft a simple API in less than 20 minutes.

The following sections assume you're running PHP 8.1+, the composer is already set up and you have any RDBMS database preferably one of MySQL and Postgres.

What we shall be working on today.

We shall create an API that:-

Creates a todo
Deletes a todo
Marks a todo as complete
Queries completed todos
Queries 1 or more random incomplete todo[s]
Returns a list of all todos
Returns a list of paginated todos
Updates a todo
Returns a single todo items
Returns overdue todos

This sounds and looks simple, but by the end of the day, you shall be able to perform all CRUD operations in Pionia, data filtration and interacting with Pionia APIs.

Our project shall be called todoApp.

For starters, we shall need to bootstrap a Pionia project using the following command.

composer create-project pionia/pionia-app todoApp

On successful installation, you should have a directory similar to this though missing a few folders. Our focus folder is app/services. Other folders can be added when needed especially using our pionia command.

Pionia does not use models, therefore, it can work with only existing databases. For starters, you need to create your database, whether in Postgres, SQLite, MySQL, or any other database supported by PHP PDO.

For this guide, we shall use MySQL and create a database called todo_app_db . In your mysql console run the following.

CREATE DATABASE todo_app_db;
use todo_app_db;

Then, let's add the table that we shall be working with.

create table todo
(
    id          bigint auto_increment,
    title       varchar(225)                        null,
    description text                                null,
    created_at  timestamp default CURRENT_TIMESTAMP null,
    start_date  date                                not null,
    end_date    date                                not null,
    completed   bool      default false             null,
    constraint table_name_pk
        primary key (id)
);

This is all outside the Pionia framework. Let's come back to Pionia now.

We already have our default switch targeting /api/v1/ registered already. This can be viewed in the routes.php file.

use Pionia\Core\Routing\PioniaRouter;

$router = new PioniaRouter();

$router->addSwitchFor("application\switches\MainApiSwitch");

return $router->getRoutes();

And if we look at application\switches\MainApiSwitch, we find it is registering the UserService. Let's drop that and create our service. Remember to remove the import too - use application\services\UserService;

public function registerServices(): array
    {
        return [
            'user' => new UserService(), // remove this
        ];
    }
}

Now it should be looking like this.

public function registerServices(): array
    {
        return [

        ];
    }
}

Head over to services folder and remove the UserService too. We want to add our own.

In your terminal, run the following command.

 php pionia addservice todo

This shall create our new service TodoService in the services folder looking like this.

<?php

/**
 * This service is auto-generated from pionia cli.
 * Remember to register your this service as TodoService in your service switch.
 */

namespace application\services;

use Pionia\Request\BaseRestService;
use Pionia\Response\BaseResponse;

class TodoService extends BaseRestService
{
    /**
     * In the request object, you can hit this service using - {'ACTION': 'getTodo', 'SERVICE':'TodoService' ...otherData}
     */
    protected function getTodo(?array $data, ?array $files): BaseResponse
    {
        return BaseResponse::JsonResponse(0, 'You have reached get action');
    }


    /**
     * In the request object, you can hit this service using - {'ACTION': 'createTodo', 'SERVICE':'TodoService' ...otherData}
     */
    protected function createTodo(?array $data, ?array $files): BaseResponse
    {
        return BaseResponse::JsonResponse(0, 'You have reached create action');
    }


    /**
     * In the request object, you can hit this service using - {'ACTION': 'listTodo', 'SERVICE':'TodoService' ...otherData}
     */
    protected function listTodo(?array $data, ?array $files): BaseResponse
    {
        return BaseResponse::JsonResponse(0, 'You have reached list action');
    }


    /**
     * In the request object, you can hit this service using - {'ACTION': 'deleteTodo', 'SERVICE':'TodoService' ...otherData}
     */
    protected function deleteTodo(?array $data, ?array $files): BaseResponse
    {
        return BaseResponse::JsonResponse(0, 'You have reached delete action');
    }
}

Before doing anything else, let's first register our service in the MainApiSwitch in our services under registerServices like this.

Also, since we don't intend to upload anything, let's remove all ?array $files from our actions.

public function registerServices(): array
    {
        return [
            'todo' => new TodoService(),
        ];
    }

So, let's test what we have so far. Run the server using the following command.

php pionia serve

Your app is being served under http://localhost:8000 but your API is served under /api/v1/ . Let's first open http://localhost:8000, you should see the following.

Now let's try to open http://localhost:8000/api/v1 in browser. If you have JSONViewer installed, you should see this.

All get requests in Pionia will return the above! Therefore to test our service we need to make POST requests, we might not pull that off in the browser, so, I suggest we use Postman.

Fire up your postman or whatever you want to use. I will use Postman. All our services can receive either JSON or form data. Form data should be preferred for file uploads.

For now, let's send JSON data.

{
    "SERVICE": "todo",
    "ACTION": "getTodo"
}

And we should get back the following.

{
    "returnCode": 0,
    "returnMessage": "You have reached get action",
    "returnData": null,
    "extraData": null
}

This is what we are returning in our getTodo:-

protected function getTodo(?array $data): BaseResponse
{
    return BaseResponse::JsonResponse(0, 'You have reached get action');
}

More about how we discovered the right action can be found here in the official docs

Now, let's add our database settings in our settings.ini file like this.

[db]
;change this to your db name
database = "todo_app_db"
;change this to your db username
username = "root"
type = "mysql"
host = "localhost"
password = ""
port = 3306

To see what is happening in real time, Pionia ships in with a logger, open a new terminal window and run the following command.

tail -f server.log

You can also edit the logging behaviour in the settings file as below.

[SERVER]
port=8000
DEBUG=true
LOG_REQUESTS=true
PORT=8000
LOG_DESTINATION=server.log ; the file to log to.
NOT_FOUND_CODE=404
UNAUTHENTICATED_CODE=401
SERVER_ERROR_CODE=500
HIDE_IN_LOGS= ; what fields should be encrypted in logs
HIDE_SUB= ; the string to replace with the hidde value default is ********
LOGGED_SETTINGS= ; the settings to add in logs eg db,SERVER
LOG_FORMAT=TEXT ; can be json or test
;APP_NAME= ; you can override this as the app name. default is Pionia.

After setting this up, you be able to now view all requests and responses in your terminal.

So far we have not yet started coding anything. Just adding optional configurations to our app.

Let's start by creating a todo in our createTodo action.

protected function createTodo(?array $data): BaseResponse
    {
        $this->requires(['title', 'description', 'start_date', 'end_date']);

        $title = $data['title'];
        $description = $data['description'];
        $startDate = date( 'Y-m-d', strtotime($data['start_date']));
        $endDate = date( 'Y-m-d', strtotime($data['end_date']));


        $saved = Porm::table('todo')->save([
            'title' => $title,
            'description' => $description,
            'start_date' => $startDate,
            'end_date' => $endDate
        ]);

        return BaseResponse::JsonResponse(0,
            'You have successfully created a new todo',
            $saved
        );
    }

Then let's send our request to target this action with all the required data like this.

{
    "SERVICE": "todo",
    "ACTION": "createTodo",
    "title": "Am a brand new todo",
    "description":"Am the description of the brand new todo",
    "start_date":"12/12/2024",
    "end_date":"06/06/2024"
}

And we shall get back our response like this.

{
    "returnCode": 0,
    "returnMessage": "You have successfully created a new todo",
    "returnData": {
        "id": 12,
        "title": "Am a brand new todo",
        "description": "Am the description of the brand new todo",
        "created_at": "2024-07-06 22:23:47",
        "start_date": "2024-12-12",
        "end_date": "2024-06-06",
        "completed": 0
    },
    "extraData": null
}

To shed some light on what is going on. The client requested /api/v1/, in the request, the client defined the SERVICE it is targeting, and the ACTION. This came straight to our index.php which also calls the kernel and sends all these requests to it.

The kernel sanitises the request and checks if there is an endpoint that handles /api/v1, it then sends the entire sanitised request to the switch in our case, the MainApiSwich, this in turn checks if it has any service that matches the SERVICE name that came through our request. It discovered that there is and it is called TodoService. It loads this service and calls the method that matches the name of the ACTION key, passing along all the request data as $data.

The action also expects certain data to be available in the request. This can be observed on this line.

$this->requires(['title', 'description', 'start_date', 'end_date']);

If any of the required data is not found on the request. The request will abort with a clean exception. Let's test this.

In your postman, delete the title key and send it as follows:-

{
    "SERVICE": "todo",
    "ACTION": "createTodo",
    "description":"Am the description of the brand new todo",
    "start_date":"12/12/2024",
    "end_date":"06/06/2024"
}

This will fail like below:-

{
    "returnCode": 500,
    "returnMessage": "The field title is required",
    "returnData": null,
    "extraData": null
}

Notice that all scenarios still return an HTTP Status Code of 200 OK, but different returnCode[s]. Also, notice that the response format stays the same throughout. This is moonlight pattern in action!

This is how you can pull off actions in Pionia. However, Pionia suggests that if what you are looking for is just CRUD, then you can look into Generic Services. If you do not know about generic services, you can read about these in one of my articles here.

So, proceeding, let's first create the entire CRUD and see what generic services can help us reduce.

Full-Service code so far for our TodoService

<?php

/**
 * This service is auto-generated from pionia cli.
 * Remember to register this service as TodoService in your service switch.
 */

namespace application\services;

use Exception;
use Pionia\Exceptions\FailedRequiredException;
use Pionia\Request\BaseRestService;
use Pionia\Request\PaginationCore;
use Pionia\Response\BaseResponse;
use Porm\database\aggregation\Agg;
use Porm\database\builders\Where;
use Porm\exceptions\BaseDatabaseException;
use Porm\Porm;

class TodoService extends BaseRestService
{
    /**
     * In the request object, you can hit this service using - {'ACTION': 'getTodo', 'SERVICE':'TodoService' ...otherData}
     * @throws Exception
     */
    protected function getTodo(?array $data): BaseResponse
    {
        $this->requires(['id']);
        $id = $data['id'];
        $todo = Porm::table('todo')->get($id);
        return BaseResponse::JsonResponse(0, null, $todo);
    }


    /**
     * In the request object, you can hit this service using - {'ACTION': 'createTodo', 'SERVICE':'TodoService' ...otherData}
     * @throws Exception
     */
    protected function createTodo(?array $data): BaseResponse
    {
        $this->requires(['title', 'description', 'start_date', 'end_date']);

        $title = $data['title'];
        $description = $data['description'];
        $startDate = date( 'Y-m-d', strtotime($data['start_date']));
        $endDate = date( 'Y-m-d', strtotime($data['end_date']));


        $saved = Porm::table('todo')->save([
            'title' => $title,
            'description' => $description,
            'start_date' => $startDate,
            'end_date' => $endDate
        ]);

        return BaseResponse::JsonResponse(0,
            'You have successfully created a new todo',
            $saved
        );
    }


    /**
     * In the request object, you can hit this service using - {'ACTION': 'listTodo', 'SERVICE':'TodoService' ...otherData}
     * @throws BaseDatabaseException
     */
    protected function listTodo(?array $data): BaseResponse
    {
        $todos = Porm::table('todo')->all();
        return BaseResponse::JsonResponse(0, null, $todos);
    }


    /**
     * In the request object, you can hit this service using - {'ACTION': 'deleteTodo', 'SERVICE':'TodoService' ...otherData}
     * @throws Exception
     */
    protected function deleteTodo(?array $data): BaseResponse
    {
        $this->requires(['id']);
        $id = $data['id'];
        Porm::table('todo')->delete($id);
        return BaseResponse::JsonResponse(0, 'To-do deleted successfully');
    }

    /**
     * In the request object, you can hit this service using - {'ACTION': 'deleteTodo', 'SERVICE':'TodoService' ...otherData}
     * @throws Exception
     */
    protected function updateTodo(?array $data): BaseResponse
    {
        $this->requires(['id']);
        $id = $data['id'];
        $todo = Porm::table('todo')->get($id);
        if (!$todo) {
            throw new Exception("Todo with id $id not found");
        }

        $title = $data['title'] ?? $todo->title;
        $description = $data['description'] ?? $todo->description;
        $startDate = isset($data['start_date']) ? date( 'Y-m-d', strtotime($data['start_date'])) : $todo->start_date;
        $endDate = isset($data['end_date']) ? date( 'Y-m-d', strtotime($data['end_date'])) : $todo->end_date;
        $completed = $data['completed'] ?? $todo->completed;

        Porm::table('todo')->update([
            'title' => $title,
            'description' => $description,
            'start_date' => $startDate,
            'end_date' => $endDate,
            'completed' => $completed
        ], $id);

        $newTodo = Porm::table('todo')->get($id);

        return BaseResponse::JsonResponse(0, 'To-do updated successfully', $newTodo);
    }

    /**
     * @param $data
     * @return BaseResponse
     * @throws BaseDatabaseException
     * @throws Exception
     */
    protected function randomTodo($data): BaseResponse
    {
        $size = $data['size'] ?? 1;
        $todos = Porm::table('todo')->random($size);
        return BaseResponse::JsonResponse(0, null, $todos);
    }

    /**
     * @param $data
     * @return BaseResponse
     * @throws BaseDatabaseException
     * @throws Exception
     */
    protected function markComplete($data): BaseResponse
    {
        $this->requires(['id']);
        $id = $data['id'];

        $todo = Porm::table('todo')->get($id);
        if (!$todo) {
            throw new Exception("Todo with id $id not found");
        }
        if ($todo->completed) {
            throw new Exception("Todo with id $id is already completed");
        }

        Porm::table('todo')->update(['completed' => 1], $id);

        $newTodo = Porm::table('todo')->get($id);

        return BaseResponse::JsonResponse(0, 'To-do marked as completed', $newTodo);
    }

    /**
     * @throws BaseDatabaseException
     */
    protected function listCompletedTodos(): BaseResponse
    {
        $todos = Porm::table('todo')->where(['completed' => true])->all();
        return BaseResponse::JsonResponse(0, null, $todos);
    }

    /**
     * @throws BaseDatabaseException
     */
    protected function listPaginatedTodos($data): BaseResponse
    {
        $limit = $data['limit'] ?? 5;
        $offset = $data['offset'] ?? 0;

        $paginator = new PaginationCore($data, 'todo', $limit, $offset);

        $todos = $paginator->paginate();
        return BaseResponse::JsonResponse(0, null, $todos);
    }

    /**
     * @throws BaseDatabaseException
     */
    protected function listOverdueTodos(): BaseResponse
    {
        $today = date('Y-m-d');

        $todos = Porm::table('todo')
            ->where(
                Where::builder()->and([
                "end_date[<]" => $today,
                'completed' => false
            ])->build())
            ->all();

        return BaseResponse::JsonResponse(0, null, $todos);
    }
}

With the above, we have completed our entire checklist of all we needed to cover. Play with it in Postman to see if everything is functioning properly.

As you have noticed it, we only focused on services, nothing like controllers, routes, models!! This is how Pionia is changing how we develop APIs.

Let me know what you say about this framework in the comment section below.

Happy coding!

The Ultimate Guide to Pionia Generic Services.

Tumusiime Ezra Jnr — Sat, 06 Jul 2024 06:56:04 +0000

Pionia framework is a PHP Rest framework that is changing how we used to develop Rest platforms. Unlike all the existing frameworks, it gives the entire process a whole new look, making the development of APIs much simpler and less boring. This is because it runs on a different and rather 'new' pattern called moonlight.

Per se, moonlight is not a new architecture/pattern, most institutions/companies/developers have been using it but just unnamed. But today, we aren't talking about moonlight, you can read about it in my other article here and even leave your comments.

To bootstrap a new Pionia project, you need to run the following command assuming you already have composer set up.

Let's create a todo_app.

composer create-project pionia/pionia-app todo_app

You can also run the same project using the pionia command like below:

php pionia serve

To watch you logs as they happen in real time, open a second terminal and run the following command:

tail -f server.log

Background on services.

Services in the Pionia framework are the heart, probably the only part you will spend most of your time while developing your APIs. All normal services in Pionia extend Pionia\Request\BaseRestService. A normal service in Pionia may look like this.

namespace application\services;


use Exception;
use Pionia\Request\BaseRestService;
use Pionia\Response\BaseResponse;
use Porm\Porm;

class UserService extends BaseRestService
{
    /**
     * @throws Exception
     */
    protected function login(array $data): BaseResponse
    {
        // password and username are required, without them we won't proceed even
        $this->requires(["username", "password"]);

        $username = $data["username"];
        $password = password_hash($data['password'], PASSWORD_DEFAULT);

        $user = Porm::from('user')->get(['username' => $username, 'password' => $password]);
        //You can do more here, maybe generate a JWT token or add more checks
        // for example if the user is an active or not
        if ($user) {
            return BaseResponse::JsonResponse(0, "Login successful", $user);
        }
        throw new Exception("User with the given username and password not found");
    }

}

After building your service, you need to register it in the switch that shall be handling it from now on. If you are not aware of switches in Pionia, you can read about them here in the docs. So, head over to our switches folder, probably in the MainAppSwitch.php if you have not yet created another one, and register the above service as below in the registerServices method

     /**
     * Register your services here.
     *
     * @return array
     */
    public function registerServices(): array
    {
        return [
            'user' => new UserService(),
            'todo' => new TodoService()
        ];
    }

This is how you get your service to be auto-discovered by the kernel from now on. In typical settings, you would have added a router, and a controller to map to this service, but Pionia approaches things differently. Remember, you can have the same service registered in multiple switches. This is how we achieve the concept of API versioning since every switch is handled by its API endpoint. By default, MainAppSwitch can be accessed on /api/v1/.

In your requests, you can point to this service by sending the following.

// POST http://localhost:8000/api/v1/
{
    "SERVICE": "user",
    "ACTION": "login",
    "username": "pionia",
    "password": "pionia1234"
}

If you notice, ACTION is the name on the action/method we created in our SERVICE/service/class which we baptised the name user upon registration.

This is how normal services work in Pionia.

Below is a complete service that performs CRUD in Piona. It is based on the following simple table called todos in a MySQL database called todo_db.

create table todo_db.todos
(
    id          int auto_increment primary key,
    title       varchar(200)                        not null,
    description text                                null,
    created_at  timestamp default CURRENT_TIMESTAMP null
) engine = InnoDB;


use Exception;
use Pionia\Request\BaseRestService;
use Pionia\Request\PaginationCore;
use Pionia\Response\BaseResponse;
use Porm\exceptions\BaseDatabaseException;
use Porm\Porm;

class TodoService extends BaseRestService
{
    /**
     * Returns all todos
     * @throws Exception
     */
    public function list(): BaseResponse
    {
        $result = Porm::table('todos')
            ->using('db')
            ->columns(['id', 'title', 'description', 'created_at'])
            ->all();

        return BaseResponse::JsonResponse(0, null, $result);
    }

    /**
     * Returns a single todo
     * @throws Exception
     */
    public function details(array $data): BaseResponse
    {
        $this->requires(['id']);
        $id = $data['id'];

        $result = Porm::table('todos')
            ->using('db')
            ->columns(['id', 'title', 'description', 'created_at'])
            ->get(['id' => $id]);

        return BaseResponse::JsonResponse(0, null, $result);
    }

    /**
     * Creates a new todo
     * @throws Exception
     */
    public function create(array $data): BaseResponse
    {
        $this->requires(['title', 'description']);
        $title = $data['title'];
        $description = $data['description'];

        $result = Porm::table('todos')
            ->save(['title' => $title, 'description' => $description]);

        return BaseResponse::JsonResponse(0, 'Todo created successfully', $result);
    }

    /**
     * Updates a todo
     * @throws Exception
     */
    public function update(array $data): BaseResponse
    {
        $this->requires(['id']);

        $id = $data['id'];

        $todo = Porm::table('todos')
            ->get($id); // similar to `get(['id' => $id])`

        // if the todo is not found, we throw an exception
        if (!$todo) {
            throw new BaseDatabaseException('Todo not found');
        }

        $description = $data['description'] ?? $todo->description;
        $title = $data['title'] ?? $todo->title;

        // we update in a transaction as below
        $result= null;
        Porm::table('todos')
            ->inTransaction(function () use ($description, $title, $id, &$result) {
                Porm::table('todos')
                    ->update(['description' => $description, 'title' => $title], $id);

                $result = Porm::table('todos')
                    ->get($id);
            });

        return BaseResponse::JsonResponse(0, "Todo $id updated successfully", $result);
    }

    /**
     * Deletes a todo
     * @throws Exception
     */
    public function delete(array $data): BaseResponse
    {
        $this->requires(['id']);
        $id = $data['id'];

        $todo = Porm::table('todos')
            ->get($id);

        if (!$todo) {
            throw new BaseDatabaseException('Todo not found');
        }

        $deleted = false;
        Porm::table('todos')
            ->inTransaction(function () use ($id, &$deleted) {
                Porm::table('todos')
                    ->delete($id);
                $deleted = true;
            });
        if (!$deleted) {
            throw new BaseDatabaseException('Todo not deleted');
        }
        return BaseResponse::JsonResponse(0, "Todo $id deleted successfully");
    }

    /**
     * Returns a random todo object if the size is not defined or 1,
     * else returns an array of random todos
     * @throws Exception
     */
    public function random($data): BaseResponse
    {
        $size = $data['size'] ?? 1;

        $result = Porm::table('todos')
            ->random($size);

        return BaseResponse::JsonResponse(0, null, $result);
    }

    /**
     * Returns a paginated list of todos
     * @throws Exception
     */
    public function paginatedList(array $data): BaseResponse
    {
        $offset = $data['offset'] ?? 0;
        $limit = $data['limit'] ?? 3;

        $paginator = new PaginationCore($data, 'todos', $limit, $offset, 'db');
        $result = $paginator->paginate();

        return BaseResponse::JsonResponse(0, null, $result);
    }
}

And since our TodoService is already registered, that's all we need to do, no adding extra routes, no adding controllers, just start hitting the actions in your requests and you should get uniform responses from all the above actions.

However much this is not alot to do, and the only thing to do in Pionia(building services), all the above actions in our TodoService can be omitted and we still get the same functionality, This is where our Generic Services come in!

Todo Service, The Generic Way.

If your logic is not more than create, delete, paginate, list, update, delete, or retrieve then Generic Services might be all you need.

Pionia provides both generic services and mixins to use. Mixins can be put together to put up your entire new Generic Service.

Provided mixins include ListMixin, CreateMixin, DeleteMixin, UpdateMixin, RandomMixin and RetrieveMixin. Under the hood, even Generic services are just combining these Mixins while extending GenericService.

Provided Generic Services include RetrieveCreateUpdateService, RetrieveListCreateService, RetrieveListCreateUpdateDeleteService, RetrieveListDeleteService, RetrieveListRandomService, RetrieveListUpdateDeleteService, RetrieveListUpdateService and UniversalGenericService.

If the above Generics don't combine the mixins in the way you want, you can extend GenericService and call all the mixins you want to use thus creating your custom generic service.

Remember, to use mixins, you must be extending Pionia\Generics\Base\GenericService not the normal BaseRestService we extended before. Also, remember that mixins are just PHP traits and should be used that way.

To refactor our TodoService, we shall need the last mentioned generic service, UniversalGenericService as it uses all the defined mixins.

Let's start by changing the class we extend. Refactor this as below

use Pionia\Generics\UniversalGenericService;
// ... rest of the imports

class TodoService extends UniversalGenericService
{
// ... rest of your actions
}

Before we do anything, let's first define the table we want to target in the database. We use the $table property for this. This is a compulsory feature and must be defined for all generic views.

use Pionia\Generics\UniversalGenericService;
// ... rest of the imports

class TodoService extends UniversalGenericService
{
   public string $table = "todo";
// ... rest of your actions
}

Secondly, from our list action, we are defining columns we want to return, however, we are defining all. If you want to return a certain range of columns only, we define the $listColumns(which defaults to all) and pass the columns we want to return. Let's just still pass all though it is the default behavior of the service.

use Pionia\Generics\UniversalGenericService;
// ... rest of the imports

class TodoService extends UniversalGenericService
{
    public string $table = "todo";
    public ?array $listColumns = ['id', 'title', 'description', 'created_at'];

// ... rest of your actions
}

At this point, we can delete the list action from our service. That's complete!

Our second target action is now details. This one can be replaced by defining the $pk_field which defaults to id. Since our primary key field for our todo table is also id, we don't need to define it, we just need to delete it too! Remember, this one also uses the defined $listColumns for columns to return from the DB.
The RetrieveMixin also defines another sister action to this called retrieve, so in your request, you can use ACTION as details or retrieve, the two will perform the same thing.
Since we already have all we need, we can drop the details action too!

Our third action is create. For this, we must define the $createColumns to define those columns we shall be looking for from the request(required) to create a record. Let's add the property now.

use Pionia\Generics\UniversalGenericService;
// ... rest of the imports

class TodoService extends UniversalGenericService
{
    public string $table = "todo";
    public ?array $listColumns = ['id', 'title', 'description', 'created_at'];
    public ?array $createColumns = ['title', 'description'];

// ... rest of your actions
}

After adding, go ahead and delete it too!

Our fourth action is update. For this, we require the $pk_field and can also optionally define the $updateColumns. If undefined, the responsible mixin checks if any of the properties were defined in the request, and will update only those.
Let's add the $updateColumns and give it the only properties we intend to update.

use Pionia\Generics\UniversalGenericService;
// ... rest of the imports

class TodoService extends UniversalGenericService
{
    public string $table = "todo";
    public ?array $listColumns = ['id', 'title', 'description', 'created_at'];
    public ?array $createColumns = ['title', 'description'];
    public ?array $updateColumns = ['title', 'description'];

// ... rest of your actions
}

We can now drop the update action too!

For our fifth action, delete, we only need the $pk_field which is by default id, so we shall be checking if id was passed in the request, and then we delete the associated record. So, just delete it, we already have all we need!

Now to our sixth action, random, this also uses the $listColumns to determine the columns to fetch from the DB per record. We already have out property defined, so, just drop it too!

For our seventh action, paginatedList, we can drop it, and in any request, we target our list action, but we define any of the following pairs of keys in our request.

limit and offset on the request object level.

{
   "SERVICE": "todo",
   "ACTION": "list",
   "limit": 3,
   "offset": 0
}

PAGINATION or pagination object on the request with limit and offset keys.

{
   "SERVICE": "todo",
   "ACTION": "list",
   "PAGINATION": {
      "limit": 3,
      "offset": 0,
   }
}

SEARCH or search object on the request object with limit and offset keys.

{
   "SERVICE": "todo",
   "ACTION": "list",
   "SEARCH": {
      "limit": 3,
      "offset": 0
   }
}

Note: Both the limit and offset keys must be defined for pagination to kick in.

And just like that, our service now has been reduced to the following.

use Pionia\Generics\UniversalGenericService;

class TodoService extends UniversalGenericService
{
    public string $table = "todo";
    public ?array $listColumns = ['id', 'title', 'description', 'created_at'];
    public ?array $createColumns = ['title', 'description'];
    public ?array $updateColumns = ['title', 'description'];
}

Let's do a little more cleanup. As we had mentioned earlier, if we are listing all columns from our table, then we don't need to define the $listColumns property, let's remove that too.

use Pionia\Generics\UniversalGenericService;

class TodoService extends UniversalGenericService
{
    public string $table = "todo";
    public ?array $createColumns = ['title', 'description'];
    public ?array $updateColumns = ['title', 'description'];
}

Also, since our update can also discover the columns to update from the request data, let's remove the $updateColumns too!

And we are left with the following as our new TodoService but still exposing the actions of list(all and paginated), create, update, delete, retrieve or details and random

use Pionia\Generics\UniversalGenericService;

class TodoService extends UniversalGenericService
{
    public string $table = "todo";
    public ?array $createColumns = ['title', 'description'];
}

You can also override how we get a single record and multiple records. You might not need it, but sometimes you may need to add where clauses and other conditions as you see fit. For that, you can read about it in this section in the docs.

Also, you may want to add your other actions in the same generic service, this is fully supported and will work as if you're in normal services, however, make sure none of those actions share the names with the provided mixin actions or otherwise you stand a chance of overriding the provided actions.

This also drives to the last point, what if you intend to override the default action? that's also okay! You can also look into it under this section of the docs.

Welcome to Pionia Framework, where we believe in both developer and program performance, writing precise and maintainable codebase with simplicity both at the front end and the back end!

Let me hear what you say about the Pionia Framework specifically about generic services. Happy coding!

Moonlight Architecture - The Old-New

Tumusiime Ezra Jnr — Sun, 30 Jun 2024 13:54:52 +0000

Moonlight Architecture is an architecture that has existed for a while but remained nameless. Therefore, it is not right to say it is a new architecture yet most developers and companies have been using it. It borrows its features from commonly used architectures of MVC, gRPC, Graphql and Micro Services. Most of the features may highly sound, look more like MVC combined with Graphql.

Features of Moonlight.

REST only. Moonlight is meant for only REST applications. It does not support any form of templating. This is a design philosophy, whereby, it lets frontend frameworks handle frontend work while serving them APIs in the most elegant manner.
Also Moonlight architecture is framework and language agnostic, implying that you can use it with your favourite framework in your favourite language. If you're coming from a PHP background, a framework - Pionia, has already been put up to get you started, however, you can configure your favourite frameworks to work with this architecture. This has already been done with frameworks such as Spring Boot in Java(an excellent and pioneer framework for the architecture), Django Rest Framework in Python(worked excellently too) and Laravel in PHP(though some few features were not pulled off right).
Moonlight encourages a single API endpoint for your entire API version, which means, all version APIs can be served at /api/v1/, then version two on /api/v2/. This is the only route you should have for your entire API. No query parameters, no relative paths but only one endpoint.
Moonlight, encourages(enforces) all requests to the backend to be performed over POST. This has security benefits since the body of POST requests is usually logged while encrypted on a web server, thus keeping your requests secure to your application server.
Single request format. The architecture encourages using either JSON or FormData if supported in your language or framework. Each request must define SERVICE and ACTION targeted. And the rest of the data as key-value pairs.

// POST https://exampleapi.com/api/v1/
{
  SERVICE: 'auth',
  ACTION: 'login',
  password: '1234567',
  username: 'moonlight'
}

Single Response Format. The response must define the return code, return message, return data, and any extra data the server wants to communicate to the front end. In this case, the return code must be defined and by conventional, 0 is reserved for success, any other codes indicate failure but this can be customised to your business needs.

// POST https://exampleapi.com/api/v1/
{
  returnCode: 0, // 0 for success, any other for error or warning
  returnObject: "token_here",// response data fro the server, can take any type according to the request
  returnMessage: 'Welcome back John Doe', // message you want the frontend to show
  extraData: null // any other data you want to pass.
}

All requests that reach your application server must return a 200 OK status code whether they are resolved with an error or not. In cases of errors, a return code that is not 0 can be returned, with a clean, descriptive error message as the return message.
Moonlight introduces the concept of switches, these represent a certain version of your API and register all services that are available in that version. Their main job is to read the incoming request, determine which service was defined and call it passing their entire request data. The switch also catches all uncaught exceptions in the request and returns a cleaner response similar to what we determined above.
Services in Moonlight are central holders of your business logic, this is where you write all your actions specific to that service. An example of a service(class) can be AuthService that defines actions(methods) such as login, resetPassword, and register. All these must return the same response format. Actions are responsible for querying the database, validating the requested data and requesting any external third party that you might be integrating with.

Known Issues With Architecture.

Strict(typed) languages such as Java, C# and Golang, may dictate you to stick to only JSON data. However, in non-strict languages like JS, Python, and PHP(which are commonly used for the web), you can mix both form data and JSON. This only affects uploading multipart files.

This is currently the only known issue so far affecting the architecture.

If you are interested in this architecture, you can read more about it here. Also, you can try out Pionia for your next API application. Pionia provides full implementation of the architecture. You will be surprised how much you need to pull off an API!

Goodluck and happy coding!

Yii2, PHP the easy way

Tumusiime Ezra Jnr — Wed, 23 Mar 2022 13:39:26 +0000

Welcome back to my other writing about tech, today we discuss about Yii2, yes, Yii2 also known as Yes it is, for security, fast and effecient.

Whereas most of us confuse the two, but Yii2 is not an extension of yii1, it is a complete re-write of first version which implies yii2 was a complete re-write ground-up, not extension of yii1.

Background
Compared to the most of the powerful frameworks, yii is slightly younger, that is, it first got its official release in December 3rd, 2008 but this was version 1 and it was not super-production-ready and battle-tested to start the competition with the then existing Django, Spring etc. Therefore a new, Version 1.1.2, which was more battle-tested had to be released and that was on March 14th, 2010. And that's how we see the coming up of yii1. But the journey did not stop, this version still had some loops here and there and the developers felt there was more need for further improvement however, they could not tamper with the already existing mature-seeming version 1.1.2, and there was also a tremendous job that was taking place to PHP itself which made PHP run faster and better. Therefore in 2013, May, the first unstable version of yii2 was released which was later followed by the release of the stable version in 2018 October that supported new versions of PHP. Yii2 currently fully supports PHP 8+.
Version 3 of the framework is in progress and can be found here

Getting started with Yii2.

Yii2 gives you two templates of projects you can start from and these are as follows.

The basic template (which is most likely what you want)
The advanced template.

Requirements.

PHP installed and running. especially PHP7.2+
You will need composer installed. You can quickly install composer from composer official download page.
Apache2 or nginx installed and running.
Database of your choice running e.g. PostgreSQL or MySQL. You can find the list of all databases supported by Yii here

This short tutorial will illustrate the setup of yii2 basic project, you may find the setup of the advanced project here

Installation.
You can quickly set up a yii2 basic project by running the following command.

composer create-project --prefer-dist yiisoft/yii2-app-basic basic

composer is the package manager for PHP applications and can be used to perform various action as seen by running composer in your terminal.
create-project is the yii2 command that tells yii that you are actually creating a new application.
--prefer-dist yiisoft/yii2-app-basic this tells yii2 the template type you would like to start with. In our case we chose the basic template.
basic is the application name, this can be any name, like polls, facebook, blog.

Now since you have application, let's navigate to it using and open it with vs code.

cd appname && code .

Replace appname with your application name you just created.

Project structure

The boilerplate seems alot but let's break it down in a minute.

Yii2 is in the nature of MVC that is Model View Controller and here, they do exactly how they sound. That is, models are placed in models, Views that is where you place what users see and finally controllers carry the mapping and logic of your entire application.

And we have completed the whole boilerplate! WAIT, HAVE WE?

So what are the rest?

assets help you to configure your JS, CSS and other dependencies of your entire application also known as Application Assets and these are done in AppAsset.php.
commands these help you to register your new commands with the application. These can later be later accessed and ran via your console.
config as the name suggests, this is where the entire application configurations sit. From databases, to configuring modules and many more.
controllers, as mentioned above, this is where routing and app logic resides. Logic that ranges from authentication, opening pages, redirecting and many more.
mail, this is functional for sending emails.
models, the database tables' representation in your code. These help you to interuct with database tables as PHP classes.
... More of these files you may never require them at all.
vendor stores your dependencies you have installed, look at this as your node_modules folder, or your virtualenv in python.
views contains the pages(HTML) that users finally interuct with.
web This is the entry folder. Your application will first get into this folder to access your index.php, which will redirect it accordingly thus running the entire application.

To run our application just get the root directory, make sure you are on the level of yii file. And run the following.

php yii serve

Navigate to http://localhost:8080/

If everything was successful, you should be seeing the page below.

And that is it!! You have your first PHP Yii2 framework app up and running.

Advantages of YII2

Authentication and authorization out of the box. This comes with pre-configured helpers and classes to handle sessions, roles and permissions and many more.
Inbuilt ORM(Object Relational Mapper) that supports over 6 databases and supports working with already existing databases with ease!
Code generation. In Yii2, you may find it crazy but in most cases you will will find code generation being automated by the gii module. You can find this at localhost:8080/gii. This enables generate modules, models, views, CRUD and many more.
Bootstrap 4 out of the box. With Yii2 you don't need to configure bootstrap and jQuery as these two come preconfigured for you to start using without any additional work.

Let me hear from you about the performance of yii2 and if you are a fun too! otherwise, goodluck with your yii journey.

Go the way to Go

Tumusiime Ezra Jnr — Wed, 16 Mar 2022 20:04:05 +0000

Well, well well, today we need to take a small teleportation to the future of software development. But before let's first look at the background.

In 1972, a very wise guy called Dennis Ritchie develops the first version of C at Bell Labs.
In 1979, another smart brain Bjarne Stroustrup enhances C to add more object oriented fetures such as classes also at Bell labs. C++ was made open for everyone to use in 1985.
In 1991, we see the birth of the worlds most powerful language(as of the present), python, by Guido Van Rossum.
In 1994, a language which was ignited to truck who viewed Rasmus Lerdolf's resume, called Personal Home Page(PHP), that was later released for use by others in 1995, which we may call its birth year.
In the same year, 1995, we see another smart brain named James Gosling developed Java at Sun Microsystems though rumors say that it was ignited in 1991 but let the world to know about it in 1995.
Also in the same year, 1995, we also see the birth of the world's second best programming language, JavaScript, developed by Brendan Eich, currently may be the most popular programming language!.

... the list is endless.

But here is the catch
The first multi-core processor was developed by IBM, in 2001, more details can be read here and at this time the only latest programming language was C# which was created in 2000, one year before the birth of multi-core processor architecture.

Therefore, with the new architecture in place, languages started putting measures to use this great feature, but that was not their nature. We see JavaScript introducing promises for asynchronous performance, python, C, Java, C++, C# do the same so as to support the multiple events since the number of threads to work on tasks were increasing. But these were all added features and of these programming languages had this by default.

To our rescue!
Robert Griesemer, Rob Pike, and Ken Thompson in 2012(when it was made public), 10 years back from the time of writing this article, (but developed in 2007), developed a language that combines all the good parts of the dear oldies, Java, Python, JS, C++, C#, C and ignores the worst parts they have, at Google. The language gets its name from (you guessed it right), Google as that's where it was developed from. Various features that you need to install as libraries, packages ..., will be implemented by default in Go.

Well, right now, the transition is not instant, but the future will dictate us to fully move to Go as most of the biggest companies have already changed their performance sensitive programs to Go.

Why Go?

Go is popular for cloud-based or server-side applications.
DevOps and site reliability automation are also popular ways to use Go.
Many command-line tools are written in Go.
Go is used in the world of artificial intelligence and data science.
Some use Go from micro-controller programming, robotics, and games.

However, Go really shines the most when it comes to infrastructure. Some of the most popular infrastructure tools today are written in Go — such as Kubernetes, Docker, and Prometheus.
Generally, wherever you need a lot of performance and concurrency, Go has got you covered.

Speed comparison between Go and Java.

Go results:

Factorial   Time To calculate factorial
10000       0.03 seconds
50000       0.41 seconds
100000      2.252 seconds
500000      68.961 seconds
1000000     224.135 seconds

Java results:

Factorial   Time To calculate factorial
10000       0.112 seconds
50000       1.185 seconds
100000      2.252 seconds
500000      89.500 seconds
1000000     385.868 seconds

That's a small sample test, but you can explore more with other languages and see how Golang beats the rest in performance.

Note: It is only in Golang where you do not even think about async and sync as Go by default is the only asynchronous programming language ever made.

Whereas python, C#, Java, C ..., are still proving to be our present, after teleporting to the future, I found Go being widely used more than anything else!! So start learning it today from here

Django vs Flask, what to choose!

Tumusiime Ezra Jnr — Tue, 08 Feb 2022 09:12:13 +0000

Introduction
- Flask
  - Background
  - Who uses flask
- Django
  - Background
  - Who uses Django
Similarities
Differences
Conclusion

Introduction

Hello, hope you are doing well, well, this is 2022 knocking at the door and we need to start doing things its new way it is coming along with.
Whereas there are more than 50 frameworks of Python, there are only two of these that have continuously become the kings of the web, flask and Django at least as far as 2021.
These two frameworks seem to be the most mature and most loved on the web by many beginners, advanced developers and companies. They give us a chance to use the world's best language for full stack development. Let's break them and we get to know which to learn and use when! Can we roll!!

Flask

Background

Flask was created by Armin Ronacher of Pocoo, an international group of Python enthusiasts formed in 2004. According to Ronacher, the idea was originally an April Fool's joke that was popular enough to make into a serious application. The name is a play on the earlier Bottle framework.
When Ronacher and Georg Brandl created a bulletin board system written in Python, the Pocoo projects Werkzeug and Jinja were developed.

Flask's philosophy according to this article is to let the developer take on the driver's seat and have total/full control over the application they are developing.
This has made the framework become the no.1 choice to most of the developers that love doing things their own way.

Flask code sample:

from flask import Flask

app = Flask(__name__)


@app.route('/')
def hello():
    return 'Hello, World!'

With the above code, you have a full application that outputs Hello, World in the browser running on http://localhost:5000, amazing, right!

Who uses flask

Well, flask being a python light weight framework, most of the companies have picked it to play a big role in building micro-services. As we have seen in the above code snippet, with just one file, you have a fully working app. Therefore, over 900 companies may not entirely be depending on flask as the primary backend framework but include it in their stack.
This list only shows the top 10.

Netflix
Reddit
Lyft
CRED
Trivago
Zalando
MIT
Patreon
ML
Sendcloud

As per this writing, Flask had 2.2k watches, 57.1k stars and 14.7k forks on github, these may have changed by the time you are reading this but you can click here for the current standings

Django

Django (/ˈdʒæŋɡoʊ/ JANG-goh; sometimes stylized as django) is a Python-based free and open-source web framework that follows the model–template–views (MTV) architectural pattern. It is maintained by the Django Software Foundation (DSF), an independent organization established in the US as a 501(c)(3) non-profit.

Background

Django was created in the fall of 2003, when the web programmers at the Lawrence Journal-World newspaper, Adrian Holovaty and Simon Willison, began using Python to build applications. Jacob Kaplan-Moss was hired early in Django's development shortly before Simon Willison's internship ended. It was released publicly under a BSD license in July 2005. This framework has been around for over 16 years atleast as per this writing! The framework was named after guitarist Django Reinhardt.

Who uses django

Well various applications/companies or even tools may not be using Django as the framework but it's counterpart framework Django Rest framework which is a derivative of the same.

The list shows the companies currently using Django in their progressive work. The list only shows the top 10 but there are more.

Disqus
Instagram
Bitbucket
MacArthur Foundation
Mozilla
National Geographic
Open Knowledge Foundation
Pinterest
Open Stack
Spotify

As per this writing, Django had 2.3k watches, 62.1k stars and 26.5k forks on github, these may have changed by the time you are reading this but you can check the Django repo for the current stand

Similiraties

Well, no matter how they seem to be, the two frameworks share somethings in common which you can not under look. And the matter of the fact, if you are ready comfortable with one, you will find it extremely easy to move one to the next. Like the process is seamless.

Here are the similarities you will find in both.

Python frameworks. Well, without knowledge of python, then you won't be able to write the two frameworks. The are highly Object oriented, and therefore all functions, classes and data structures from python itself, can be used in both.
Fullstack frameworks. Both are independent fullstack frameworks, that is, you will not need any other framework alongside them to develop the backend, frontend etc. They come with inbuilt template engines to handle the front-end and use python to handle the backend.
ORM for models. The frameworks use Object Relational Mappers to provide quick interactions with the database. Whereas Flask does not ship in with this functionality, a special tool to achieve the same has been developed called Flask-SQLAlchamey .On the other hand, the ORM functionality is in-built with django and it's one of those features Django beats most of the other frameworks on.
Request-Response behaviour. With both frameworks you will not miss finding features such as views which will receive requests, perform some logic and map them to the right response. This response maybe returning a new page, some json, or file.
Routes/urls. Whereas the design differs, the functionality does not. These are mappers, which tell the frameworks which view to return on which request. 6.** Sessions and authentication**. Whereas, you may not start the sessions automatically with flask, helper functions for starting, updating, deleting sessions, and performing authentication are provided for by the frameworks. Some of these features can be achieved with some extra libraries in flask, but relying on external libraries in django is upon you. Whichever choice you opt for, you will find it easy in both to handle the functionalities.
In-built template engines. Whereas they may not entirely be the same, the frameworks come with the inbuilt way of building templates(what users see). With these, python functionalities such loops, conditionals, string laterals and many more are presented. Flask uses Jinja2, but with django, you can choose to use Jinja2 but this is not their default. Django has defined its own template engine called django templates, which works closely similar to Jinja2 with little upgrades.

These are not the only similarities, the endless will surely be bigger, but you scan from the above for more...
Next, let's move on how the two differ.

Differences

There will be a few distinctions between the two frameworks, and that's the reason why I had put it that switching from one to another shall really be seamless. Let's see how they differ.

Architecture. Django is MVT(That is, Model-View-Template). Now do not take "View" for how other frameworks of MVC(Model-View-Controller) take it, Model-will still be Model, View will be equivalent to Controller and Template will equivalent to View in MVC. Somehow confusing right!, please read the docs to understand how django handles this feature. Django stores and names these files accordingly and most of them are provided by default. On the other hand, Flask is a modular framework, which means, one file can even contain the whole app. Whereas, the architecture is internally maintained as for django, the structure is entirely upon you.
Flexibility. Django is meant for developers who want to get tasks complete in time. That's why you will find most of the features provided for by default. This may look a good thing and will actually do the right work for you, but this means you will have less freedom of updating the defaults which will require extra knowledge of the framework to update these features. On the other hand, Flask is entirely flexible, ground up. In brief, there is no convention of designing a Flask application. This also looks good for the start, but when the project starts getting complex, new members, and/or even old team may find it hard to update the code.
Scalability. Flask is highly meant to develop modular applications also known as micro services in the same project. This implies that different developers can work on different small modules independent of each other but communicating together. However, django is somehow different. Django itself is considered a project, and then inside it, you set up as many applications as you feel like. This let's django handle even the most complex project with ease. Also the development convention of django while creating these apps makes it very simple for one to divide out members to work on different modules within the same project without necessarily handling them in a distributed format. Also, plugging in a new app is very seamless also and does not affect the other applications ran in the same project.
Security. Whereas in django, starting from the user, and all the forms of authentications such as creating accounts, logging in, resetting and changing passwords, confirming passwords and many more are inbuilt, flask loses out on some of these features and you will end up building them from scratch or depending on third-party libraries. Features like cryptography, click-jacking, CSRF and worked upon by django by default.
Learning curve. If you already know python, Flask should take at most a week to write your first application. This differs with django, most developers have confessed that understanding the file structure of the framework has become an issue, however, understanding this flow will make django equally easier. Therefore, django will require you to at least two weeks to feel comfortable working on a good project.
ORM. Whereas flask depends and works well with Flask-SQLAlchamy, Django's ORM is a killer. From the process of creating models, tracking and squashing, working with more than one database, and changing from one database to the other. All these make Django ORM a killer feature especially when it comes to handling complex databases with very many tables.

Conclusion

With that said and more as you will read from other developers, the question still stands, what do you choose?
Well, I am someone who writes both frameworks and my conclusion is thought about.

When you are handling something that is not complex at all, please choose Flask.

If you are working on a project with some other framework such as Express or Laravel, but wanted some independent feature to be done with python, please choose flask.

Otherwise, choose django.

DEV Community: Tumusiime Ezra Jnr

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

Another framework, Arrrgggg!!!

Getting started with Pionia Framework

What we shall be working on today.

The Ultimate Guide to Pionia Generic Services.

Background on services.

Todo Service, The Generic Way.

Moonlight Architecture - The Old-New

Features of Moonlight.

Known Issues With Architecture.

Yii2, PHP the easy way

Go the way to Go

Django vs Flask, what to choose!

Table of contents

Introduction

Flask

Background

Who uses flask

Django

Background

Who uses django

Similiraties

Differences

Conclusion