DEV Community: Daniyal Javani

How to Implement a Simple Queue in Symfony

Daniyal Javani — Sun, 03 Dec 2023 15:38:37 +0000

Symfony is a popular PHP framework that provides many features and components to create web applications. One of these components is the Messenger component, which allows you to send and receive messages between different parts of your application or between different applications. In this article, we will see how to use the Messenger component to implement a simple queue system using Redis as the transport layer.

Installing the Required Packages

The first step is to install the Messenger component and the Redis adapter for it. You can do this by running the following commands in your project directory:

composer require symfony/messenger
composer require symfony/redis-messenger

This will add the necessary dependencies to your composer.json file and install them.

Configuring the Transport

The next step is to configure the transport that will be used to send and receive messages. In this case, we will use Redis, which is a fast and reliable in-memory data store that can act as a message broker. To use Redis, you need to have a Redis server running and accessible from your application. You can use the official Redis Docker image for this purpose.

To configure the Redis transport, you need to edit the .env file in your project root and uncomment the line that defines the MESSENGER_TRANSPORT_DSN environment variable. This variable holds the connection string to the Redis server and the name of the queue that will be used. For example, if your Redis server is running on localhost on port 6379 and you want to use a queue named messages, you can set the variable as follows:

MESSENGER_TRANSPORT_DSN=redis://localhost:6379/messages

You can also use a different queue name or a different Redis server if you want.

Creating the Message and the Handler

The next step is to create the message and the handler classes that will be used by the Messenger component. A message is a simple PHP object that represents the data that will be sent or received by the transport. A handler is a PHP class that implements the logic that will be executed when a message is received. You can create these classes using the make:message command provided by the Symfony console:

php bin/console make:message

This command will ask you to enter the name of the message class and the name of the handler class. For this example, we will use SmsNotification as the message class and SmsNotificationHandler as the handler class. The command will generate two files in the src/Message and src/MessageHandler directories respectively. You can edit these files to add the properties and methods that you need for your message and handler.

For example, the SmsNotification class could have a property that holds the phone number and a property that holds the text of the SMS:

<?php

namespace App\Message;

class SmsNotification
{
    private $phoneNumber;
    private $text;

    public function __construct(string $phoneNumber, string $text)
    {
        $this->phoneNumber = $phoneNumber;
        $this->text = $text;
    }

    public function getPhoneNumber(): string
    {
        return $this->phoneNumber;
    }

    public function getText(): string
    {
        return $this->text;
    }
}

The SmsNotificationHandler class could have a method that uses a third-party service to send the SMS:

<?php

namespace App\MessageHandler;

use App\Message\SmsNotification;
use Symfony\Component\Messenger\Handler\MessageHandlerInterface;

class SmsNotificationHandler implements MessageHandlerInterface
{
    public function __invoke(SmsNotification $smsNotification)
    {
        // Use a third-party service to send the SMS
        // For example, using Twilio:
        // $twilio = new \Twilio\Rest\Client($sid, $token);
        // $twilio->messages->create($smsNotification->getPhoneNumber(), [
        //     'from' => $from,
        //     'body' => $smsNotification->getText(),
        // ]);
    }
}

Routing the Message to the Transport

The next step is to tell the Messenger component which transport to use for each message. You can do this by editing the config/packages/messenger.yaml file and adding a routing section. In this section, you can map each message class to a transport name. For example, to use the Redis transport that we configured earlier for the SmsNotification message, you can add the following lines:

# config/packages/messenger.yaml
framework:
    messenger:
        transports:
            async: "%env(MESSENGER_TRANSPORT_DSN)%"

        routing:
            # async is whatever name you gave your transport above
            'App\Message\SmsNotification': async

You can also use different transports for different messages if you want.

Dispatching the Message

The next step is to dispatch the message to the transport. You can do this by using the MessageBusInterface service that is provided by the Messenger component. You can inject this service into any class that needs to send messages, such as a controller, a service, or a command. For example, in a controller, you can dispatch a message like this:

<?php

namespace App\Controller;

use App\Message\SmsNotification;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Messenger\MessageBusInterface;
use Symfony\Component\Routing\Annotation\Route;

class HomeController extends AbstractController
{
    #[Route('/home', name: 'app_home')]
    public function index(MessageBusInterface $messageBus): JsonResponse
    {
        $messageBus->dispatch(new SmsNotification('1234567890', 'Hello from Symfony!'));

        return $this->json([
            'message' => 'Message has been dispatched successfully!',
        ]);
    }
}

