Forem: Ricardo Čerljenko

Use Laravel with OpenAI to validate inappropriate content

Ricardo Čerljenko — Fri, 10 Feb 2023 20:40:29 +0000

Recently I stumbled across OpenAI Moderations API which gives you a way to query OpenAI in order to detect if input text contains inappropriate content such as hate, violence, etc.

API is completly free - you just need to create an OpenAI account and issue a fresh API token.

Since I'm primary a Laravel PHP Framework developer, I decided to make a package which will provide a way to validate request payload fields against OpenAI Moderations API.

Installation

Standard Composer package installation:

composer require rcerljenko/laravel-openai-moderation

Usage

Publish config and translation files.

php artisan vendor:publish --provider="RCerljenko\LaravelOpenAIModeration\LaravelOpenAIModerationServiceProvider"

Set your OpenAI API key and enable package via newly created config file => config/openai.php
Use provided rule with your validation rules.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use RCerljenko\LaravelOpenAIModeration\Rules\OpenAIModeration;

class StoreText extends FormRequest
{
 /**
  * Determine if the user is authorized to make this request.
  */
 public function authorize(): bool
 {
  return true;
 }

 /**
  * Get the validation rules that apply to the request.
  */
 public function rules(): array
 {
  return [
   'text' => ['required', 'string', new OpenAIModeration],
  ];
 }
}

And that's it! Your content can now be validated with powerfull (and yet free) OpenAI Moderations API.

Thank you for reading this! If you've found this interesting, consider leaving a ❤️, 🦄 , and of course, share and comment on your thoughts!

Lloyds is available for partnerships and open for new projects. If you want to know more about us, check us out.

Also, don’t forget to follow us on Instagram and Facebook!

Laravel - Serve API requests with translated validation rules

Ricardo Čerljenko — Wed, 19 Oct 2022 18:49:32 +0000

Consider building a mobile app (or a website) which connects to a Laravel CMS over API for dynamic content. Now, the app can be a multi-language app which expects to receive a translated content from the CMS.
Usually, in our company, we instruct our frontend developers to send a lang query param on every request in order to deliver the correct translated content back.

E.g.:

GET /api/blogs?lang=en

However, Laravel validation is not aware of this and it always returns validation error messages according to app locale (or fallback locale).

Therefore we created a route middleware which groups all API routes and sets app locale based on the lang query param:

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class ChangeLocale
{
    /**
     * Handle an incoming request.
     */
    public function handle(Request $request, Closure $next): Response
    {
        $locale = $request->query('lang');

        if ($locale) {
            app()->setLocale($locale);
        }

        return $next($request);
    }
}

And in routes file:

// routes/api.php

use App\Http\Middleware\ChangeLocale;
use Illuminate\Support\Facades\Route;

Route::middleware(ChangeLocale::class)->group(function (): void {
    // ROUTES
});

Now your validation messages will be in the requested locale. If you don't like handling this over query param you can always use a header or something else, e.g.:

$locale = $request->header('Accept-Language');

Thank you for reading this! If you've found this interesting, consider leaving a ❤️, 🦄 , and of course, share and comment on your thoughts!

Lloyds is available for partnerships and open for new projects. If you want to know more about us, check us out.

Also, don’t forget to follow us on Instagram and Facebook!

Creating a Neat DateTime Helper Function in PHP

Ricardo Čerljenko — Thu, 24 Mar 2022 12:35:05 +0000

Let me start with a statement: I'm not a big fan of global helper functions being included in the project, but sometimes it's a good thing to have that little helper functions here and there.

Working with datetime in PHP could be a real pain if you don't take advantage of popular libraries like Carbon. It's all good until you have to convert dates provided on user input into another timezone (eg. UTC) and vice versa. Other example could be that you have to manage various input datetime formats, and sanitize them into a consistent one before saving it to database.

I will show you how I handled that by creating a datetime helper function which will take any datetime format and convert it into a consistent one with the power of Carbon library.

use Carbon\Carbon;

function formatDateTime(
    DateTimeInterface|string|float|int $inputDateTime = null,
    string $outputFormat = 'Y-m-d H:i:s',
    DateTimeZone|string $outputTimezone = 'UTC',
    DateTimeZone|string $inputTimezone = 'UTC'
): string
{
    $carbon = is_numeric($inputDateTime)
        ? Carbon::createFromTimestamp($inputDateTime, $inputTimezone)
        : new Carbon($inputDateTime, $inputTimezone);

    return $carbon->setTimezone($outputTimezone)->format($outputFormat);
}

Let's go over this bit by bit. The function takes 4 arguments and none of them are required which means that if called without any argument, the function should return a current UTC datetime string in a common database format.

$date = formatDateTime();
// 2022-02-03 08:10:21

First argument $inputDateTime is the most important one and by its signature you can easily figure out that it can accept various datetime formats including a string, float, integer and a DateTimeInterface capable object. That last one is important because it enables us to work with any PHP datetime object as well as any potential library that implements that interface (such as Carbon).

