DEV Community: Tonko Mulder

Events, Listeners and Redis

Tonko Mulder — Fri, 15 Jan 2021 22:38:00 +0000

I have a project at work which uses Redis to handle the queues and the Laravel websocket package by Freek van de Herten from Spatie and Marcel Pociot from Beyond Code.

This all went fine for a long time, but hiccups started to come.

The issue I was starting to see that sometimes events were not broadcasted, which was weird as it was working before. Eventually they stopped working altogether. I've been trying to debug this myself but at first I didn't got very far.

After asking around on a course of action on how to handle this, I decided to try the power of open source. And so I created an issue on the Github issue tracker for the package.

There were not a lot responses to it, mostly people trying to help me debug this issue.

Pairing

I created the issue a bit before my holiday and upon returning I paired with a colleague to debug this ourselves. So at this point no broadcasting was being done and were thinking what would be causing this radical change.

Laravel patch updates

I'm someone who tries to stay up to date with dependencies, so I figured there must be some version bump on which it all stopped working.

Looking back in git history I saw that when it all worked the Laravel framework was on version 5.8.24. I figured that the issue probably originates in the Laravel framework, so I fixed composer to that version and ran composer update. And it all still worked, next step was to increment the patch version until it didn't work anymore.

The patch version on which broadcasting stopped working was 5.8.25 so I didn't have to look far. Looking at the release notes for that version one contribution stood out.

PR #28904 (Prevent event cache from firing multiple times the same event(s))

To make sure this was the one that was causing problems, I copied the files from the previous patch release and voila everything worked!

Discover my Events

After studying that PR I saw the shouldDiscoverEvents() method and that got me thinking, I remembered seeing something about this when Taylor tweeted about being able to cache events and being able to discover them.

To my dismay I discovered that I didn't have this method in my EventServiceProvider. After adding this method and clearing my event cache I saw that my broadcasting was working again yay :D

Not so soon!

Broadcasting was working again which was awesome, the thing I didn't mention that this was all using the sync queue connection driver. Which works, but is slower than when using Redis for example.

With the Redis queue connection driver broadcasting wouldn't work. The day before I had a thought; Redis has multiple databases and I made sure that every Laravel application had it's own.

Or so I thought...

Turned out that I had the same Redis database for production and staging, which shouldn't be a problem since they all have prefixes right?

Well.. only Horizon has these prefixes, the queue'd jobs which are stored in Redis do not.

Closing

The problem that I faced with broadcasting was solved by doing the following things.

add the shouldDiscoverEvents() method to the EventServiceProvider and let it return true
made sure that the Redis database was only being used by the current application.
The second point could also be fixed by using a prefix for the queue's. This has been proposed before, but it didn't gain any traction.

Combining Blade templates with Vue.js

Tonko Mulder — Fri, 13 Oct 2017 20:14:42 +0000

In a project that I am working on, there are currently two public facing parts.

Website
Backoffice

In a discussion about what (front-end) technique we should use. Vue.js being a big contender. But a big concern was Search Engine Optimization for the website.

Having no experience with prerender options (prerender.io, Nuxt.js) we chose to use the default template engine in Laravel projects (Blade).

I’d like to show how I went about and implemented this. Source code for an example project can be found on Github.

Starting from scratch, I just created a fresh Laravel project with

composer create-project laravel/laravel co-housing-blade-vuejs

The next step is to create some structure. Go to resources/views and add a directory called backoffice. And in that directory create a view called index.blade.php

In that file reference the app.css and app.js, put the latter at the bottom of the body tag. Otherwise Vue won’t load. And put one div with an id of app in the body.

Next add two controllers, PageController & Backoffice\PageController and update the current route to point to the main index method of the PageController.

Also add the route for the index method for the backend PageController.

Load the default welcome view in that method.

Both controllers

Web routes

By default a new Laravel project comes with an example Vue.js component, which is loaded in the backoffice/index.blade.php template. So all that is needed to show the Vue.js template is to run

npm run dev || yarn run dev

The result is that the ‘normal’ website is build using blade templates and that everything in the ‘backoffice’ route prefix is being rendered by Vue.js

So in closing we have two different front-end techniques in use due to SEO concerns. In a next article I’ll be looking into alternatives to only use Vue.js in the front-end.

First steps with Elasticsearch & Laravel

Tonko Mulder — Tue, 04 Jul 2017 12:48:47 +0000

After working with Solr in past employment, I’ve alway been interested in indexing large amounts of data and processing that.

So recently I was told to look into Elasticsearch and I’ve been following the How to integrate your Laravel app with Elasticsearch post by Tony Messias from Made with love.

As it turns out that it’s actually quite simple, the Eloquent model that needs to be indexed has a trait which contains a created and deleted event. These are actually Model observer events, which determine if a piece of data should be indexed by Elasticsearch.

public function saved ($model)
{
    $this->elasticsearch->index([
        'index' => $model->getSearchIndex(),
        'type' => $model->getSearchType(),
        'id' => $model->id,
        'body' => $model->toSearchArray(),
    ]);
}

public function deleted ($model)
{
    $this->elasticsearch->delete([
        'index' => $model->getSearchIndex(),
        'type' => $model->getSearchType(),
        'id' => $model->id,
    ]);
}

The first part was about getting data into Elasticsearch, the second part is about getting that data from Elasticsearch and presenting it on the Laravel side. Tony’s article is using a repository to interact with Elasticsearch. In that repository the following method is present to do the searching part.

private function searchOnElasticsearch (string $query): array
{
    $instance = new Article;

    $items = $this->search->search([
        'index' => $instance->getSearchIndex(),
        'type' => $instance->getSearchType(),
        'body' => [
           'query' => [
              'multi\_match' => [
              'fields' => ['title', 'body', 'tags'],
                    'query' => $query,
                ],
            ],
        ],
    ]);

return $items;
}

It returns an array with the data it retrieved from Elasticsearch, which in turn can be used by Laravel as a data source.

So these were my first steps with Elasticsearch, I like how easy it actually was setting this up. Next is implementing this in a personal project, and trying to learn more about Elasticsearch in the meantime.