Bref: RFC: Direction of the project from 0.3 onwards

[nealio82]

As a user of bref and advocate of serverless PHP, I'm very excited about the recent Lambda changes and what it can mean for the project.

It looks like we're gaining traction (a few people in the UK Symfony Slack channel have been coming to me with support requests, I've been working on presentations, there seems to be a bit of a conversation about it happening around Twitter, etc). I imagine there's been similar happening in other framework communities and / or countries.

I was wondering what @mnapoli's vision for the project is (both short-term and longer-term), so the rest of us can get on-board and contribute where we can while @mnapoli is busy with the nitty-gritty).

Is there a current snagging list / wishlist of 0.3 issues anywhere which we can work against and avoid duplicating effort? Do we have a target release date for 0.3, or will it just happen as it happens? Considering that it's such a major breaking change, should it actually be considered to be 1.0.0!?

I'd love to see us be able to establish bref as a leading open-source solution to attaining easy serverless PHP, but I just don't know if my ideas on where to get started are the same as anyone else's!

I think we probably need (typing as things come to me - apologies if any of these already exist):

• bref deploy to work out of the box as it did before, (including building / deploying the runtime?)
• less bootstrapping (I think @mnapoli has already done a load of work on this, judging by #113 !)
• full documentation (I'm thinking of something like https://readthedocs.org/, or a full website like https://api-platform.com)
• all of the available global / environment vars to be available to the application code (Symfony sometimes has some Request parameters missing, for example)
• a repository of runtimes (just make some publicly accessible on S3..?) so beginners / tinkerers don't have to worry about building PHP themselves
• a plan of action for things we want to include / not include for the next release
• a team / project goal
• a really cool logo 😜

[bubba-h57]

We have also been leveraging serverless PHP in AWS Lambda for the past two years. We are a Laravel shop and we, as a company, would love to both contribute tobref as well as see it become _a leading open-source solution to attaining easy serverless PHP._

My management has encouraged me to invest company time pursuing this, and I must admit that I have a personal passion for it as well. We have services running on PHP, Nodejs, and Python in Lambda today that I would dearly love to refactor into a single Laravel service of Lambda's, not to mention the planned services that we are willing to hold off on for few weeks while we get bref to a stability that we are comfortable with in production.

I plan to continue contributing to the benchmarking, and to fold in Laravel testing alongside the Symfony tests. Whatever else I can to do help move things forward, please let me know.

[mnapoli]

Right thanks for opening this issue, this is all great we can have so many people involved!

Here is how I see things, let me know what you think.

Why

Serverless is about getting more things done by doing less, especially less ops. PHP has always been about getting things done. The mix of those two things is amazing for businesses and tech teams.

I believe Bref should empower PHP developers to take advantage of serverless approaches, ultimately to empower people to get things done :)

What

The "Why" helps figuring out "what to do", for example:

• as simple as possible (e.g. single command deployment, etc.)
• keep things as familiar as possible when it makes sense: if I use Symfony/Laravel/etc. it should work like I am used to (unless there's an underlying fundamental change that I need to understand)
• explain: I believe documentation and case studies will be key! people should be empowered and feel confident to use serverless, which is definitely not the case at the moment
• guide the transition to serverless: serverless will probably change how we write applications over time. We should not hide fundamental changes in architecture. Instead we should make them simple to understand and use (with tools and/or documentation). Things that come into mind: IAM roles, queue workers, readonly filesystem, sessions, serverless databases, use of AWS events to orchestrate the application flow, etc.
• allow to build on top of it: empower people to create even better tools (or more specialized tools)

but also "what not to do":

• everything: a project starts to die the moment it tries to do everything. We should create opportunities for people to build awesome stuff, not build everything for them and lock them in with half-backed solutions
• reinvent new PHP frameworks: people will not get things done if they have to learn something new from scratch again
• reinvent existing tools (e.g. for deployment, provisioning, etc.) when those exist and work well (thinking of AWS SAM/serverless, Docker images in SAM, etc.)
• lock users into "Bref's" solution and close it to external tools
• make it perfect from the start: I want it to be useful right now -> maybe that means documenting what is supported and what isn't? (like what we do with PHP extensions for example)

How

Now this is more concrete, here is what I have in mind for v0.3 for now:

• provide PHP runtimes for CLI (workers, cron, etc.) and HTTP applications
  
  
  
  • @nealio82 yes I definitely want to provide public runtimes so that people get started straight away
  
  
  • I said this before but some might be reading this for the first time: great performance improvements because of this
  
  
• thanks to the HTTP/PHP-FPM runtime: provide support for any PHP application (not be restricted to PSR-7 and Symfony/Laravel)
• AWS SAM for:
  
  
  
  • automated deployments of Lambda functions and resources (db, queues, cdn, etc.)
  
  
  • local development environment (reproduces the prod environment using Docker automatically)
  
  
  • integration to AWS services (e.g. CodeDeploy/CodePipeline for automated deployments & advanced deployment strategies)
  
  
• a kickass website and documentation that I want to rewrite from scratch

@nealio82 you mentioned the following points that I did not mention above:

• all of the available global / environment vars to be available to the application code (Symfony sometimes has some Request parameters missing, for example)

That's a good point and I think using PHP-FPM will definitely help for this. I just finished writing a truckload of tests for that. But I want to stress that getting it perfect is not my priority right now. I want to get 0.3 out of the door so that people can use it (including me) and improve it. However I welcome any help to make things super solid, tested and cover all the edge cases.

This applies to basically everything in Bref: I will rely on contributions to get from "working" to "perfect" :) (also this is why I'm fine waiting a few months before tagging a v1, it may be more explicit)

• a repository of runtimes (just make some publicly accessible on S3..?) so beginners / tinkerers don't have to worry about building PHP themselves

Yes, I want people to get started instantly. Building your own runtime is possible though, but hopefully won't be necessary. If you think it is let me know (I may have a few ideas about this).

a really cool logo 😜

That could definitely happen with the website :)

To get started I can create issues in a milestone or a project board?

And sorry for the wall of text, comments welcome!

[nealio82]

To get started I can create issues in a milestone or a project board?

Yes, this! I want to help out when time allows but don't know what's highest priority, what's already being done, etc. I feel like I've missed a lot of the recent enhancements on the 0.3 branch and will need to spend some time getting back up to speed again! At the very least a project board or tagged issues will give some context to what's going on and help us re-group :)

[mnapoli]

OK I've created a board to plan v0.3: https://github.com/mnapoli/bref/projects/2

Here is what we can do to take advantage of everyone's time:

• 1st step is creating a first version of the runtimes (without that we can't do much) -> I'm working on this
• 2nd step will be testing it out with AWS SAM, report issues and validate whether SAM is the right choice => this is where everyone comes in

From there we can all work in parallel:

• report and fix issues
• improve the runtimes (automation, edge cases, performances, etc.)
• Bref CLI (deploy, init, etc.)
• documentation and website

I'm focusing on the runtimes right now. Once that's done I'll open an issue where we can exchange instructions and tips on how to test them with SAM. This is where we'll need everyone.

I'll keep you posted!

[mnapoli]

Okay I built first versions of the runtimes and opened an issue to track testing: #116.

I invite all of those wanting to help to head over there and subscribe.

Open issues, comment #99 about what you think of SAM too.

[mnapoli]

The v0.3 board is kept up to date, the new version is taking shape :) I'll close this.