This will send the message to the Redis transport, where it will be stored until it is consumed by a worker.

Consuming the Message

The final step is to consume the message from the transport and execute the handler. You can do this by using the messenger:consume command provided by the Symfony console:

php bin/console messenger:consume async -vv

This command will start a worker process that will listen to the async transport (or any other transport that you specify) and handle the messages that are received. The -vv option will enable verbose output that will show you the details of each message and handler. You can also use other options to control the behavior of the worker, such as the number of messages to handle, the memory limit, the signal handling, etc. You can see the full list of options by running:

php bin/console messenger:consume --help

You can also run multiple workers in parallel to increase the throughput of your queue system. You can use tools like Supervisor or Systemd to manage your workers and ensure that they are always running.

Conclusion

In this article, we have seen how to use the Messenger component to implement a simple queue system in Symfony using Redis as the transport layer. We have learned how to install the required packages, configure the transport, create the message and the handler, route the message to the transport, dispatch the message, and consume the message. The Messenger component provides a powerful and flexible way to send and receive messages between different parts of your application or between different applications. You can use it to implement various patterns, such as command bus, event bus, query bus, etc. You can also use different transports, such as AMQP, Doctrine, Amazon SQS, Google Pub/Sub, etc. You can find more information and examples in the official documentation.

A Simple Way to Validate API Requests in Symfony

Daniyal Javani — Wed, 29 Nov 2023 11:43:06 +0000

Symfony is a popular PHP framework that provides many features to simplify web development. One of these features is the ability to validate API requests using data transfer objects (DTOs) and annotations. In this article, we will see how to use this feature to create a simple API endpoint for creating a post with some related fields.

What is a DTO?

A DTO is a class that represents the data that is transferred between different layers of an application, such as the presentation layer and the business layer. A DTO can be used to map the values from the request, validate them, and pass them to the service layer. A DTO can also be used to return the data from the service layer to the presentation layer.

How to create a DTO in Symfony?

To create a DTO in Symfony, we just need to create a class with some public properties that will hold the values from the request. We can also use annotations to define the validation rules for each property, such as NotBlank, Type, Range, etc. These annotations are provided by the Symfony Validator component, which is a powerful tool for validating data in Symfony.

Please ensure that all the required packages are installed before starting.install all necessary packages before starting:

composer require symfony/serializer
composer require symfony/validator

For example, let's create a DTO class for creating a post with some related fields, such as title, content, author, category, and tags. We can use the following code to create the class:

<?php

namespace App\Dto;

use Symfony\Component\Validator\Constraints as Assert;

class CreatePostDto
{
    public function __construct(
        #[Assert\NotBlank]
        #[Assert\Type('string')]
        public readonly string $title,

        #[Assert\NotBlank]
        #[Assert\Type('string')]
        public readonly string $content,

        #[Assert\NotBlank]
        #[Assert\Type('string')]
        public readonly string $author,

        #[Assert\NotBlank]
        #[Assert\Type('string')]
        public readonly string $category,

        #[Assert\Type('array')]
        public ?array $tags = null,
    ) {
    }
}

As you can see, we have defined the properties of the DTO class and used annotations to specify the validation rules for each property. We have also used the readonly modifier to make the properties immutable, which means they cannot be changed after the object is created. This is a good practice to ensure the consistency and integrity of the data.

How to use a DTO in a controller?

To use a DTO in a controller, we just need to use the class as a dependency in the method of the controller with the annotation #[MapRequestPayload]. This annotation tells Symfony to automatically map the values from the request into the object of the DTO class. We can also use the #[Route] annotation to define the route for the controller method.

For example, let's create a controller method for creating a post using the DTO class we created before. We can use the following code to create the method:

<?php

namespace App\Controller;

use App\Dto\CreatePostDto;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpKernel\Attribute\MapRequestPayload;
use Symfony\Component\Routing\Annotation\Route;

