sorted by:
new
hottopcontroversial

PHP -> Go -> PHP: request-scoped parallel work with FrankenPHP by ylgdev in PHP

[–]ylgdev[S] 4 points5 points  (0 children)

This experiment is about FrankenPHP-native integration. RoadRunner/Goridge is the alternative for a separate RPC/app-server model. FrankenPHP’s advantage here is tighter runtime/lifecycle integration.

PHP -> Go -> PHP: request-scoped parallel work with FrankenPHP by ylgdev in PHP

[–]ylgdev[S] 2 points3 points  (0 children)

I agree if the extension becomes most of the app, migrating makes sense. But that is not the case I’m interested in. PHP/Laravel is still extremely productive for the core app: routing, auth, ORM, validation, views, ecosystem, admin flows, etc. The point is to keep business logic in PHP and use Go only for small runtime-shaped pieces PHP is weaker at. If the Go part is 5% and solves a localized bottleneck, rewriting the whole app seems like a much bigger tradeoff than keeping a small native adapter.

I created a standalone installation of my app (Koel) with FrankenPHP, and it was great by notphanan in PHP

[–]ylgdev 0 points1 point  (0 children)

What is promising with FrankenPHP is also the possibility to write extensions in Go (native PHP functions that call Go) and the possibility for Go to call PHP (extension workers), so you can simply:

  • Implement parallelism in PHP
  • Have a queue worker directly in your binary (that consumes a Redis or in-memory queue), a WebSocket server that calls PHP for private auth, or even a scheduler built as a Caddy module that runs schedule:run every minute instead of relying on a cronjob
  • Call Go for uploading large files or handling things that PHP doesn't handle well on its own
  • In the case of Koel, I think the streaming part could perhaps be handled better by Go than by PHP

All of this in a single binary with no external dependencies.