// string
$date = formatDateTime('2022-02-03 08:10:21');

// string
$date = formatDateTime('2022-12-31');

// int (UNIX timestamp)
$date = formatDateTime(time());

// float (UNIX timestamp in microseconds)
$date = formatDateTime(microtime(true));

// DateTime object
$date = formatDateTime(new DateTime);

// Carbon object
$date = formatDateTime(new Carbon);

// Laravel Carbon datetime casting
$date = formatDateTime($post->created_at);

Other arguments are pretty self-explanatory.

$outputFormat controls in which format will function return the datetime string, e.g.:

$date = formatDateTime(new DateTime, 'd/m/Y');
// 03/02/2022

$outputTimezone controls the result timezone and $inputTimezone tells the function in which timezone is the $inputDateTime.

If you're running under PHP8+ then it's even easier to handle arguments with the "named arguments" feature like so:

$date = formatDateTime(
    inputTimezone: 'Europe/Zagreb'
);

Thank you for reading this! If you've found this interesting, consider leaving a ❤️, 🦄 , and of course, share and comment on your thoughts!

Lloyds is available for partnerships and open for new projects. If you want to know more about us, check us out.

Also, don’t forget to follow us on Instagram and Facebook!

How to handle both API and Basic authentication in Laravel

Ricardo Čerljenko — Thu, 03 Mar 2022 09:55:42 +0000

While building your app in Laravel PHP Framework, you have multiple ways of protecting your API routes with various auth guards or Basic auth. Would it be nice to support both API guard and Basic auth at the same time?

In default Laravel app you can protect your API routes like this:

// routes/api.php

use Illuminate\Support\Facades\Route;

Route::middleware('auth:api')->group(function (): void {
    // PROTECTED ROUTES
});

Or using Basic auth:

// routes/api.php

use Illuminate\Support\Facades\Route;

Route::middleware('auth.basic')->group(function (): void {
    // PROTECTED ROUTES
});

But it's not possible to guard your routes with both of them. E.g., if there's no provided Bearer token use the Basic auth. To accomplish this we need to make some adjustments to the default Authenticate middleware which is provided in the app/Http/Middleware directory. Here's how I achieved that:

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Auth\AuthenticationException;
use Symfony\Component\HttpFoundation\Response;
use Illuminate\Auth\Middleware\Authenticate as Middleware;

class Authenticate extends Middleware
{
    /**
     * Handle an incoming request.
     */
    public function handle($request, Closure $next, ...$guards): Response
    {
        try {
            $this->authenticate($request, $guards);
        } catch (AuthenticationException $e) {
            if (!$request->wantsJson()) {
                throw $e;
            }

            if ($response = $this->auth->onceBasic()) {
                return $response;
            }
        }

        return $next($request);
    }
}

First, we catch the AuthenticationException which is thrown by the parent authenticate() method. That means that every provided guard (or a default one) didn't produce a valid user.

