FrankenDoc

[Nayte91]

Hello,
Not an issue, because how I messed with my issue on HTTP3, it's more about improving documentation and giving ideas.
I put some random stuff here as I need to free my mind:

HTTP3

• add to the doc what Kevin answered me about how the browsers usually handle http protocol:

browsers usually start with HTTP/2 and switch to HTTP/3 only if a Alt-Svc header exists, so be sure that the browser does extra requests (like downloading assets).

--> add a page about http3 by saying Caddy blabla... Find how to add link on left menu

• add on FrankenPHP-demo an example of an asset sent with earlyhint, an asset with preloaded http headers Link, and a normal one. Both for earlyhints tests, and to see HTTP3 triggers. --> Already a branch "feat/103-early-hints" on FrankenPHP-demo
• Tweak FrankenPHP-demo to open 443 UDP port, as it's needed to enable HTTP3 --> PR opened to change readme and add makefile

Early hints

• test what if 103 early hints sended resource (e.g. foo.css) is not in the DOM when final HTML's response comes?
• How to see early hints works on a browser? Add tips about chrome://net-export/ and Firefox debugging (never found how!) on FrankenDoc,
• does importmap specification allows this JSON to be earlyhint sent? If a browser receives importmap JSON like this, will it download keys and apply them to the subsequent HTML response?
• if so, add earlyhint sending for SF assetMapper component --> advertise about it in FrankenDoc
• if not, this is weird because they are 2 new features meant to improve browsers loading speed but they are fighting each other --> add importmap acceptance to 103 actual specification --> Created discussion around AssetMapper
• If both are needed, see on SF weblink component if can add 103 earlyhint sending feat to a preload() resource on twig side (note 103 hints are http2 compatible) --> add advertising on FrankenDoc
• I can't see any use case where fallbacking into HTTP Header link a earlyHinted resource isn't a good idea, unless duplicating 40Kb of 103's is a waste of bandwidth... And only in a controlled environment where only 103's compatible browsers are meant to connect. Can FrankenPHP manages adding programmatically the earlyHinted resource to Caddy's conf? In this case, maybe we can handle a list of "non contextual, always needed" resources, that will be cached by Symfony (in order to not wait for the controller to be triggered), then proposed to Caddy to 103's them, then fallback into HTTP Header's link.

Worker mode

• Can worker mode works on dev env to look at perfs? I think no, because worker mode "skips" the PHP compiletime and you need it when modifying files,
• When deploy in worker mode, you can't start worker, then composer install/make commands/ doing anything AFTER the start? Or maybe there is a feature to on/off switch the mode?
• If not, improve FrankenDoc on how to dev/test worker on dev for information purpose/deploy on prod (detailled steps with env variables FRANKENPHP_CONFIG & APP_RUNTIME, php ini conf GPCS/EGPCS, ...)
• Add details about GPCS/EGPCS config on FrankenDoc
• Can FrankenPHP automatically handle the GPCS/EGPCS variable? For example set it on worker/normal mode, but let it be overrided when user specify it in his php.ini?
• If this new mode is called "worker mode", how do we call the "fire & forget" mode? I feel like "compiler" and "runner" modes suit well, but I'm pretty sure it already exists normalized terms for this ("compiled"/"scripted", ...)
• When in worker mode with a SQLite database, would it be possible to set in memory mode, then after each request (code in the wrapper), save it on the file.db?
• Would it be relevant to "structure" the worker wrapper in a well known pattern setUp() (actual handle)/execute()/tearDown() (actual terminate) functions?

Misc

• Test perf boost on a Magento 2 project

That's all for now, I will check later what I can try locally/do on Doc side, as a lot of my points are testable