The Weekly Talk Review #2 – Patterns that Pay Off by Matt Stauffer

My choice for this second issue of “The Weekly Talk Review” is another Laracon 2018 talk: “Patterns that Pay Off” by Matt Stauffer.

It kept me glued to the screen, and I am not exaggerating. I love practical and pragmatic talks. After listening to a lot of talks, I learned how to recognize speakers that have broad, practical experience with the topic they have chosen for the talk.

Do not be fooled by the title: it’s not about design patterns in a traditional way. This talk is about a lot of practical dos and don’ts that you can apply in your everyday job. I loved how he managed to explain the importance of the value you give to your customer. I also appreciated a lot the concept of “posture” towards patterns, or how we approach them.

Also, the “Test to save your job” and “Monolith first” parts are pure gold. However, I am not going to spoil it, so watch it and enjoy!

The Weekly Talk Review

First time here? Welcome to The Weekly Talk Review, here on FrancescoCodes.

Every week I will make a short review (~100 words) of a talk that I liked and found interesting enough to share here with you. I am not going to review only Laravel related talk: why limit myself when there is a lot of stuff to learn?

Have fun and feel free to suggest a talk in the comments if you want to share it with us. I will be more than happy to see it and publish it here!

The Weekly Talk Review #1 – Design Patterns with Laravel by Colin DeCarlo

For this first issue of “The Weekly Talk Review”, my choice is this fantastic talk by Colin DeCarlo at Laracon 2018: “Design Patterns with Laravel”.

I must admit it: I have a thing for everything that makes learning way easier than expected. In this talk, Colin tells us about his struggles with the Design Patterns book first impact, and how things can be explained differently. Then, he makes some perfect, real-life examples of code refactoring while implementing these patterns. The code highlighting style is the cherry on top.

I think this talk will be particularly useful to all those developers that are starting refactoring their first codebases into something more structured and well written.

Timing is also perfect: in ~32 minutes everything fits in it perfectly without any sense of haste. I am not going to tell you which patterns he has chosen; you will do it by yourself 🙂

Also liked a lot the quote from Kent Beck:

“Make the change easy, then make the easy change”.

Enjoy it!

The Weekly Talk Review

First time here? Welcome to The Weekly Talk Review, here on FrancescoCodes.

Every week I will make a short review (~100 words) of a talk that I liked and found interesting enough to share here with you. I am not going to review only Laravel related talk: why limit myself when there is a lot of stuff to learn?

Have fun and feel free to suggest a talk in the comments if you want to share it with us. I will be more than happy to see it and publish it here!

Building a Laravel Development Environment with Docker, Vessel and… LaraPrep!

Once upon a time…

… I used to develop my applications in a Vagrant/Homestead development environment. It worked pretty well, I remember using it for a lot of projects, but soon performances decreased, especially in large projects/codebases.

Sure, I was able to make some optimizations and tweaks here and there, but it was mostly a palliative. I knew I needed something different.

Then, Docker arrived. So I started my research of a cool Laravel application development environment. 

I loved the way Docker made everything easier regarding development environment organization. Sure, it has a very steep learning curve (especially at the beginning), but it was worth it.

The next step was quite obvious: find a set of scripts to make the provisioning of a new dev environment as easier as possible.

Why? Simple: I like to try/test new packages and techniques on Laravel. Well, to be more specific, I have to say that I want to explore them in a new, fresh Laravel application.

So, I discovered Laravel Vessel, an exciting project you can find here. What I love about Vessel is the minimalism of its footprint and provisioning. It just has the very basics:

  • PHP 7.2
  • MySQL 5.7
  • Redis;
  • NodeJS with NPM, Yarn, & Gulp;

However, I wanted to find a way to use it without having PHP installed locally. The dedicated documentation page helped me with a specific script. Everything worked so I asked myself: what if I try to automate it in a simple shell script?

Something that I can call with something like “myscript myproject” and:

  • creates a new Laravel project in the myfolder folder;
  • adds a new record to the hosts file, to reach my project with http://myfolder.test;

WITHOUT the need for anything on my local machine. Only exception: Docker and Docker Compose.

So, after a couple of hours on it, I finally made it! I put it on Github.

Here’s the code:

Nothing special, after all. This shell script defines a docker_prep function that:

  • initializes some variables with the user id and name;
  • echoes a new line into the hosts file, to add a new .test record in it (with the same project name we chose);
  • creates a new project using Docker and the shippingdocker dedicated image;
  • adds Vessel as a dependency;
  • calls the artisan vendor:publish Artisan command, passing the Vessel provider;
  • initializes the development environment;

