[HN Gopher] Show HN: Dumbo - Hono inspired framework for PHP
___________________________________________________________________
Show HN: Dumbo - Hono inspired framework for PHP
Hey HN, I last PHP professionally over 15 years ago, and I loved
it. I switched to Ruby on Rails, then Node/Go/React/GraphQL as
there was a lot more demand for those roles. However, PHP is back!
In true JavaScript fashion, I decided to learn PHP again by
building a framework to put all the pieces together in my brain. I
absolutely love Hono.dev, and decided to base the PHP framework on
that. Dumbo isn't intended to compete with Laravel, Symphony or
Slim, if anything, it's something people can use in production, but
also contribute to and be used as a learning resource for others.
Author : notrab
Score : 66 points
Date : 2024-11-18 07:37 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dzonga wrote:
| I wish the market didn't determine the technologies we get to
| work with. because at times the market can be wrong due to
| incentives.
|
| e.g the market was wrong on graphQL.
|
| btw Hono is cool, but found the api surface area insufficient for
| my node.js usecases.
| no_wizard wrote:
| How was the market objectively wrong on GraphQL?
|
| I ask a a REST turned GraphQL advocate to be clear but
| criticisms I hear tend to be opinions or issues with specific
| implementations but not ones based on the technical
| shortcomings of the technology
| davzie wrote:
| 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?
| no_wizard wrote:
| GraphQL says nothing about databases at all. Resolvers can
| get resources from anything, they're agnostic.
|
| None of that is inherent to the technology but it's a
| common folly among developers. This is an issue with REST
| too but it can be more obfuscated
| ITB wrote:
| If a certain arrangement makes it more likely to write
| bad queries, and it requires extra care to write optimal
| queries, then it's a worse interface to a database. I bet
| for really database intensive applications graphQL adds
| more work than it saves.
| no_wizard wrote:
| It's not though. Especially since GraphQL makes no
| mention of databases. It's a resource agnostic protocol.
|
| This isn't a technical issue with GraphQL. It's a culture
| issue among developers who shoehorn GraphQL and don't use
| it appropriately
|
| As someone who works on very database intense application
| GraphQL saves me more work than its ever caused.
| jayknight wrote:
| Any chance you can point to a good graphql
| implementation/framework that someone could use to learn
| best practices?
| no_wizard wrote:
| You're talking about the implementation of the protocol,
| right?
|
| That is a good implementation of it, called GraphQL
| Yoga[0]
|
| However I'm concerned there is a slight disconnect here.
| I'm saying that the technical specification of GraphQL
| does not lend itself to being bad, rather its the failure
| of developers to really understand its purpose and what
| its for (its a giant aggregator, with various ways to
| optimally aggregate things together, depending on what is
| optimal for a given problem set)
|
| For that, I recommend becoming more familiar with the
| specification itself[1] because thats what I'm talking
| about. The specification (and thus its technical nature)
| doesn't prescribe anything regarding how you get data on
| to the graph. Many people equate GraphQL with database
| problems[2]
|
| This doesn't mean I don't understand that GraphQL has
| shortcomings, but all approaches to APIs have short
| comings. I have found GraphQL has the least amount
|
| [0]: https://github.com/dotansimha/graphql-yoga
|
| [1]: https://spec.graphql.org
|
| [2]: Common complaint I see all the time. I find it stems
| from a failure to understand how the entirety of GraphQL
| is meant to work, and some of the mechanics within. Like
| when to appropriately leverage DataLoader[3], for
| instance.
|
| [3]: https://github.com/graphql/dataloader
| bearjaws wrote:
| 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.
| wink wrote:
| What's your distinguishing point over Slim and Silex (rip)
| because from your example script I don't see anything different.
| I mean, how would it, (un?)fortunately PHP syntax doesn't let you
| play as much with DSLs as Ruby or other languages.
| notrab wrote:
| I guess that's still to figure out... it's mostly been an
| experiment to relearn PHP... I guess keeping a similar DX to
| Hono's context->X is where I was coming from originally.
| oldandboring wrote:
| This is what I was thinking as well. From the README examples
| it looks like every other modern PHP micro framework.
| notrab wrote:
| 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.
| WORMS_EAT_WORMS wrote:
| Honestly beautifully designed. Really lives up to Hono name
| notrab wrote:
| Hono is to credit for the design, really nice!
| crowcroft wrote:
| I don't see myself ever using anything other than Laravel, but
| love these kinds of projects just to see what new ideas they
| might spark for the wider PHP community. Also interested in
| https://tempestphp.com/
| notrab wrote:
| That looks awesome!
| racl101 wrote:
| I was about to start looking for a PHP micro framework. I wish
| Lumen was still supported.
| notrab wrote:
| Is FuelPHP or CodeIgniter still going? Those were my two
| favourites back in the day before Laravel came on the scene.
| crowcroft wrote:
| I don't think Fuel is at all, and CodeIgniter is... but not
| really?
|
| IMO Laravel is kind of the spiritual successor to
| CodeIgniter, although of course a lot has changed between
| V1 and V11
| notrab wrote:
| True true. I went back and forth so much in the early
| days of CodeIgniter, Rails, Fuel and Cake.
|
| Eventually discovered just building stuff was going to
| bring me the most joy, no matter the tool. It's been a
| joy learning PHP again though, even if I do suck at it
| right now.
| leftnode wrote:
| 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...
| gregoriol wrote:
| They say it "can" but it is not first class in their docs
| or minds, so it's mostly up to you to figure out how to do
| most of things then. It would be better to have an
| independent micro framework with a clear scope of what it
| can and cannot do compared to the full Symfony stack.
| crowcroft wrote:
| 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.
| james2doyle wrote:
| 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
| basilgohar wrote:
| If nothing else, I love the logo. A hyper-realistic take on the
| ElePHPhant [0].
|
| [0] https://www.elephpant.com/
| gagik_co wrote:
| There is definitely a discussion like this under every repo at
| this point but I genuinely do not understand why people feel
| the need to have AI art for their GitHub projects. It's
| subjective but it just looks tacky and cheap, as is nearly
| always case with AI art. Some online, non-AI logo generator
| that slaps a generic royalty free icon with a font would be
| miles better, or honestly even dropping it altogether and just
| having a header.
| notrab wrote:
| I think it looks cute
| jtreminio wrote:
| You're requiring PHP 8.3 but not using some of the most powerful
| tools in 7+: strict types.
|
| ``` /* @var array<string, mixed> Variables stored in the context
| */ private $variables = []; ```
|
| This should be typed as `array` (heck, I'd argue ArrayObject
| instead) and all your classes should have
| `declare(strict_types=1);` at the top.
|
| Your `Dumbo\Helpers` classes are basically static mine traps that
| you are unable to mock in unit tests. Why does `BasicAuth` expose
| a single static method but then calls a bunch of other static
| methods? What ends up happening in any class that uses any of
| your `Dumbo\Helpers` classes will always run whatever code is
| defined in these helper classes.
|
| I'm unsure where the bootstrapping process begins. What file does
| your webserver need to call to handle a new request? I am hoping
| it is within a root-level directory and not at the root level
| itself. In other words, `/public/index.php` vs `/index.php`. Your
| quickstart in README.MD makes it pretty clear that you expect the
| latter, which is highly unsafe. See any number of poorly
| configured webservers that stop processing PHP for any reason but
| now show your site's full contents to anyone passing by.
|
| I would strongly argue against _any_ magic in your framework.
| Specifically, routes: they should be explicitly defined. I still
| work with a legacy Symfony 1 framework project and I can't tell
| you how much I detest magic routing. For a modern example see how
| Symfony 2+ requires explicit route definition. Heck, how it
| requires explicit everything because magic should be left to
| magicians.
|
| Your framework seems like it can only handle `application/json`
| and `application/x-www-form-urlencoded` requests, but not
| `multipart/form-data`.
|
| Take these as positive criticisms of your work. It's "fine". I
| wouldn't use it, I would actively recommend against using it, but
| I would actively recommend against using anything that's not
| Symfony (or Laravel if I were drunk). I do not think your project
| is at the "Show HN" level - it is still far too under-developed.
| notrab wrote:
| Appreciate the feedback, I'll work on it. I have lots to learn
| it seems!
| thinkingtoilet wrote:
| Out of curiosity, what do you dislike so much about Laravel?
| jtreminio wrote:
| 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
| thinkingtoilet wrote:
| Makes sense. I agree on the ORM. I actively don't use
| Eloquent when I use Laravel. It's fine for simple actions
| but I find it can get in the way as the project grows more
| complex. Thanks for sharing.
| gregoriol wrote:
| Symfony has a huge lot of magic (text/non-typed config
| files, factory/abstract bloats, ...), and even dark magic
| (compilation passes, ...), but it's better than Laravel in
| many ways indeed.
|
| A simpler framework with modern techniques would be great
| though.
| lofaszvanitt wrote:
| Too much angst about non standards and preferences.
| Everyone codes the way they feel comfortable and decides
| what to implement because the more mumbojumbo pattern magic
| included the more complexity you introduce to your
| codebase. And the development time skyrockets.
|
| Just because someone wrote a book about patterns, it
| doesn't mean it's the high standard and the holy bible by
| any means. These people are mostly control freaks, who like
| to exert control on people and think their excrement is
| akin to a lump of gold.
|
| And then there are the preachers - like you - who
| disseminate the bullshit these pattern monkeys rant day and
| night.
| dotancohen wrote:
| We are in agreement about Laravel's ORM, but I disagree
| about the magic. Laravel's "magic" is just convention over
| configuration, and most things can be configured as well.
| larsnystrom wrote:
| But really, who thought mixins was a good idea? It's the
| only place in the wild I've seen somebody bind $this when
| calling closures.
| mjrpes wrote:
| What do you think of Slim Framework as far as best
| practices for modern PHP in a micro framework (which is
| similar to OP's Dumbo)? Are there any other micro
| frameworks you recommend?
|
| https://www.slimframework.com/
| jtreminio wrote:
| At the risk of being piled on by fans of Slim (see fans
| of Laravel), I don't use slim frameworks.
|
| For large projects when you get down to it, slim
| frameworks are simply frameworks where you have to add in
| components yourself, vs shipping with sane defaults.
|
| Symfony comes with Doctrine, Twig, etc, but you can
| choose not to use them or even include them.
|
| With slim frameworks if they are built correctly they
| will have hooks to add these components but you have to
| choose them and import them and set them up.
|
| I have not worked on a small project in years, and have
| not bothered looking at slim frameworks in as much time,
| so my knowledge might be out of date ... but a quick
| glance through Slim's documentation tells me I'm still
| fairly close.
| eterps wrote:
| Are there any frameworks other programming languages (besides
| this one) that are directly inspired by Hono?
| campak wrote:
| Small world! Congrats on getting up there on Hacker News, too!
| notrab wrote:
| Thanks Campak!
| avinassh wrote:
| perfect. beautifully designed. I will try this for my next side
| project.
| notrab wrote:
| Yay PHP! Let me know how you get on
| pftg wrote:
| Yeah, I believe Sinatra https://sinatrarb.com/ or Padrino
| https://padrinorb.com/ inspired Hono. So you are back to Ruby ;)
| notrab wrote:
| Sinatra is beautiful!
| cies wrote:
| I've went through a similar journey, with some PHP in the early
| days, then a lot of Merb/Rack/RoR experience. Though I'd not say
| PHP is back. I'd avoid it for new projects as there are --IMHO--
| much better languages available for free.
|
| What I really liked from webdevt in Ruby was Rack.
| https://github.com/rack/rack (gosh I prefer the simplicity of the
| old logo)
|
| And I found a Rack-like architecture in "http4k"
| https://www.http4k.org
|
| In a way Kotlin can be looked at as a "typed Ruby". Sure Ruby now
| has optional types, but I believe it's not something easily
| bolted on later. The whole lang + stdlib should be built in an
| idiomatic way. Changing the language a lot later usually creates
| a mess in the stdlib.
|
| The framework http4k delivers is very similar Hono/Dumbo, but it
| has a Rack built in as well. Also, http4k is make by functional
| programming enthusiasts. So it clearly separates logic and data.
|
| Small request: Please make Hono clickable in the README!
| shikck200 wrote:
| We actually target a HUGE legacy PHP codebase (its over 16 years
| old, with over 1M LOC) with Haxe. I would not EVER write vanilla
| PHP for anything else than a toy website, because there is no
| amount of testing that makes it stable enough.
|
| We still have a lots of legacy PHP, but its slowly being
| refactored to Haxe. With Haxe we get a really nice typesystem,
| and a "faster than Go" compiler. It has pushed our productivity
| thru the roof.
|
| We still need to use external dependencies tho, as PHP lacks any
| concurrency in the core language, so we also have a Go API for
| fetching data concurrently, and also use it as a BI directional
| socket for the frontend and as a queue server.
|
| Otherwise, the stack is pretty much PHP7 from top to bottom.
| gr4vityWall wrote:
| Very interesting to hear about the Haxe PHP target being used
| like that. How did you start introducing it to the codebase?
| Were there any devs familiar with Haxe in the company already?
___________________________________________________________________
(page generated 2024-11-19 23:02 UTC)