Bref v3
This PR will contain all changes for Bref v3.
This will be a long-running PR, I like to keep this open for months so that we have a place to preview and discuss changes. I do not intend to merge this pull request soon.
This PR goes hand-in-hand with https://github.com/brefphp/aws-lambda-layers/pull/257.
Breaking changes:
- Dropped support for PHP 8.0 and 8.1
- Underlying Linux upgrade -> 99% of projects should not be impacted
- Deployment via containers: need to change because of https://github.com/brefphp/aws-lambda-layers/pull/256 (docs coming soon)
- The
pgsqlextension is now enabled by default - The small
brefCLI is removed, this was already stripped down with the v2 upgrade and could only set up new projects. That built-in CLI is no longer needed. It is replaced byserverlessCLI commands and thebrefexternal CLI (https://github.com/brefphp/cli).
All changes:
- https://github.com/brefphp/bref/pull/1988
- #1954
- https://github.com/brefphp/aws-lambda-layers/pull/256
- #1952
- https://github.com/brefphp/aws-lambda-layers/pull/262
- The
pgsqlextension is now enabled by default - Publish v3 layers to a separate AWS account (
873528684822) - https://github.com/brefphp/aws-lambda-layers/pull/122
- https://github.com/brefphp/aws-lambda-layers/pull/284
- Drop the
blackfireextension from "dev" container images - #2012
- https://github.com/brefphp/laravel-bridge/pull/190
- https://github.com/brefphp/bref/pull/2030
Ideas considered:
- Facilitate deploying container images based on anything (e.g. Debian/Ubuntu)
- https://github.com/brefphp/bref/issues/1661
TODO:
- [x] Update all documentation to point to
provided.al2023instead ofprovided.al2 - [ ] Document the migration to
provided.al2023in the upgrade guide
Do you have any ETA in mind for this?
Targeting end of November or early December hopefully. You can start using v3 right now, I have published the first alpha versions.
Hello @mnapoli , thank you for your work, I am using Bref since a while and working like a charm.
But, I am about to drop bref runtime (php files) and only keep base layers for the reason that I can't send the response BEFORE calling kernel.terminate and do some heavy work (my use case is mostly sending opentelemetry data for now). I am using the function runtime (way faster than fpm because of connection reuse) and symfony.
So I built a custom runtime for symfony + bref, doing some low level things I would prefer see in Bref :) Have you considered leveraging the symfony runtime for v3 ? I could help you and open a PR if you think it might be a good thing.
here is my http runner code, leveraging symfony runtime:
public function run(): int
{
$loops = 0;
$memoryLeakDetector = new MemoryLeakDetector();
while ($invocation = $this->apiClient->nextInvocation()) {
try {
if (is_string($invocation->event)) {
throw new Exception('Invalid event: ' . $invocation->event);
}
$request = RequestConverter::convert($invocation->event);
$response = $this->kernel->handle($request);
$lambdaResponse = ResponseConverter::convert($response);
} catch (Throwable $e) {
$invocation->signalFailure($e);
return 0;
}
$invocation->sendResponse($lambdaResponse);
if ($this->kernel instanceof TerminableInterface) {
$this->kernel->terminate($request, $response);
}
// Only check loop max if it's set and > 0
if ($this->loopMax > 0 && ++$loops > $this->loopMax) {
return 0;
}
// Boot kernel to prepare for next invocation (resets resettable services)
if ($this->kernel instanceof \Symfony\Component\HttpKernel\KernelInterface) {
$this->kernel->boot();
}
// Clear memory between invocations
gc_collect_cycles();
// Check for memory leak
if ($memoryLeakDetector->checkAndRecord()) {
return 0;
}
}
}
@jlabedo I think this already exists: https://bref.sh/docs/symfony/keep-alive right?
(PS: can you create a separate issue if this isn't it, to avoid cluttering the v3 PR)