I was first introduced to the concept of webhooks via a 2009 blog post by John Herren, a former colleague at Zend. At the time, they were in their infancy; today, they're ubiquituous, as they provide a mechanism for a service to notify interested parties of events. This saves traffic; instead of consumers polling an API for event changes, the service notifies them directly. It also means that the consumer does not need to setup things like cronjobs; they instead setup a webhook endpoint, register it with the service provider, and their application takes care of the rest.
The thing is, handling a webhook can often lead to additional processing, and you are expected to send an immediate response to the provider indicating you received the event.
How can you achieve this?
Sites I build often utilize cronjobs to periodically pull in data from other sources. For example, I might want to poll an API once a day, or scrape content from another website once a month. Cronjobs are a perfect fit for this.
However, cron has a few problems:
Since most sites I build anymore use mezzio-swoole, I started wondering if I might be able to handle these jobs another way.
I've been using Caddy as a front-end reverse proxy for several years now, on the advice of Marco Pivetta. Somewhere along the line version 2 was released, and I updated at some point, but evidently didn't quite understand some of its configuration options, particularly around HSTS support and providing your proxied application information about how the client tried to connect.
The Laminas Project has close to 200 repositories between the main project, Laminas API Tools, and Mezzio. It's a lot to maintain, and keeping on top of incoming patches can be a gargantuan task, much less creating releases.
That's why this past year, we've spent a bunch of time on streamlining our processes; we want to be able to review, merge, and release changes quickly and confidently. To that end, we have developed a number of GitHub Actions to make these processes as easy as possible for our maintainers.
I fielded a question in the Laminas Slack yesterday that I realized should likely be a blog post. The question was:
Is there a way to register development-mode-only modules in Mezzio?
There's actually multiple ways to do it, though one that is probably more preferable to others.
Progress has been happening at a furious pace on the Zend Framework to Laminas transition, with major changes still dropping even now.
Most recently, we decided to rename the subprojects. Apigility will become the Laminas API Tools, and Expressive will become Mezzio.
For more background, read the Zend by Perforce blog post.
Due to disorganization on my part, I accidentally booked php[world] 2019 to coincide with a family commitment.
As of 2019-10-01, I am once again employed full-time. Thank you everyone who reached out!
Fourteen years ago, almost to the day, I received a job offer from Zend to join their nascent eBiz team, where I started contributing almost immediately to the yet-to-be-announced Zend Framework. Two years later, I joined the Zend Framework team full-time. A year later, I was promoted to Architect. A year after that, I was promoted to Project Lead of Zend Framework, a role I kept for the next ten years. Over the years, Zend was acquired by RogueWave Software, which was in turn acquired by Perforce earlier this year.
Two months ago, almost to the day, was my last day with Zend/RogueWave/Perforce.
I'm now looking for a new adventure.
Last week, I did some system updates, and then decided to compile the most recent PHP releases. I've used phpbrew to manage multiple PHP releases for a number of years, and having it install a new version is fairly routine.
Except this time, it wasn't. Due to updates I installed, I was getting errors first with compiling the GD extension, then with ext-intl:
If you want Freetype support in ext-gd, you are expected to install the
package libfreetype-dev. On Ubuntu, this now installs libfreetype6-dev, which
no longer includes the
freetype-config binary that PHP's
uses to determine what features it supports.
Similarly, ext-intl depends on the package libicu-dev. Ubuntu's package now
icu-config binary used by PHP to determine feature support.
I searched for quite some time to find packages that would resolve these problems. I could have found the source code and compiled it and linked to that, but that would mean keeping that up-to-date on top of my PHP installs.
I even looked in the ondrej/php PPA, as that repository has multiple PHP versions already, including source packages.
And then I thought: why not try using those instead of phpbrew?
The rest of this post is how I made that work.