class PostController extends AbstractController
{
    #[Route('/api/v1/posts', name: 'app_api_create_post_v1', methods: ['POST'])]
    public function v1Create(#[MapRequestPayload] CreatePostDto $createPost): JsonResponse
    {
        // Here we can use the $createPost object to pass the data to the service layer
        // For simplicity, we will just return the data as a JSON response
        return $this->json([
            'response' => 'ok',
            'title' => $createPost->title,
            'content' => $createPost->content,
            'author' => $createPost->author,
            'category' => $createPost->category,
            'tags' => $createPost->tags,
        ]);
    }
}

As you can see, we have used the #[MapRequestPayload] annotation to inject the CreatePostDto object into the controller method. We have also used the #[Route] annotation to define the route for the method, which is /api/v1/posts with the POST method. Inside the method, we can use the $createPost object to access the data from the request and pass it to the service layer. For simplicity, we will just return the data as a JSON response using the json method of the AbstractController class.

How to test the API endpoint?

To test the API endpoint, we can use a tool like curl to send a request to the endpoint with the data we want to create a post. We need to make sure to add the Content-Type: application/json header to the request, as we are sending the data in JSON format. We can also use the -v option to see the verbose output of the request and the response.

For example, let's send a request to the endpoint with the following data:

{
  "title": null,
  "content": "In this article, we will see how to use DTOs and annotations to validate API request in Symfony",
  "author": "John Doe",
  "category": "PHP",
  "tags": ["Symfony", "API", "Validation"]
}

We can use the following command to send the request:

curl -v --request POST \
  --url http://127.0.0.1:8001/api/v1/posts \
  --header 'Content-Type: application/json' \
  --data '{
  "title": null,
  "content": "In this article, we will see how to use DTOs and annotations to validate API request in Symfony",
  "author": "John Doe",
  "category": "PHP",
  "tags": ["Symfony", "API", "Validation"]
}'

And here is the result:

< HTTP/1.1 422
< Content-Type: application/json

{
  "type": "https:\/\/symfony.com\/errors\/validation",
  "title": "Validation Failed",
  "status": 422,
  "detail": "This value should be of type unknown.\ntitle: This value should not be blank.",
  "violations": [
    {
      "propertyPath": "title",
      "title": "This value should not be blank.",
      "template": "This value should not be blank.",
      "parameters": {
        "{{ value }}": "null"
      },
      "type": "urn:uuid:c1051bb4-d103-4f74-8988-acbcafc7fdc3"
    }
  ]
}

As you can see, we have successfully created a post using the API endpoint and received the data back as a JSON response.

Conclusion

In this article, we have seen how to use DTOs and annotations to validate API request in Symfony. This is a simple and elegant way to handle the data from the request, validate it, and pass it to the service layer. We have also seen how to use the #[MapRequestPayload] annotation to automatically map the values from the request into the object of the DTO class. We have also seen how to test the API endpoint using curl.

We hope you have enjoyed this article and learned something new. If you have any questions or feedback, please feel free to leave a comment below. Thank you for reading!

How to Add JWT Login to a Symfony Project

Daniyal Javani — Tue, 21 Nov 2023 14:06:06 +0000

In this tutorial, I will show you how to implement a simple JWT authentication system for your Symfony project. JWT stands for JSON Web Token, which is a standard for securely transmitting information between parties as a JSON object. JWT can be used to authenticate users and authorize access to protected resources, such as APIs.

Prerequisites

To follow this tutorial, you will need:

PHP 8.0 or higher
Composer
Symfony CLI
A database server (MySQL, PostgreSQL, etc.)
A tool to test your API requests (Postman, Insomnia, etc.)

Creating a New Symfony Project

First, let's create a new Symfony project using the Symfony CLI. Open a terminal and run the following command:

symfony new jwt-test

This will create a new Symfony project in the jwt-test directory.

Installing the Required Packages

Next, we need to install some packages that we will use for this tutorial. We will use the Doctrine ORM to interact with the database, the MakerBundle to generate code, and the LexikJWTAuthenticationBundle to handle the JWT authentication.

To install these packages, run the following commands:

composer require symfony/orm-pack
composer require symfony/maker-bundle --dev
composer require lexik/jwt-authentication-bundle

Creating the User Entity

Now we need to create a User entity that will represent our users in the database. We will use the MakerBundle to generate the code for us. Run the following command:

php bin/console make:user

This will ask you some questions about the User entity, such as the class name, the properties, and the password hashing algorithm. You can accept the default values or customize them as you wish. I'll be keeping things simple for this tutorial and sticking with the default settings.

This will generate the following files:

src/Entity/User.php: The User entity class
src/Repository/UserRepository.php: The User repository class

Configure your database and run the following commands to create the users table:

php bin/console doctrine:database:create
php bin/console make:migration
doctrine:migrations:migrate