With a one-line instruction like

you can now prepare the perfect development environment for your next application.

Enjoy it! You can find LaraPrep here on Github.

Note: if you have any feedback to improve this script, feel free to comment below or make a PR on Github 😉

The 2018 Mighty Laravel Application 20 Optimization Ideas Checklist

Here we go! Your Laravel application is now in production. You are online, ready to start making a lot of mecha-gazillion dollars.

Roses are red, violets are blue, tests are green and you feel so cool.

First user. Ten users. One hundred users. A thousand users! Suddenly, the more you go forward, the more your application becomes slower.

What should you do? Well… Devil is in details.

After some searching, I decided to create this list of 20 tips you can use to boost your Laravel application to a new level.

I will start with the basic stuff, mostly something you can apply in seconds. Then, I will introduce you to something at an intermediate level. Finally, the advanced things. If you follow the next steps in a proper way, I am sure your application will get a real boost.

Enjoy it! If you want to suggest something, leave a comment below! I will be more than happy to add it.

Basic Stuff

Ok, let’s see what we can do in seconds.

Route Caching

Every time your server execute a request, all the routes are registered. It takes some time. However, you can choose to cache them to skip the step instead of doing it.

Caching your routes is easy. All you have to do is to execute a command after you deploy your application:

However, if you add new routes or edit something don’t forget to clear the route cache and re-execute the command.

Note this only work with Controller routes.

Config Caching

Just like routes, you can also cache configuration files of your application.

Think about it: every single time you send a request to your app, Laravel needs to load different configuration files, and the .env file must be opened to read its contents. This approach is not performance oriented, huh?

Don’t worry; there is an Artisan command for that.

You can use it after your deploy. Just like routes, don’t forget to clear the config cache if you edit something.

Optimize the Composer Autoloader

Usually, the autoloader file generated by Composer is quite fast. However, in a production environment, things can get slower if PSR-4 and PSR-0 autoload rules are set up.

You can optimize the autoloader file creation process by adding the

command to your deploy script. Don’t forget it 😉

False Myths: “Don’t Use a Lot of Blade Views”

I have heard this a LOOOOOOT of times.

“Don’t use a lot of Blade views because application performance will decrease!”

Totally – not – right. Seriously.

Remember: Laravel compiles Blade views. Compiled means that at the end of the process you have a compiled, complete file that is going to be used instead of multiple files.

So, don’t worry 😉

Intermediate Stuff

Switch to Another/Better Cache/Session Driver

By default, when you start a new Laravel project the default driver for Cache and Sessions is “file”. It is ok for the local development environment and small projects, but wrong when things are getting serious.

So, think about moving on to something better like Redis. Laravel has built-in support for it, and all you need to do is to install Predis.

More details here and here.

Update Laravel Version ASAP

Remember to update Laravel as soon as possible when a new version comes out. It’s not just about features: when possible, all the contributors spend time fixing performance issues around the codebase.

So, stay tuned and keep your code up to date.

Unused Service Removal

This one is a trick a lot of people often forget. The fundamental question is the old one:

“Do I need it?”

Now, we know that Laravel has a lot of stuff inside of it. After all, we are talking about a full-stack framework, made to solve a lot of specific issues. That said, the perfect weapon does not exist.

Spend some time checking the config/app.php file to see if you can find a service provider you don’t need. Try to remove it and test your application if everything is ok.

It should help (a little bit)!

Use Eager Loading for your Queries

If you know what Laravel is, you probably also know what the Eager Loading is. In case you live under a rock, Eager Loading is a way to improve Eloquent performance by using a specific syntax to reduce the number of queries it sends to the database.

This problem is known as N + 1 query problem. Let’s make an example. You have two models: Book and Author. Every book has its author.

Imagine that you have 1000 books in your database. Now, this code is going to execute 1001 queries to retrieve the author name for 1000 books.

1 (query to fetch data for 1000 books) + 1000 (queries to fetch author data for every book) = 1001.

However, if you write this code like

the underlying query is changed to avoid this performance problem. You will execute only two queries instead of 1001! A huge performance improvement.

Cache Query Results

Sometimes, caching specific queries results can be a great idea.

Imagine this situation: you are showing a “Top 10 Albums” in the home page of your application. The job is done by a query that fetches data from the database (maybe involving artists and other tables). Your home page is seen 1000 times/hour.

