Releases: brefphp/bref
0.5.8
This new release contains documentation improvements and one feature: #476 Add bref.dev short URLs.
A major pain when creating a new application is the API Gateway URL:
https://fd8s8cbq6l.execute-api.us-east-1.amazonaws.com/dev
That URL is long and not friendly. And more importantly, the /dev prefix breaks routing in most frameworks, like Symfony or Laravel.
I have created a little service called bref.dev. It lets us generate short domains for development. To use it, run:
$ vendor/bin/bref bref.dev
Creating a short URL for https://fd8s8cbq6l.execute-api.us-east-1.amazonaws.com/dev
Short URL created and active for 7 days: https://ca4mb8u.bref.devThe short URL that is created can be used instead of the API Gateway URL. It is shorter and does not have a directory prefix.
At the moment the service is in beta. It can break at any time. Short URLs are valid for 7 days after which they are disabled. That helps keep the service lean and cost-efficient.
0.5.7
-
Fix #372 with #466 Allow the region to be a variable in
serverless.yml, by @harmenjanssen -
#288, #457 Support binary responses (images, PDF, etc.) by @victormacko, @shrink, @Guillaume-Rossignol, @italo1983 and @bubba-h57.
It took months but we finally have a solution that requires the least effort from users, and supports the most use cases. Bref will automatically detect if the response is a text response or a binary response, and will behave accordingly (binary responses need to be sent as base64-encoded to API Gateway).
Below is an extract of the new documentation that can be read at https://bref.sh/docs/runtimes/http.html#binary-responses:
By default API Gateway does not support binary HTTP responses like images, PDF, binary files… To achieve this, you need to enable the option for binary responses in serverless.yml:
provider:
# ...
apiGateway:
binaryMediaTypes:
- '*/*'This will make API Gateway support binary responses for all responses. Your application can now return binary responses as usual.
However, you must define a Content-Type header on binary responses. If you don't, you may get the following error: Failed encoding Lambda JSON response: Malformed UTF-8 characters, possibly incorrectly encoded. Symfony's helpers or Laravel's helpers will take care of that for you. If you don't use them, here are some examples:
// Vanilla PHP example with a JPEG image response:
header('Content-Type: image/jpeg');
header('Content-Length: ' . filesize($filename));
fpassthru(fopen($filename, 'rb'));
// PSR-7 example:
return $response
->withHeader('Content-Type', 'image/jpeg')
->withHeader('Content-Length', (string) filesize($filename))
->withBody(new Stream($filename));0.5.6
0.5.6-beta1
Alpha release to test the GD extension (#396).
0.5.5
- #401, #407: The API Gateway timeout is changed to 28s for new projects, by @linuxjuggler
- #429: Add the
--stageoption for the bref dashboard, by @TiagoBrito
0.5.4
0.5.3
0.5.2
Quick summary:
- 🚢 Bref Docker images!
- 📈 Bref Dashboard!
- bug #394 fixed with #395 by @linuxjuggler: the
eventis not always an array
Docker images
Thanks to a huge contribution by @Guillaume-Rossignol, Bref now publishes Docker images on the Docker Hub: hub.docker.com/u/bref.
One use case for these images is local development. It is explained in details in the revamp "Local development for HTTP applications" guide, but here is an example using Docker Compose to run a HTTP app locally:
version: "3.5"
services:
web:
image: bref/fpm-dev-gateway
ports:
- '8000:80'
volumes:
- .:/var/task
depends_on:
- php
environment:
HANDLER: index.php
php:
image: bref/php-73-fpm-dev
volumes:
- .:/var/task:roAfter running docker-compose up, the application is accessible at http://localhost:8000/
We think this is a good alternative to sam local or serverless invoke local because Docker is an environment which many developers are starting to use, and because of much better performances.
It is also easy with Docker Compose to setup a database, or run CLI commands with the same environment as the rest of the application.
Since we have changed a bit how layers are built, new layers are available. But if you are using Bref 0.5 you don't have anything extra to do, you will get them automatically when you update Bref :)
Bref Dashboard
After months of iterations, we are very happy to finally publish the Bref dashboard publicly.
The dashboard is an addition to Bref that provides a visual interface to manage your application. It is meant to complete and enhance the rest of Bref features.
Right now it provides:
- a view of all functions and APIs deployed in one application
- direct links to each components in the AWS dashboard
- graphs of the response time (duration) and number of invocations in the last 30 days
- average response time
- number of errors in the last 30 days
- a log viewer (I'm super happy with this!)
We have plenty of ideas to improve the dashboard over time.
The great thing with the dashboard is that it is not bundled in Bref (which keeps Bref lightweight). Instead it is a Docker image. To open the dashboard, simply run:
vendor/bin/bref dashboard
This command will automatically recognize the AWS stack name and region from serverless.yml, pull the latest version of the dashboard and start it. The only requirement: Docker.
And the best thing is that the dashboard runs on your machine, with your own credentials.
You don't need to setup anything or give access to your AWS account to anyone. Anything your machine can access, the dashboard can show!
Log viewer
The log viewer helps you read and search your logs without having to go through the AWS console. We have tried to dim out the noise as much as possible to make the logs easy to read:
What does it mean for Bref?
The dashboard is close-source. The reason for that is that we are exploring the possibility of adding advanced and paid features to the dashboard in the future. The goal behind this is to find funding for the project. Note that the dashboard is a completely optional feature of Bref and it is not bundled in the open-source project.
Mixing open source with closed products and/or paid products is a delicate thing to do. I want to stress that we are being extremely careful with that. I have been thinking about this for more than a year, and I don't think I am done :)
My vision of a sane relationship between the open-source project and related products is:
- the open-source project must live and work on its own
- the open-source project must be usable and have its core features not impacted by other products
- other products (closed and/or paid) must live separately from the open-source project and not replace basic features that are already provided by the open-source project
In other words, Bref's mission is to help everybody create serverless PHP applications. Side projects or products can provide extra help around that (especially for power users or advanced scenarios), but do not strip away from Bref's mission. Basic features that are essential to create serverless applications must be open source.
As we move further with this I intend to make this a little bit clearer and more defined, but in the meantime I hope it helps.
If you have any questions or feedback, please share them in this Bref dashboard feedback issue. What you think is important. We try to make some decisions with the best intentions, but sometimes we get things wrong :)
0.5.1
The main feature of this new release: performance improvements!
New runtimes have been published: if you use Bref 0.5 with the Serverless plugin (default behavior) you don't have anything to do. If you include Lambda layers manually, check out runtimes.bref.sh for the new layer versions.
Improvements:
- #380, #378: PHP runtimes have been made lighter (by removing useless files) and faster (by optimizing PHP's compilation options): PHP's execution is 10% faster (for CPU-bound operations). You can check out updated benchmarks here: github.com/brefphp/benchmarks. By @TheNodi.
- #332, #373: Runtimes are now built against the new AmazonLinux version: 2018.03. AWS upgraded the version of Linux used in Lambda and we had to recompile PHP against it. By @TheNodi, @bubba-h57 and @mnapoli.
- #261, #377: the default timeout for console functions is now 30s (instead of 6s), by @Luitame
Documentation:
- #315, #376: the menu now reflects which page is currently open, by @Luitame.
- #312, #375: the list of case studies now contains a link to non-PHP case studies, by @Luitame.
Fixes:
- #379, #381:
bref cliarguments are now correctly escaped and forwarded to the lambda, by @shadowhand.
0.5.0
This is a "major" version without BC break, but with major changes that affect the usage of Bref.
Logo
Bref now has a logo, thanks to Percola.top and null:
Switching to Serverless
AWS SAM is being replaced by Serverless as the tool to configure and deploy applications.
This is a major change because:
- Bref now recommends Serverless instead of SAM
- the documentation has been rewritten around Serverless
- tooling has been added around Serverless
SAM will continue to work with Bref, just like CloudFormation, Terraform, Now (#368), etc. Bref layers are independent of the tooling used. If you have created applications with SAM, you can keep using it. Most of the time however migrating template.yaml to serverless.yml is not too complex (migrating a production stack may be more effort).
Why?
Serverless offers a configuration format (serverless.yml) that is much simpler and more concise (#320). Sometimes serverless.yml is twice less YAML than template.yaml for the same application. You can see an example of this with the configuration file for a simple HTTP application: https://gist.github.com/mnapoli/a9f690499160736a0a9f70e8492b1f5e
Another major simplification is that the stack name and the region are configured inside serverless.yml. Deploying no longer take 3 steps and 10 lines of code, but only 2 words.
On top of that, Serverless offers a plugin system that lets us simplify a lot of things, especially around Bref (#351). For example, using Bref layers is now much simpler:
# Before
functions:
foo:
handler: index.php
layers:
- 'arn:aws:lambda:us-east-1:209497400698:layer:php-73:7'
# After
functions:
foo:
handler: index.php
layers:
- ${bref:layer.php-73}Layer version numbers are now tied to a specific Bref version, and we no longer need to mess with the AWS region name. Upgrading layers is now as simple as upgrading Bref via Composer.
Additionally, serverless deploy can deploy the same application in multiple stages.
Finally, Serverless offers a lot of plugins to create more advanced applications: https://serverless.com/plugins/
Want to benefit all of that? All the bref.sh documentation has been rewritten and expanded to help you use Serverless. Give it a try!
Creating websites with Bref
A new documentation article has been created to help you create serverless websites with Bref. You can read it here: Creating websites with Bref.
Several architectures are suggested, depending on what you need:
This is great news as the Maturity Matrix has a more ratings going to green!
