Built with Bref

[mnapoli]

I would like to create a page that references applications or websites built with Bref.

In the meantime let's collect here links and descriptions of those applications. Feel free to post a comment, your application doesn't have to be a public website, it can also be anything not visible on the internet.

Here is my (public) list for now:

• prettyci.com, workers
• mnapoli.fr, website built with Symfony
• returntrue.win, website + API built with a custom PSR-7 framework and DynamoDB
• runtimes.bref.sh, website built with Slim
• https://externals.io/
• https://journal.serverless-visually-explained.com Laravel application
• https://port7777.com/ Backend API

[mnapoli]

https://arkadiuszkondas.com/php-grandmaster/ (https://github.com/akondas/php-grandmaster)

[atrope]

Https://www.suamusica.com.br (website built with phalcon uses alb to lambda)
Suamusica private APIs to our apps (cacheable and world-wide deployed with Cloudfront caching the public responses close to the user)

[nealio82]

https://kittyquotes.net (someday there'll be a PHP / serverless tutorial on github to accompany this site)

[mnapoli]

@atrope that's really interesting. Did you build a PHP layer yourself or are you using the Bref layers? If you have any numbers to share (either here or via a blog post) I'm sure many people would be interested to learn more :)

[atrope]

@mnapoli first we built ourselves our layer, and then we migrated to bref.
With bref we changed the PHP dockerfile so we could build some custom extensions with custom support (redis with igbinary, phalcon, imagick etc) and change some code (ALB Support and other issues).

The Performance with bref is 30% better than it was with our runtime(also was FPM based).

I Will write a blog post sometime but just for now here are some numbers:

Roughly 40M requests daily
In Peak, we have 2.5k concurrent lambdas
In API our average duration is 90ms
In Portal(Website) is 130ms

This of course when it goes to lambda and is not cached in CF.

• Some changes(challenges) we had to do coming from nginx is for example when a route is not found, it must check in lambda's public directory and do a file_get_contents of it and set appropriate headers(ads.txt, manifest.json examples).

• Most of our work was facilitated because we were already in containers thus we had(almost, just the ones cited above) no local assets files(a must in lambda).

• We created an integrated Slack bot that deploys our lambdas (minifying js/css and uploading to s3) in less than 30s using a BASH Layer - https://github.com/gkrizek/bash-lambda-layer - we deploy any branch to a new lambda and we have a complete new development env in some seconds each time we want to test any branch. When we deploy branch master, it updates our prod code. That's also great when something is not good we can revert our code for any commit we want in seconds.

• Setting the right alarms are also a must for this kind of scale, because some extra miliseconds could cost us double the money, so alarms must be finely tuned.

• Changing from ECS to Lambda gave us a roughly 25% economy in EC2 not even taking into account TCO and worldwide Infinitely scale/descale lambda+CF gives us, and not even needing to think of EC2 Reservations and hidden costs(storage, data transfer..).

I do plan to write a detailed blog post as soon as i have some free time but if anyone want to know something specific can shoot me a message :)

[mnapoli]

@atrope this is amazing! Thanks for sharing.

BTW ALB is definitely on my TODO list, I'm working on a project to try it out and document it (it just takes some time to go through everything).

[yousafs]

@mnapoli first we built ourselves our layer, and then we migrated to bref.
With bref we changed the PHP dockerfile so we could build some custom extensions with custom support (redis with igbinary, phalcon, imagick etc) and change some code (ALB Support and other issues).

I do plan to write a detailed blog post as soon as i have some free time but if anyone want to know something specific can shoot me a message :)

@atrope That is fantastic work!! I have been trying to get Imagemagick & Imagick installed using the same method but my PHP Dockerfile is not right and although I have installed the delegates for decoding I always get an error 'no decode delegate for this image format `PNG'. If you could publish yours (or the sections for adding these) it would be amazing!

[atrope]

@yousafs
Of course i can send you :)

In php.Dockerfile:

RUN LD_LIBRARY_PATH= yum install -y ImageMagick-devel
RUN pecl install imagick

and then rebuild, Simple as that.

[yousafs]

@atrope
Thank you! That is much simpler than my version - clearly I am not worthy :)
I will give it a try ...

[mnapoli]

Here is a new website shared in the Slack channel:

We launched a Project with bref on Lambda last week.

Setup is

• Domain DNS is at Route53
• All Requests go through Cloudfront /static -> S3 everything else through API Gateway to Lambda (No caching there currently)
• Lambda is in a VPC with a Aurora and an Elasticache (tbh. I think I'm going to cut the Elasticache and move the sessions stuff to Auroa)
• It's an Laravel App with Nova and some Jobs
• Assets are synced while deloying via a Gitlabrunner + Cloudfront Cache is invalidated at that point
• Entire Cloudfront Setup is in Cloudformation

Pain Points:

• I needed the Requested Hostname at my Lambda Function to determine the Language (Tenant) of the Page so a Lambda@Edge Function is running on every request that maps my Host to (yeah that's not really nice I know but I havn't found an alternative with Cloudfront)
• Setting Up VPC with Cloudformation is a pain so i did it manually

Url: https://radiome.de/ https://radiome.at/ https://radiome.fr/

[nealio82]

at https://mybuilder.com we're using Bref to generate reports in PDF format.

Using the fpm layer we have a single api endpoint which accepts a request payload containing an HTML string and a destination of where to upload the generated report. The endpoint does auth and validation, then pushes a notification through SNS.

A 2nd lambda function defined in the same template.yml using the base php layer (along with our own wkhtmltopdf layer which we created) converts the HTML string into PDF, before uploading it to the destination specified in the original payload.

We chose to launch this on lambda because we expect there to be spikes of usage throughout the day, and probably zero instantiations overnight, so fast scaling up-and-down was a key consideration.

We created our own wkhtmltopdf layer because:

1. there is no 'currrent' generic Linux binary any more (this is covered in the wkhtmltopdf FAQ)
2. there are 3rd party pre-compiled generic Linux binaries available, but they're also out-of-date, and we didn't want to have to trust random people over the internet not to include anything nefarious
3. we didn't want to use the vendor-specific binaries because that would have involved spinning up an EC2 box, which is an expensive way of just providing a PDF conversion service
4. we looked at puppeteer, but one of our teams had already used wkhtmltopdf so we wanted to carry on with what they'd already tried / learned
5. we also felt the performance of wkhtmltopdf would be better than running headless Chrome in Lambda using puppeteer
6. we felt this would be a great chance to learn about creating layers and compiling software in Lambda

[ondrejmirtes]

https://phpstan.org - running PHPStan inside a Bref project 😊

[vincentcau]

and a new one https://www.chouchouhotel.com/ 😊