1000 queries per hour for that widget. 24000 queries/day for a f*****g widget.

Now, let’s say the Top 10 is updated hourly. So, what about caching the result for an hour?

With the remember method of the Cache component you will be able to fetch data from the database, save it on the cache storage and use it for 60 minutes. After that period, “fresh” data will be fetched again from the database.

From 24000 to 24 queries/day.

Add Indexes to your Tables

Remember to add indexes to your tables when necessary. It may seem a trivial tip, but it’s not. I saw a lot of applications without indexes on their tables.

You can do it easily with a new migration and dedicated code inside of it.

You can’t just create indexes wherever you like it. You must study your business, your code and queries, understand where it is necessary and then add the required indexes.

Too Many Middlewares?

Under the hood, Laravel does a lot of (pre/post) calls for every middleware you register in the application code. So, be sure to double check them and remove what you don’t need.

You can find the list, as usual, in the Kernel.php file.

Time to Use Queues!

Sometimes, Laravel applications are way slower than expected because you can asynchronously implement synchronous tasks and you don’t do it.

The most used example is the welcome email sending. Let’s imagine a flow:

  1. user filled our form;
  2. we save his/her details on the database;
  3. we send him/her an email with a welcome message and a confirmation link;
  4. we show him/her a “Thank you!” view;

Well, a lot of times a saw all this stuff entirely done in a controller and sequentially.

My suggestion here is to learn how to use events and queues. You could use them to delegate the email sending procedure to another dedicated process and improve the final user experience.

Advanced Stuff

Use Pusher to Improve Async Tasks

Just a couple of lines above I wrote about queues. Well, you can also use queues to improve user-facing tasks, sometimes.

Imagine that you are creating a heavy (in terms of calculations) procedure and you want to show a progress bar for your user. You can easily use an async job on a queue and an integration with Pusher to send messages to your frontend even if the task is not complete yet.

Another often used example is a way to send notifications to your user without the need to reload the page.

Think about it!

Use Logs / Debugbars / Laravel Telescope to Measure Stuff

There is a quote that I love about what you can improve. I’ve heard from my CEO (thanks Massimo!) quoting Peter Drucker.

You can’t improve it if you can’t measure it.

This concept fits perfectly in the context of web applications. There is a lot of stuff to be measured to improve requests management times. Luckily for us, there are also a lot of excellent tools to do it.

  • Slow query logs: in MySQL, MariaDB and other databases you can enable a dedicated log for slow queries to track what is taking a lot of time. You can use this data to understand if a specific piece of code (or query) must be changed or optimized;
  • Debugbar: Laravel Debugbar is a fantastic package you can use to collect data about a lot of your application aspects. Queries, views, times and so on;
  • Laravel Telescope: another cool tool is Laravel Telescope, defined as “an elegant debug assistant” for a Laravel application. If you are interested, I have already written an article about it here;

Update PHP

It is quite simple, but I decided to add it to the Advanced group, because if your codebase is a large one this could be a difficult task.

Consider updating your old application to PHP 7.* if you have not done it. Of course, don’t also forget that you will also need to update your Laravel version.

Consider Lumen for Services

If your application is growing a lot, start considering a way to split stuff into separate services. There is not a clear guide for doing this: the perfect splitting criteria depends on many factors, from the domain of your application to the work you need to do to split all the necessary stuff.

However, when you start to “break the monolith” your application can breathe again.

If you are interested in the subject, this article can be a good start:

Serve Assets with a CDN

I am quite sure you have a lot of frontend assets, like CSS files and JS scripts.

You can reduce the amount of data you send to your users in many ways:

  • Assets minification;
  • Assets bundling;
  • Enable gzip compression;

However, if you experience a lot of traffic you can host your assets to a dedicated CDN service, like:

  • Akamai
  • Max CDN;
  • Cloudflare;
  • Amazon AWS Services (S3 + CloudFront);

Use Advanced Measurement Tools

Installing the Laravel Debugbar or Telescope can be a good start, but for more significant applications, it could not be enough.

You should choose more advanced tools like:

  • New Relic;
  • AppOptics;
  • Datadog;
  • Sentry;

Applications in the list above do not do the same thing: they are made for different purposes. Spend some time studying them to understand how they can help you.

Vertical Scaling

You have done everything to optimize every single bit of your code, but your application is growing. Sooner or later you will need to scale your application vertically.

