Creating a Macro that lets you convert text to audio on-the-fly in Laravel without needing an extra package

Ok, so here is the deal: I wanted a quick and dirty way of dynamically and on-the-fly convert text to speech, preferably in PHP. Now, in the past I have fiddled around trying to do the opposite, aka transcribing audio to text.

I wanted to use my all-time favourite Web Framework Laravel and as an additional requirement, not having to install a third party package or library.

The solution I came up with is equally genius and hacky at the same time. Simply put, I use Google Translate to do the work for me behind the scenes. No API calls or anything required, just simply send a GET request to the URL that returns the audio file that gets created when you use Google Translate.

Ok, so let me explain. When you navigate to https://translate.google.com/ and start typing some text, you will notice that a ‘loudspeaker’ icon appears.

This means, Google has created an audio file on-the-fly. And it just so happens that this audio file can be accessed from a URL, which looks something like this:

https://translate.google.com/translate_tts?ie=UTF-8&client=gtx&q=Hello+World!&tl=en_US

If you open this URL as is, most browser will probably detect the filetype and render a nice audio player for you like shown below (Example: Google Chrome).

So, now that we know that this exists and where to get it, it is just a matter of writing some code to open the URL, get the data and store it in our application.

Let’s get our hands dirty with some code.

My initial approach was very simple. I didn’t even bother to create a page or a Controller or anything. I just put below code into my `web.php` routes file.

Now, when I hit the `text-to-speech` endpoint on my application, it would send a GET request to the URL where the audio file is located, get the data, create a filename and store it into the `storage/app/public` folder.

Although this works, I wanted to create a reusable helper for this functionality. In the spirit of Laravel’s nice fluent syntax used everywhere throughout the framework, I thought it would be really cool to create a Macro for the `Str` (String) facade. If you have never used or created Macro’s before, don’t worry, I will briefly explain. A lot of things in Laravel are Macroable (recognizable by the use of the Macroable trait). It is simply a way to extend functionality. Let’s take a simple example straight out of Laravel’s documentation:

Macros are registered in a ServiceProviders `boot` method, like in this instance in the `AppServiceProvider`. Here, a Macro called `github` is added to the Http client, which allows us to use it like this:

$response = Http::github()->get(‘/’);

This will send a request to Github with the headers as configured in the ServiceProvider. As you can see, it allows extending functionality and writing really elegant, expressive code.

But now back to the text-to-speech implementation. What I wanted to achieve was this:

$audioFile = Str::toAudio(‘Hello World!’); // gets the audio, stores the file and returns the path to the file

To achieve this, we basically just have to move my initial code into the AppServiceProvider. There we register our Macro as shown in the example above inside the boot method and that is pretty much all there is to it.

So the final code looks like this:

Note that I improved it slightly by not only passing the text to convert, but also the language as an optional second parameter, which means I can now also convert text in other languages to audio, as long as Google Translate supports it. 🤷‍♂

// Hello in Japanese

return Str::toAudio(‘こんにちは！’, ‘ja_JP’);

Summary

Obviously, this approach does have its limitations and drawbacks. For starters, everybody that has ever played around with Google Translate will know that certain words and expressions are not well picked up and converted by the underlying AI. Also the voice usually sounds ‘robotic’ and unnatural. So, I would suggest to use it only for simple use cases, such as short texts, preferably not containing any complicated words or phrases. Also, I think it goes without saying that results in English are quality-wise usually the best.

While I wouldn’t use this in a professional, large-scale business use case, it was a fun little thing to play around with.

I prepared a gist for this, so feel free to use it:

Thanks for reading! 😃

I personally have worked extensively with Action classes in a recent project, so this was a good timing for me to summarize Luke’s talk in the form of this article.

What are Actions?

To put it very simple: A broken-up service class which has one responsibility only. This means it usually only contains one method to do a specific task, which can be reused. This of course plays well with the principles of Separation of Concerns and also the approach of using Compositions (instead of inheritance). If this all sounds way too complicated for you, don’t worry, we will jump into some examples in a second!