Now we can try to do a Basic auth but only if the client expects a JSON response (we don't want to try Basic auth in a normal web context because it would pop-up the Basic auth prompt box on every browser request).

Take note that onceBasic() method returns null if the provided Basic auth credentials are valid. If not, it returns an already formed Error Response bag which you can safely return from the middleware.

Now we're able to authenticate our users on API routes with both API guard and fallback Basic auth by simply using a default auth middleware.

Thank you for reading this! If you've found this interesting, consider leaving a ❤️, 🦄 , and of course, share and comment on your thoughts!

Lloyds is available for partnerships and open for new projects. If you want to know more about us, check us out.

Also, don’t forget to follow us on Instagram and Facebook!

PHP Laravel Local Dev Setup

Ricardo Čerljenko — Mon, 05 Oct 2020 08:53:19 +0000

Coming from a company that has multiple backend developers and even more ongoing projects, it's a normal situation that developers are shared between multiple projects. From the developers point of view that's not the ideal scenario because there will always be a "context switch" time penalty where you have to disengage yourself from you current state of mind and integrate your focus to a completely new project. That includes reading the user stories and tasks that are left to be done on this new project as well as understanding the code itself that the previous developer left on.

While we can't do much about the first part where your teammates must somehow onboard you to the new project, there are some things that we can do with our codebase so that any developer in the company can understand it with ease. Over the past few years we figured out that some developers find it very hard to continue on someone else's code if they vary a lot in coding style - it somehow feels unnatural and wrong don't you agree? There's also a problem of structuring your codebase, especially when you're working with frameworks such as Laravel where you have a multiple ways to achieve the same thing.

Here are some pieces of advice on how we can minimize the differences between coding styles and project structures that we implemented over the past few years.

1. Master project template

In our company we have around 15 developers in three developer divisions: Backend Development (Laravel PHP Framework), Frontend Web Development (Nuxt.js Framework) and Mobile App Development (React Native). Imagine that every developer starts it's project completely on its own without any guidelines and completely from scratch every time. It would be a mess out there. No one could jump in in the middle of the project and continue to work without that person sitting by its side.

Instead, let's create a "Master template" (some companies call that "skeleton project" or "base template") which will be a starting point for all future projects of that division. So in our case, we have a Laravel, Nuxt.js, and React Native master templates and all projects originate from them. Master templates have to be maintained (usually by a team lead) and updated from time to time especially when a new framework version gets out. Templates contain everything that you need to start a fresh new project (eg. UI kit, auth, base controllers and logic, database setup, settings, user management, ...).

Once every developer gets familiarized with the template it's a lot easier to switch to a new project because you know where you can find your Models, Controllers, Custom logic, etc.

2. Enforce coding style

Every developer has its coding style which can be a problem in a shared project sense. Some tools that can help you set up a set of rules that developers have to obey in their coding. You have to think in a way to achieve a silver lining so that most of the team is satisfied with that.

PHP

One of the most popular tools in PHP is PHP Coding Standards Fixer. You can read all about it in the documentation but at this point the developer would have to manually fix its code once in a while. Down the road we'll learn how we can achieve that automatically.

JavaScript

For JS we chose Prettier, one of the most popular libraries for JS code formatting. Again at this point developer should also do this manually once in a while.

Both tools have their own set of rules which I strongly encourage you to take a look at (especially PHP CS Fixer) and tweak it to your needs.

3. Static analysis of the code

This step is the important one. We can leverage from the tool called Larastan which is basically a wrapper for PHPStan with Laravel specific config. The tool will perform a static analysis of our code and find out if we have some errors that we simply didn't catch but they will pop up in the runtime for sure and crash our app.
Like in the steps above, the developer has to do that manually in order to scan the code.

4. Combine and automate

Wouldn't be nice if we could completely automate steps 2. and 3. before every git commit? Yes we can and that's exactly what we're going to do. Before every commit, we're going to scan our entire code, fix the coding style according to our rule set in both PHP and JS, and run the static analysis of the code to catch any hidden errors. On top of that if any of that step catches something, we're not going to let the commit to happen. Instead, we'll force the user to fix the errors and repeat the commit again.

First, we need to set up our "pre-commit" hook that will react every time user wants to commit something. The easiest way for that is to use the package called brainmaestro/composer-git-hooks. The package has installation instructions that allows you to add a custom git hooks on some events like "pre-commit".
After including the package in your composer.json file you should update your scripts section and add something like this:

"post-install-cmd": "cghooks add --ignore-lock",
"post-update-cmd": "cghooks update"

It means that the hooks will be updated after each composer install and composer update events. While we're here, for the ease of this example, we could also add our custom scripts for steps 2. and 3. like so:

"check-format": "php-cs-fixer fix --dry-run",
"format": "php-cs-fixer fix",
"analyse": "phpstan analyse"

And in package.json for the JS fixer:

"check-format": "prettier --check resources/assets/js/**/*.js",
"format": "prettier --write resources/assets/js/**/*.js"

With that few scripts we can do this now:

# scans the PHP code and reports for invalid coding style
composer check-format

# fixes the invalid PHP coding style
composer format

# scans the JS code and reports for invalid coding style
npm run check-format

# fixes the invalid JS coding style
npm run format

# runs static code analysis
composer analyse

And now we need to instruct our script what to do when a pre-commit event happens. Let's create a custom script that will automate all of the steps above. First, add the target script in the extra section of the composer.json just like in the documentation of the Composer Git Hooks package:

"extra": {
    "laravel": {
        "dont-discover": []
    },
    "hooks": {
        "pre-commit": "./pre-commit.sh"
    }
},

And now create and populate the contents of the pre-commit.sh script:

#!/bin/bash

npm run check-format
PRETTIER_EXIT_CODE=$?

if [ $PRETTIER_EXIT_CODE -ne 0 ]
then
    npm run format
fi


composer check-format
CS_FIXER_EXIT_CODE=$?

if [ $CS_FIXER_EXIT_CODE -ne 0 ]
then
    composer format
fi


composer analyse
PHP_STAN_EXIT_CODE=$?


if [ $PRETTIER_EXIT_CODE -ne 0 ] || [ $CS_FIXER_EXIT_CODE -ne 0 ] || [ $PHP_STAN_EXIT_CODE -ne 0 ]
then
    exit -1
fi

In English the script does this:

Check JS coding style
If there's something to fix, fix it
Check PHP coding style
If there's something to fix, fix it
Perform the static analysis on the code
Exit with -1 if any of the steps above reported an error

When pre-commit hook exits with an exit code different than 0 it cancels the commit and user has to do it again (or fix the code first).

Conclusion

Hope you had some insight into how we manage to keep our coding style and project base the same across multiple projects and developers. This can be further upgraded to third party systems like Git Actions or StyleCI and also you can completely customize it to your needs with custom rules and regulations.

Thank you for reading this! If you've found this interesting, consider leaving a ❤️, 🦄, and of course, share and comment your thoughts!

Lloyds is available for partnerships and open for new projects. If you want to know more about us, click here.

Also, don’t forget to follow us on Instagram and Facebook!