The final step in the database process is to create a user within the database. You need to first hash your password using this command:

php bin/console ecurity:hash-password

Copy the "Password hash" and paste it into the password column of the user. Set the roles column as [].

Configuring the Security

Next, we need to configure the security system to use the User entity and the JWT authentication. We will make some changes to the config/packages/security.yaml file.

We need to define two firewalls: one for the login endpoint, and one for the API endpoints. The login firewall will use the json_login authenticator, which will allow us to send the username and password as a JSON object and receive a JWT token in response. The API firewall will use the jwt authenticator, which will validate the JWT token and grant access to the protected resources.

To define the firewalls, add the following lines under the firewalls key:

firewalls:
    login:
        pattern: ^/api/login
        stateless: true
        json_login:
            check_path: /api/login_check
            success_handler: lexik_jwt_authentication.handler.authentication_success
            failure_handler: lexik_jwt_authentication.handler.authentication_failure
    api:
        pattern:   ^/api
        stateless: true
        jwt: ~

The pattern option defines the URL pattern that matches the firewall. The stateless option indicates that the firewall does not use sessions or cookies. The check_path option defines the URL that will handle the login request. The success_handler and failure_handler options define the services that will handle the login success and failure events. The jwt option enables the JWT authenticator.

Finally, we need to define some access control rules to restrict access to the endpoints based on the user roles. We will use the PUBLIC_ACCESS role to allow anyone to access the login endpoint, and the IS_AUTHENTICATED_FULLY role to require a valid JWT token to access the API endpoints.

To define the access control rules, add the following lines under the access_control key:

access_control:
    - { path: ^/api/login, roles: PUBLIC_ACCESS }
    - { path: ^/api,       roles: IS_AUTHENTICATED_FULLY }

The path option defines the URL pattern that matches the rule. The roles option defines the required roles to access the path.

Here are the final changes that have been made in the config/packages/security.yaml file:

@@ -10,6 +12,17 @@ security:
                 class: App\Entity\User
                 property: email
     firewalls:
+        login:
+            pattern: ^/api/login
+            stateless: true
+            json_login:
+                check_path: /api/login_check
+                success_handler: lexik_jwt_authentication.handler.authentication_success
+                failure_handler: lexik_jwt_authentication.handler.authentication_failure
+        api:
+            pattern:   ^/api
+            stateless: true
+            jwt: ~
         dev:
             pattern: ^/(_(profiler|wdt)|css|images|js)/
             security: false
@@ -17,17 +30,9 @@ security:
             lazy: true
             provider: app_user_provider

     access_control:
-        # - { path: ^/admin, roles: ROLE_ADMIN }
-        # - { path: ^/profile, roles: ROLE_USER }
+        - { path: ^/api/login, roles: PUBLIC_ACCESS }
+        - { path: ^/api,       roles: IS_AUTHENTICATED_FULLY }

To create JWT tokens, it is necessary to generate key pairs:

php bin/console lexik:jwt:generate-keypair

Configuring the Routes

Next, we need to configure the routes for the login and the API endpoints. We will use the config/routes.yaml file to define the routes.

First, we need to define a route for the login endpoint, which will be handled by the api_login_check controller. This controller is provided by the LexikJWTAuthenticationBundle and will generate and return the JWT token. To define the route, add the following lines to the config/routes.yaml file:

api_login_check:
    path: /api/login_check

The path option defines the URL that matches the route. The api_login_check controller is automatically registered by the bundle, so we don't need to specify the controller name.

Next, we need to define a route for the API endpoint, which will be handled by our custom controller. We will create this controller in the next step. To define the route, we will use the #[Route] attribute on the controller class.

Make a request to the login endpoint to obtain a JWT token.

curl --request POST \
  --url http://localhost:8000/api/login_check \
  --header 'Content-Type: application/json' \
  --data '{
    "username": "REPLACE_YOUR_EMAIL",
    "password": "REPLACE_YOUR_PASSWORD"
  }'

Creating the API Controller

Now we need to create a controller that will handle the API requests. We will use the MakerBundle to generate the code for us. Run the following command:

php bin/console make:controller

This will ask you the name of the controller class. You can choose any name you want, but for this tutorial, I will use HomeController. This will generate the following file:

src/Controller/HomeController.php: The HomeController class

We will use the TokenStorageInterface service to get the logged-in user and display their email.

To modify the controller class, replace the content of the src/Controller/HomeController.php file with the following code:

<?php