It’s a simple concept: more RAM, more space, more bandwidth, more CPU.

Note that this is a quite common practice for a lot of startups that do not have enough time to schedule a refactoring/optimization procedure. It’s perfectly ok, so consider it like a temporary solution to give you some breath.

Horizontal Scaling

Another approach to scaling, different from the traditional vertical scaling, for two reasons:

  • Instead of raising your resources on the current configuration, you will add more items to it to deal with the traffic increase differently. While in the context of vertical scaling you merely raise the level of your server configuration, scaling your application horizontally means that it will run on different machines, maybe behind a load balancer and other services. It means more setup and configuration; it’s not so simple as it may seem;
  • Not all applications are written to be scaled horizontally in a matter of hours. Sometimes you will need to refactor and isolate some code; sometimes you will need to split your application in different, smaller services that are going to scale differently;

There is a lot of work to do, but when you can horizontally scale your application, the benefits are incredible.


Enough stuff for today! I have created this list by merging my personal experiences and some research I have done for it.

If you want, feel free to suggest new items, I will be happy to update it accordingly.

Monitoring a Laravel Application with Telescope

I am always excited when a new Laravel ecosystem product comes out. I am not a fanboy, I have always been skeptic and critic about some parts of the framework when I don’t like them, but there is something (among many others) I love about Laravel: its pragmatism.

So, every single time they release something new I am 100% sure that it’s something that can be useful, no matter if paid or not (the cure the team put in it makes nearly impossible to feel the difference).

Today I want to talk a little bit about Laravel Telescope, a debugging tool for Laravel applications. On the Telescope Github page is defined as an “elegant debugger assistant”.

You can use it to monitor a lot of stuff:

  • Requests
  • Commands
  • Exceptions
  • Logs
  • Queries
  • Events
  • Mail

… and more. In this article, I will show you how to install it and then use it in your workflow.

Installing Telescope is easy. All you have to do is to add it as a dependency of your project with Composer.

Once done, you only have to run a couple of commands:

The first one is used to scaffold everything is necessary. Then the migrate command will take care of the database schema Telescope requires.

That’s it!


The installation command added a new telescope.php file in your config folder. The documentation suggests spending a little time exploring it.

In the file we can count four items:

  • Path: it’s just the path we will use to access Telescope. By default, its value is “telescope”. That means you will be able to access it at /telescope;
  • Storage: here we can define everything about where we are going to save Telescope related metrics. By default, Telescope saves data on specific MySQL tables we created during the install procedure;
  • Middleware: here you can define a list of middleware to be assigned to every single telescope route. By default, it includes the “web” group and the specific Telescope “Authorize”;
  • Watches: every single item Telescope is monitoring has its own “watcher”. Exceptions? ExceptionWatcher. Queries? QueryWatcher. The list goes on following this rule. Here you can customize this list to define what you want to track and what you don’t need;


Now we know how to install Telescope and how to configure it. Let’s use it! I will assume your Laravel project is accessible at http://myapp.test.

Let’s open it by going to http://myapp.test/telescope. Here’s the main dashboard:

Right now we are in the “Requests” section of Telescope. Try to visit, then come back here or refresh the page.

Yeah, it’s working! For every request, we can see the HTTP verb, the complete path (in this case we have an empty value because we requested the home page) and when the event happened. We also have an eye icon. It’s a button we can click to access more details about the request.

Let’s click on it!

For every request, we can see everything, from basic details to headers, related session data, and some metadata about the response.

One of the most useful features is also the ability to see “related” Telescope records. Example: in this request, we set a new cache item, the “a66bs…” one. We can look at its details by clicking on the eye icon again.

I like this feature. It is handy to debug in depth what can go wrong and have a better understanding of the app we are building.

Oh, talking about what can go wrong: let’s test one of my favorite ones. Exceptions!

First of all, go to the routes/web.php file and add this code.

Great. Now go to http://myapp.test/error. You should see the classic exception screen. Let’s go back to Telescope and click on the Exceptions in the menu.

Yeah, we got it! Let’s click on the eye icon to see some details about this exception.

I love this one.

With a little effort (installing and configuring Telescope required nearly no time) we have a lot of data about this exception message, location and stack trace. Also, we can quickly check other occurrences for the same exception or access the related request!

I think this is one of the most amazing features of Telescope. Yeah, I already know that the sea is plenty of advanced software already doing this. I am thinking about Sentry because I use it in my everyday job.

