ngx-php VS sqlc

Pasir is like frankenphp, but in Rust. Very promising, but still early in development:

https://github.com/el7cosmos/pasir

Which uses the following Zend API bindings for Rust:

https://github.com/davidcole1340/ext-php-rs

There's also all sorts of interesting experiments, like ngx-php, which basically embeds PHP via Zend API inside an nginx binary: https://github.com/rryqszq4/ngx-php

And workerman, which has a hybrid backend of asio libraries, so you can get pretty fast runtimes: https://github.com/walkor/workerman

Two questions:

1. Does Unit + PHP doing the typical “initialize & teardown” that PHP is know for?

Or is Unit persisting the initialization/setup, hence why it’s achieving the way faster results?

2. How is Unit/PHP architecturally different than NGX-PHP (an event loop)?

https://github.com/rryqszq4/ngx-php

I guess you referring to php-nginx which seems pretty niche.

SQLC is a modern marvel. It's not an ORM or a library; it's a code generator. You write raw SQL queries in .sql files, and sqlc generates fully type-safe, idiomatic Go code that you can call in your application.

I've been using the modernc driver for a few years in https://github.com/bbkane/enventory . It's worked perfectly with no drama. Combined with https://sqlc.dev/, I've been very happy writing (small) database applications in Go.

Speaking of Go, if you want compile-time type checking like what SQLx offers, the Go ecosystem has an option that is arguably even better at it:

https://sqlc.dev/

It has the advantage that it implements the parsing and type checking logic in pure Go, allowing it to import your migrations and infer the schema for type checking. With SQLx you need to have your database engine running at compile time during the proc macro execution with the schema already available. This makes SQLx kind of a non-starter for me, though I understand why nobody wants to do what sqlc does (it involves a lot of duplication that essentially reimplements database features.)

What would you use if ORM is to be avoided?

Perhaps something like https://github.com/sqlc-dev/sqlc ?

Next, let's write sql queries for retrieving our users & their permissions. Here we will use sqlc for type-safe code generation from our sql queries, and pgx as its backend

sqlc (https://sqlc.dev/) is amazing, but I needed to use it in several unsupported languages. So instead of creating a plugin for each of those languages, I created a generic one, which is based on go templates.

I really wanted to like sqlc, but it had some major limitations and minor annoyances last time I tried it a few months ago. You might want to go through its list of issues[1] before adopting it.

Things like no support for dynamic queries[2], one-to-many relationships[3], embedded CTEs[4], composite types[5], etc.

It might work fine if you only have simple needs, but if you ever want to do something slightly sophisticated, you'll have to fallback to the manual approach. It's partly understandable, though. It cannot realistically support every feature of every DBMS, and it's explicitly not an ORM. But I still decided to stick to the manual approach for everything, instead of wondering whether something is or isn't supported by sqlc.

[1]: https://github.com/sqlc-dev/sqlc/issues/

[2]: https://github.com/sqlc-dev/sqlc/issues/3414

[3]: https://github.com/sqlc-dev/sqlc/issues/3394

[4]: https://github.com/sqlc-dev/sqlc/issues/3128

[5]: https://github.com/sqlc-dev/sqlc/issues/2760