Example: User Registration

Let’s say you have a simple sign up form on your website. Typically, you would receive the request in your Controller, validate the data, and then invoke, depending on your coding style, either the Model directly, or some Repository class to store the user to the database as shown below.

class RegisterController extends Controller
{
    public function store(RegisterRequest $request)
    {
        $data = $request->validated();

        $user = User::create([
            ...$data,
            'password' => Hash::make($data['password'])
        ]);

        $auth->login($user);

        return redirect(route('home'))->with('success', true);
    }
}

This is a fairly common approach and certainly works well, until the need arises to register the user from, let’s say, the command line. Of course, we would create a custom Artisan command for this task. Let’s see how this command would look like:

public function handle(): int
{
    $data = $this->validateData($this->getInput());
    
    $user = User::create([
        ...$data,
        'password' => Hash::make($data['password']);
    ]);

    $this->line("User {$user->email} has been registered.");

    return Command::SUCCESS;
}

private function validateData(array $data): array
{
    return Validator::make($data, [
        'email' => ['required', 'email', 'unique:users'],
        'name' => ['required', 'string', 'max:255'],
        'password' => ['required', 'min:6']
    ])->validate();
}

private function getInput(): array
{
    return [
        'email' => $this->argument('email') ?? $this->ask("What is the user's name?"),
        'name' => $this->argument('email') ?? $this->ask("What is the user's email?"),
        'password' => $this->argument('password') ?? $this->secret("What is the user's password?")
    ];
}

Again, no problem at all. We have, however, introduced duplicated code. The validation and creation of the user part has now to be maintained in several places, which is a problem in terms of maintainability.

Enter Actions

One very powerful and elegant solution to this is obviously using an Action. Let’s see how that would like applied to the previous example. For that, we create a file called RegisterUser.php under app/Actions (if the Actions folder doesn’t exist, just create it).

class RegisterUser
{
    public function __invoke(array $data): User
    {
        $data = $this->validateData($data);

        return User::create([
            ...$data,
            'password' => Hash::make($data['password']);
        ]);
     }

    private function validateData(array $data): array
    {
        return Validator::make($data, [
            'email' => ['required', 'email', 'unique:users'],
            'name' => ['required', 'string', 'max:255'],
            'password' => ['required', 'min:6']
        ]);
    }
}

Please note the name of the class. It is in the format of verb + noun. This makes it more explicit and easier to understand as to what the class does.

And now since we abstracted the logic, we can go ahead and replace this logic in both our Controller and the Artisan command, and also tests if you have them (spoiler: you should!) as shown below.

Our Controller will now look like this:

class RegisterController extends Controller
{
    public function store(RegisterRequest $request, RegisterUser $registerUser)
    {
        $user = $registerUser($request->all());

        $auth->login($user);

        return redirect(route('home'))->with('success', true);
    }
}

And the Artisan command:

public function handle(RegisterUser $registerUser): int
{
    $user = $registerUser($this->getInput());

    $this->line("User {$user->email} has been registered.");

    return Command::SUCCESS;
}

private function getInput(): array
{
    return [
        'email' => $this->argument('email') ?? $this->ask("What is the user's name?"),
        'name' => $this->argument('email') ?? $this->ask("What is the user's email?"),
        'password' => $this->argument('password') ?? $this->secret("What is the user's password?")
    ];
}

And that’s basically it. Clean abstraction, which means enhanced maintainability.

Now, Luke takes it even a step further in his Laracon talk by pairing it with Contracts (aka Interfaces), but I’ll leave that out for now. If you are interested in that as well, check out his awesome presentation on Youtube (it was the first talk of the event, starting at around 29 minutes into the video), and follow him on Twitter.

I hope this article was helpful and I hope you all have a nice day/morning/evening.

Stay safe.