However, what if are you just bootstrapping a product and you want to have an excellent debugging tool with nearly no install effort? Telescope is the perfect fit.

Huh, talking about production…

Should I Use it in Production?

By default, Telescope is visible in the local environment only. However, you can easily modify this behavior by editing the app/Providers/TelescopeServiceProvider.php file.

There is a method called “gate()”. You can edit it with your custom logic to decide if a specific authenticated user can see the Telescope dashboard or not. The documentation suggests a straightforward approach: define an email whitelist. However, you can decide to stick with it or implement your logic.

So… Should you use it in production?

Given my previous experiences, I think I will do it for my next project. Especially in a first bootstrapping phase, it could save me a lot of time.

Have you already tried it? What do you think about it? Let me know in the comments.

Dall’Actor Model alla Pratica – Giocando con I Processi in Elixir

Il mio viaggio in Elixir prosegue e, devo ammetterlo, è sempre più stimolante. Non soltanto da un punto di vista strettamente “tecnico” ma anche da quello legato alle inclinazioni personali, legate all’apprendimento (ed insegnamento) di qualcosa di nuovo.

Qualche settimana fa ho spiegato, partendo da un ottimo articolo in inglese, cos’è l’actor model. Qualche giorno fa, invece, ho spiegato come installare Elixir e configurare un primo progetto. Oggi mettiamo in pratica tutto quello che abbiamo visto: scriveremo del codice creando una piccola applicazione che fa uso di processi!

Ehm, cosa?

In Elixir, ogni singola riga di codice viene eseguita in un processo. Non parliamo dei processi “classici” a cui siamo abituati: parliamo invece di quelli della BEAM, la VM su cui gira il codice che noi scriviamo.

Ora, Elixir è un linguaggio fortemente orientato alla concorrenza e alla scrittura di applicazioni che fanno più cose contemporaneamente (per davvero). Un processo della BEAM è molto più leggero di quelli a cui siamo abituati, tant’è che su una macchina normalissima è possibile crearne centinaia di migliaia e farli lavorare contemporaneamente senza nessun problema.

Non perdiamoci in chiacchiere, iniziamo da cose semplicissime per poi renderle più interessanti!

Continue reading

Functional Developer Italiani – Un Nuovo Gruppo Facebook

Alcuni di voi sapranno che, da qualche tempo, sono uno degli amministratori di Web Developer Italiani, uno (se non il) gruppo più forte in Italia per tutto quello che riguarda (you don’t say) lo sviluppo web, che conta undicimila sviluppatori iscritti.

Qualche giorno fa ho fondato il “fratellino minore”, in un certo senso, del gruppo: Functional Developer Italiani!

>> Functional Developer Italiani <<

Il gruppo è pubblico e aperto! Ti aspettiamo!

Sarà dedicato TOTALMENTE allo sviluppo con linguaggi funzionali.

Il lancio è stato spaziale, abbiamo raggiunto velocemente più di 100 iscritti!

L’obiettivo è semplice:

  • creare un centro di discussione attivo sull’argomento, tirando in ballo un po’ tutti i linguaggi che abbracciano questo paradigma. Niente fondamentalismi, niente estremismi di sorta;
  • “accogliere” anche chi è totalmente a secco sull’argomento, attraverso la diffusione di risorse entry-level più adatte a chi il paradigma non lo mastica per niente;

Ti aspettiamo su Functional Developer Italiani! 🙂

Come Configurare un Primo Progetto Elixir (ed effettivamente è semplicissimo)

Qualche giorno fa ho scritto un post per spiegare, in più o meno poche righe, cosa diamine è l’actor model. Come già scritto proprio in quelle righe, negli ultimi tempi mi sto (ri)avvicinando ad Elixir. Stavolta, però, ho deciso di trovare quello che poteva essere un buon modo di imparare ad usarlo (senza dover partire dalle basi più banali) e nel contempo tenere un “diario” dell’avventura.

Ho una mia teoria sui “diari” nello sviluppo. Se ben tenuti, è molto più semplice scrivere materiale che sarà, a sua volta, molto più semplice da consultare per il lettore. Del perché, tuttavia, parleremo un’altra volta, oggi non siamo qui per questo.

Va bene, quindi cosa succede oggi?