namespace App\Controller;

use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorageInterface;

class HomeController extends AbstractController
{
    #[Route('api/home', name: 'app_home')]
    public function home(TokenStorageInterface $tokenStorage): JsonResponse
    {
        $token = $tokenStorage->getToken();

        $user = $token->getUser();

        return $this->json([
            'message' => sprintf('Welcome to your new controller %s!', $user->getEmail()),
            'path' => 'src/Controller/HomeController.php',
        ]);
    }
}

The #[Route] attribute defines the route for the home action. The TokenStorageInterface service is injected as a parameter to the home method. The getToken method returns the current authentication token. The getUser method returns the actual user!

Make a request to the secured endpoint using the obtained JWT token to get the logged-in user's email.

curl --request POST \
  --url http://localhost:8000/api/home \
  --header 'Authorization: Bearer REPLACE_YOUR_TOKEN' \
  --header 'Content-Type: application/json'

Congratulations! You've successfully added JWT authentication to your Symfony 6 project. Enjoy the secure authentication mechanism for your APIs.

Temporary URL for local driver in Spatie Laravel media library

Daniyal Javani — Wed, 02 Dec 2020 11:49:35 +0000

Today’s guide describes the implementation of temporary URL for local driver in spatie/laravel-medialibrary. We'll accomplish this via Laravel signed URLs.

If you use getTemporaryUrl() function of the laravel-medialibrary for local driver, you will get the following error:
RuntimeException with message 'This driver does not support creating temporary URLs.'

The below steps describe how to implement getTemporaryUrl function in your Laravel app.

Step 1: Add a private disk to config file

Laravel already comes with local, public and s3 disks and you should add your own disk for private files to config/filesystems.

/*
|--------------------------------------------------------------------------
| Filesystem Disks
|--------------------------------------------------------------------------
|
| Here you may configure as many filesystem "disks" as you wish, and you
| may even configure multiple disks of the same driver. Defaults have
| been setup for each driver as an example of the required options.
|
| Supported Drivers: "local", "ftp", "sftp", "s3", "rackspace"
|
*/

'disks' => [
    'private' => [
        'driver' => 'local',
        'root' => storage_path('app/private'),
        'url' => env('APP_URL').'/private-storage',
        'visibility' => 'private',
    ],
],

Step 2: Add files to the private disk

You must ensure that files added to secret-files collection are automatically added to the private disk.

// in your model

public function registerMediaCollections(): void
{
    $this
       ->addMediaCollection('secret-files')
       ->useDisk('private');
}

Step 3: Create a controller that handle file requests

It does nothing but returning the media model instance.
Note: You can even authorise using Laravel policy.

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Spatie\MediaLibrary\MediaCollections\Models\Media;
use Storage;

class ServePrivateStorage extends Controller
{
    /**
     * Handle the incoming request.
     *
     * @param \Spatie\MediaLibrary\MediaCollections\Models\Media $media
     * @return \Illuminate\Http\Response
     */
    public function __invoke(Media $media)
    {
        // $this->authorize('view', $media->model);

        return $media;
    }
}

Step 4: Create the controller's signed route

Route::get('private-storage/{media}/{filename}', 'ServePrivateStorage')
    ->middleware('signed')
    ->name('private-storage');

Step 5: Now we need a media URL generator class

In this step we extend the DefaultUrlGenerator and override the getTemporaryUrl function.

namespace App\Services;

use DateTimeInterface;
use Illuminate\Support\Facades\URL;
use Spatie\MediaLibrary\Support\UrlGenerator\DefaultUrlGenerator;

class MediaUrlGeneratorService extends DefaultUrlGenerator
{
    public function getTemporaryUrl(DateTimeInterface $expiration, array $options = []): string
    {
        return URL::temporarySignedRoute(
            'private-storage',
            $expiration,
            ['media' => $this->media, 'filename' => $this->media]
        );
    }
}

Step 6: Replace your URL generator with the default one

Open the config/media-library.php file and replace the following class with yours.

'url_generator' => Spatie\MediaLibrary\Support\UrlGenerator\DefaultUrlGenerator::class,

That's it. Now your local driver does support creating temporary URLs.

An example of using GraphQL in Laravel

Daniyal Javani — Tue, 21 Apr 2020 07:51:07 +0000

If you haven't experienced GraphQL in Laravel yet, check out the example

https://github.com/Daniyal-Javani/Laravel-GraphQL-Example