Matthieu Napoli

Simpler single-file AWS CDK deployments

I am checking out the AWS CDK to deploy serverless applications. But having used Serverless Framework a lot, I find the AWS CDK very noisy and invasive in some of my projects. It doesn't have to be though. Here are my notes on how to use the AWS CDK in a single file, without polluting your existing projects.

Open-source funding in 2020

Back in January 2019, I created the Null company. My goal: help developers work better, through products, training and consulting. My secondary goal: make some of that work open-source. Just like my financial report for 2019, here's my yearly update for 2020 on funding open-source work.

AWS Lambda can now run PHP using Docker Containers

Update: Bref now supports deploying PHP apps with Docker on AWS Lambda. Check out the up-to-date guide: PHP on Lambda with Docker. AWS Lambda now supports running Docker containers! This is big news for the PHP community: while Bref runtimes provide out-of-the-box support for PHP on AWS Lambda, we can now run any container image 🎉 Let's check that out!

Email alerts on SQS dead letter queues

Update: are you using Serverless Framework? Check out Lift, a plugin that deploys pre-configured SQS queues, Lambda workers, and SQS DLQ with email alerts. When running asynchronous tasks on AWS, it often makes sense to send failed tasks to an SQS "Dead Letter Queue". A dead letter queue is simply a standard SQS queue that we create to store those failed tasks. All that is great, but what do we do with messages in that special queue? It doesn't make sense to process them again, since we know our code fails at that. What we want instead is get alerted, so that we can inspect those messages and debug the error.

Open-source funding in 2019

Back in January 2019, I created the Null company. My goal: help developers work better, through products, training and consulting. My secondary goal: make some of that work open-source. Last year, I was able to work on Bref and its documentation, various open-source projects, articles in this blog, the serverless PHP newsletter, as well as share through conferences, meetups and podcasts (a first for me!). That was awesome! Now I want to look back at 2019 and see how I am doing with funding that open-source work.

From LAMP to serverless: case study of externals.io

This article is part of a series of case studies of serverless PHP applications built with Bref on AWS Lambda. You can read more of those case studies here. This case study is about migrating the externals.io website to AWS Lambda using Bref. This is the first time I write about a serverless PHP website with a MySQL database. I hope it will interest a few people ;)

Serverless case study: PrettyCI and Laravel Queues

This article is part of a series of case studies of serverless PHP applications built with Bref on AWS Lambda. If you are not familiar with serverless and Bref, I invite you to read Serverless and PHP: introducing Bref. This case study is about prettyci.com, a SaaS that provides continuous integration for PHP coding standards for GitHub repositories. The idea is that anytime you push a commit to your GitHub repository, PrettyCI will analyze that commit using PHP CodeSniffer or PHP-CS-Fixer. Since PrettyCI integrates in GitHub's checks tab you can see the build result directly in your repository without having to leave your work.

HTTP performances with Bref v0.3

Back in October I published a case study of a serverless website: returntrue.win. This website runs on AWS Lambda using Bref. A new major version of Bref (v0.3) was released this month and it comes with completely new internals. I was curious, as many others were, of what it meant for performances.

Serverless case study: returntrue.win

This article is part of a series of case studies of serverless PHP applications built with Bref on AWS Lambda. If you are not familiar with serverless and Bref, I invite you to read Serverless and PHP: introducing Bref. This case study is about the returntrue.win website. This website was my first serious experiment with serverless and Function as a Service.

Serverless Laravel

Update: Since November 2018 AWS Lambda supports PHP via custom runtimes. Bref has changed to take advantage of that and the Laravel integration has changed accordingly. Read more about it in Bref's documentation for Laravel. The article below is now obsolete. Last week I introduced Bref as a solution to running PHP serverless. Today let's try to deploy a Laravel application on AWS lambda using Bref. The code shown in this article is available on GitHub. You can check out the demo Laravel application on AWS lambda here: https://k6ay4xiyld.execute-api.eu-west-3.amazonaws.com/dev. It is a simple application that uses a 3rd party HTTP API to convert between currencies.

Serverless and PHP: Performances

Last week I introduced Bref as a solution to running PHP serverless. Update: Since November 2018 AWS Lambda supports PHP via custom runtimes. Bref now takes advantage of that, you can read more about it at bref.sh. Performances have changed a lot with these new versions (see new benchmarks). This article is now obsolete. Today let's explore what performances to expect when running PHP on AWS lambda using Bref. Everything shown in this article is open source on GitHub and can be reproduced. Everything shown here is specific to AWS Lambda. Other serverless providers (Azure, Google Cloud…) could offer different performances and costs.

Serverless and PHP: introducing Bref

Serverless basically means "Running apps without worrying about servers". Obviously there are still servers involved, the main difference is that you do not maintain the servers and reserve their capacity. They are scaled up or down automatically and you pay only for what you use. This article intends to explain what serverless means for web applications and more specifically for PHP.

Organizing code into domain modules

Note: the french version of this article is published on Wizaplace's tech blog. We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code? how to organize teams?

My "speaker checklist"

I follow a checklist whenever I am planning to speak at a conference. I am sharing it so that hopefully it can help you too. The steps marked with 💥 are the one I failed before and don't want to fail again :) It also let me justify why something that sounds silly may be part of the list! The checklist is quite long and might seem paranoid or more stressful than helpful, but it's actually the contrary: the more you anticipate things, the less reasons you have to stress.

Using non-breakable spaces in test method names

Yes. This article is about using non-breakable spaces to name tests. And the fact that it's awesome. And why you should use them too. public function test a user can add a product to a wishlist() { // ... } The code above is valid PHP code and works. Non-breaking spaces (aka   in HTML) look like spaces in editors but are actually interpreted like any other character by PHP.

Approaching coding style rationally

Let's talk about how to format code and name things. I remember when PSR-1 and PSR-2 became a thing. Jeez that "use only spaces" thing was just ridiculous, I knew that tabs where better (right?). And those crazy formatting rules were the opposite of what I was used to. Nonsense! One day I did the jump and after a few weeks, I just didn't care anymore. I was over it, just like everyone else did, and PSR-2 was my new religion. Fast forward a few years and I'm at a talk where the speaker argues to use snake case for naming test methods. Dude, you crazy? We just finally got consistent style across all the PHP world! And we all know that camelCase looks much better right? How can I go against PSR-2? It turns out, after trying it, that this was a wonderful idea… Habits are sometimes making us blind. We think X looks prettier than Y but that's just the habit speaking. In this article I'll try to take a rational approach at coding style. That means leaving the "it looks ugly/better" at the door.

Test against the lowest Composer dependencies on Travis

Composer just got a new awesome addition thanks to Nicolas Grekas: prefer the lowest versions of your dependencies. composer update --prefer-lowest This amazing option will install the lowest versions possible for all your dependencies. What for? Tests of course!

Decoupling packages

Decoupling packages is a hard thing. There are not a lot of options, and this blog post is about how some options are better than others. Let's say for example that you are writing a "package", or library, to respond to HTTP requests (that kind of package could be considered the basis for a web framework). How do you handle routing? If you write your Router package as an independent package (which is good: small and specialized packages are more reusable and maintainable), you might not want to couple the HTTP package to the Router package: you want to leave users free to choose the router of their choice. So, what are your options to make the HTTP package and the Router package decoupled from each other?

Working with mails in dev environment

If your application sends emails, you probably don't want emails to be sent when you are developing on your machine. If you use nice libraries like SwiftMailer, it is easy to use a mock instead of sending real emails. But if you don't, you can act on PHP's configuration: instead of installing and using a real SMTP server on your machine, you can fake one using a simple script.