Ecco cosa faremo:

  • innanzitutto, installeremo Elixir e tutto quello che serve per iniziare a lavorarci;
  • una volta installato tutto scopriremo Mix, uno dei tool più importanti di Elixir;
  • scopriremo un po’ di comandi aggiuntivi interessanti;
  • vedremo come mettere su un ambiente di lavoro decente in cui scrivere il nostro codice;

Continue reading

Cosa diamine è l’Actor Model, spiegato in poche righe

Prefazione (salta pure se vuoi, non è essenziale)

L’idea di questo post/traduzione mi è venuta leggendo un articolo di Brian Storti.

Di tanto in tanto cerco di (ri)avvicinarmi ad Elixir, per poterci mettere le mani in maniera sensata e tirare fuori un po’ di codice con cui divertirmi. Chi mi conosce bene tra l’altro sa che ho sempre avuto il pallino per le spiegazioni semplici. Sono convinto che l’apprendimento non debba essere una cosa noiosa, per quanto possibile, e che la capacità di sintesi è una cosa importante. Stasera, troppo stanco per scrivere del codice, mi sono detto: “ok, magari trovo qualche articolo interessante in giro“.

Mi sono messo così a pensare ai vari talk che ho sentito in giro ultimamente, alle discussioni che leggo sui vari forum/slack/chat e così via. Si parla spesso di Actor Model. Un concetto spesso descritto come “semplicissimo” (e lo è) ma raramente spiegato davvero. Non so dire con precisione perché, anche se una mezza idea ce l’ho: tendiamo a dare un sacco di cose per scontate, quando cerchiamo di spiegarne altre.

Ad ogni modo, del mio metodo di lavoro/studio/scrittura parlerò in un altro post. Torniamo all’articolo dell’ottimo Brian.

Ho trovato la domanda a cui rispondere: che cosa diamine è l’actor model? Il post che ho trovato è secondo su Google. La parte divertente arriva adesso però: cercando pagine in Italiano per “actor model”… non trovo nulla! Anzi, ad essere onesti ho trovato:

  • un link ad un libro su Amazon (in inglese);
  • un altro link ad un libro su Amazon (in inglese);
  • un link ad un account instagram (non riguarda l’actor model, ovviamente, ma un tizio che fa l’attore ed il modello);


Cos’è l’Actor Model (ecco, leggi qui)

Partiamo da un principio semplicissimo. Fino a qualche anno fa le nostre CPU raddoppiavano di potenza senza problemi a ritmo quasi regolare. Adesso le cose sono cambiate e il miglioramento non segue lo stesso trend. Succede una cosa diversa: aumentano il numero dei core. Di conseguenza, per trarre il maggior vantaggio dai nostri software dobbiamo riuscire a scrivere del codice che può essere eseguito su più core. Concurrency, la chiamano. Continue reading

Il mio nuovo package per Laravel 5.6: Circuit Breaker!

Di tanto in tanto mi capita di buttare giù due righe in PHP e scrivere dei package “ispirati” a qualcosa che ho visto a lavoro, o di cui magari ho avuto necessità nella stesura di questo o quel side-project. Qualche giorno fa, a lavoro, mi sono ritrovato a parlare con un collega del Circuit Breaker pattern, di cui si può trovare un’ottima spiegazione qui.

Circuit What?

Niente di complesso, ad essere onesti. Fondamentalmente si tratta di un pattern grazie al quale è possibile, in parole poverissime, “wrappare” una funzione/oggetto in modo tale da poterne monitorare lo “stato di servizio”. Per capirci meglio facciamo un esempio:

  • immaginiamo di avere un’integrazione con un gateway di pagamenti per il nostro store/applicazione;
  • in caso di malfunzionamenti abbiamo un meccanismo di fallback, che ci permette di segnare gli ordini che non possono essere processati se il gateway è giù;

Implementando un circuit breaker monitoriamo l’esito delle chiamate al gateway di pagamento. Se più di X chiamate in un certo periodo T non vanno a buon fine, allora possiamo marcare per un certo lasso di tempo il nostro gateway come “failed” ed usare direttamente il meccanismo di fallback, senza dover aspettare tutte le volte il gateway che, sappiamo, ormai è andato.

Abbiate pazienza, è sabato sera e non ho una gran fantasia.

Interessante! Cosa c’entra con Laravel?

C’entra perché chiunque può sviluppare la propria “versione” di un circuit breaker. Nel mio caso, ho deciso di creare un package per Laravel (dalla 5.6 in poi) che mi permetta di realizzare velocemente una cosa del genere.

Continue reading