Show HN: Dumbo – Hono inspired framework for PHP

1) *magic* 2) Its ORM of choice uses ActiveRecord pattern which I find to be hideous. DataMapper is far superior 3) Its weird facade patterns is terrible

I can (and have!) gone in-depth into my misgivings with Laravel, but it is fine for most projects and teams. It has elevated the average codebase quality throughout the PHP community and introduced many engineers to what PHP can do. Its creator and community have been a large net-positive to PHP as a whole.

I still prefer Symfony:

1) explicit 2) DataMapper ORM by default 3) What I am used to

We started small. And prototyped with just a single feature.

Basically we generate code in our src folder under a reserved namespace, and other PHP code can then use that code with imports. As we grow, we might want to split this into separate compilation units (we are not there yet, as the Haxe compiler is really fast!)

At the moment the generated PHP code is checked in source control, again we might want to have this done in CI, but it works kind of nicely at the moment.

The tricky bits are how to "speak" to PHP. Haxe is a really nice functional language (even its syntax is traditionally class based, but you can have module level fields in Haxe since 2020), so its pretty annoying to handle option types etc from the PHP side. We are still not decided on this part, and many APIs expose duplicate functions for some general task, like foo and foo_exn, and the one that ends with _exn throws instead of returning a variant (like option/maybe etc)

Also, its tricky to design where data is fetched from. We tend to keep the Haxe code as pure as possible, and only taking input and returning output (not doing any IO). We also write our own typings for externals, this has actually been really good for us, as we can observe easily what we actually use, and if we can remove some dependency that has some one feature we only use.

Overall, im amazed not more PHP devs look into Haxe as its basically a better version of what is TypeScript > JavaScript. Also there is no other compile to PHP language im aware of that ha the same robustness and features Haxe has.

See my above comment for a semi detailed version of how we do things.

Symfony 7.2 can work as a micro framework, believe it or not: https://symfony.com/blog/new-in-symfony-7-2-simpler-single-f...

Can't go wrong with Slim: https://www.slimframework.com/

But if you're looking for something more modern and interesting, then Hyperf looks pretty cool. They have a mini-framework version you can check out: https://github.com/hyperf/nano

It does require Swoole, but that is a lot easier to get your hands on these days

When you say micro framework, what are you looking for? If you're just looking for a routing library then something like Symfony Flex might be what you want.

I find when I start a project I pretty quickly want to add an ORM, models, and maybe some middleware, and then I'm at a point where I might as well just use Laravel because it's fast enough and I know my way around.

Is FuelPHP or CodeIgniter still going? Those were my two favourites back in the day before Laravel came on the scene.

I can't comment on all the shortcomings and this may be reflective on my lack of experience with different implementations, but doesn't using GraphQL basically just enable a tonne of unoptimised database queries to occur that, at scale, could cause some serious load issues?

GraphQL has too many foot guns for your typical SMB to implement successfully, especially pivoting from REST. It requires you to architect your solution much further ahead than most companies have the capability to.

I prefer it over SOAP, but I think it's far too easy to ignore:

N+1 issues

Security (found that we had our entire schema open including internal data routes at my last job), also we had to refactor from patients being company -> patient to company -> pharmacy -> patient... that was fun

Overcomplicating resolvers

Not implementing pagination upfront

Dead end schema designs, since you need to plan much further ahead it really hurts when you mess it up. In REST you can make a V2 of a route and move on. Especially since many people ignore modules at first. Even large corporations get stuck with UserEntity_V2, updateUser_V2.

IMO if you are going "wow if only we had GraphQL" and your team only knows REST you are always better off improving your REST tooling and standards. For example, when adding a new entity/resource you can just plan to understand how your own teams intend to query for this data, rather than guessing with GraphQL or implementing every search pattern.

I think it looks cute

100% like every other framework. I'm primarily a JS dev, so it's in my nature to create yet another framework...

But seriously, this has been a tool for me to relearn PHP, and those contributing so far have also been learning PHP. If it ends up just bein (and nothing more than) something helps me, as well as others learn more about PHP, it's a success.

To be fair, there is technically concurrency. But it’s not what you would really expect. But as someone pointed out to me 14 years ago, if you need concurrency in your web request you‘re probably doing something wrong.

There is some very impressive work going on to define how Generics will work in PHP. It’s a matter of when not if Generics come to PHP. I‘m expecting a new RFC for Generics to be created some point next year.