Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Dumbo – Hono inspired framework for PHP

github.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Show HN: Dumbo – Hono inspired framework for PHP

#61

Post by no_wizard »

bearjaws wrote: post #55
no_wizard wrote: post #5

Earlier quoted context omitted.

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

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 p…

All of these are developer issues and not issues with the technology. They aren’t inherent to GraphQL.

By your own admission it’s sloppy developer work that causes issues it’s not the tech.

REST APIs actually do have an inherent problem, which is they’re one call == one source. Everything has to be bespoke to the endpoint, where as GraphQL as a technology allows one to not have to do that.

Versioning APIs is a code smell. With GraphQL you can combine queries by using Fragments for example. You could also perform concurrent resolution with resolvers and merge data results if if it’s appropriate for the scenario to resolve a single query. There is far more flexibility in the model but you as a developer are 100% in charge of performance and such, no different than REST. GraphQL gives far more flexibility in finding a solution for any given scenario, where as REST is an extremely rigid 1 == 1 resource coupling.

As for pagination isn’t built into REST. Anything “standard” about that was bolted on and varies quite a lot. Where as GraphQL does address this[0] on an implementation reference level.

Regarding exposing schema, while I question if there is the security risk you're implying it to be (lots of organizations expose their GraphQL schemas, like Salesforce and GitHub) but never the less, any good implementation will have a single line option for turning it off. Apollo does (arguably the most popular of the implementations) but so does GraphQL Yoga and even implementations in other languages.

As far as developers go, the biggest mistake developers make is creating schema that is simply a clone of their database schema at the end of the day, and this is the absolute worst way to go about implementing GraphQL. Its explicit purpose is to have a middle layer that lets you express APIs for intended purpose, not to be coupled to your database schema

[0]: https://graphql.org/learn/pagination/

Re: Show HN: Dumbo – Hono inspired framework for PHP

#62

Post by toastercat »

shikck200 wrote: post #48

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 productivi…

This is really cool to hear as someone who used to experiment with Haxe for game development. Would love to read a case study.

Re: Show HN: Dumbo – Hono inspired framework for PHP

#63

Post by fourfour3 »

jtreminio wrote: post #58
mjrpes wrote: post #54

Earlier quoted context omitted.

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/

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 h…

I'll add on to this too, as someone who largely agrees!

I work for a company that has several mid-sized PHP projects. Some started life back with early PHP5 - eg 5.1.

The biggest reason I don't like slim frameworks is that they make every project unique.

Projects that start small rarely stay small, and if every project gets to pick it's own router, it's own method of doing CLI commands, it's own ORM, it's own messaging/queue stack, etc - then well intentioned decisions create a ton of variety in projects over time and it makes it very hard for people to jump from project to project. It also makes upgrades a mammoth task.

We tested Slim, Laravel & Symfony and settled on Symfony.

We found huge advantages in using a framework that can be installed piece-by-piece as you need it, but where the pieces are the same every time & consistently designed, and where the whole thing is designed to be upgraded in one go.

Going with Symfony has been a genuine productivity improvement for us - every project follows the same basic structure, we try to follow Symfony best practices, we try to minimise tons of external dependencies. It makes maintenance much much easier, and makes something like 'hey, we really should be processing this async in the background' an easy step - just install symfony/messenger, rather than evaluating different options, etc.

edit: we didn't go for Laravel because Eloquent really didn't compare well to Doctrine, and the amount of hard to debug 'magic' was much worse for us than Symfony.

Re: Show HN: Dumbo – Hono inspired framework for PHP

#64

Post by bearjaws »

no_wizard wrote: post #61
bearjaws wrote: post #55

Earlier quoted context omitted.

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 p…

All of these are developer issues and not issues with the technology. They aren’t inherent to GraphQL. By your own admission it’s sloppy developer work that causes issues it’s not the tech. REST APIs actually do have an inherent problem, which is they’re one call == one source. Everything has to be bespoke to the endpoint, where as GraphQL as a technology allows one to not have to do that. Versioning APIs is a code s…

All problems with all software are developer issues. Technically, we could do everything in Assembly, but we don't.

Ideally, a technology needs to solve as many problems as possible while introducing as few problems as possible. That is why I am not sure every organization should use GraphQL.

If someone came to me from an SMB and asked "should we switch to GraphQL" I would first ask what problems they have, and what they believe GraphQL will solve. Then make an informed decision, the answer is not "yes, you should always use GraphQL".

Re: Show HN: Dumbo – Hono inspired framework for PHP

#65

Post by no_wizard »

bearjaws wrote: post #64
no_wizard wrote: post #61

Earlier quoted context omitted.

All of these are developer issues and not issues with the technology. They aren’t inherent to GraphQL. By your own admission it’s sloppy developer work that causes issues it’s not the tech. REST APIs actually do have an inherent problem, which is they’re one call == one source. Everything has to be bespoke to the endpoint, where as GraphQL as a technology allows one to not have to do that. Versioning APIs is a code s…

All problems with all software are developer issues. Technically, we could do everything in Assembly, but we don't. Ideally, a technology needs to solve as many problems as possible while introducing as few problems as possible. That is why I am not sure every organization should use GraphQL. If someone came to me from an SMB and asked "should we switch to GraphQL" I would first ask what problems they have, and what…

That wasn't the question as posed though. It was 'regarding its technical basis, what issue does GraphQL have?' and rarely do I ever get an actual technical problem with how graphql is structured.

REST has at least 1 inherent flaw in its model, which is 1-1 API resource coupling.

Now, if we want to talk about perhaps skill threshold? Yeah, GraphQL requires a higher level of confidence and experience to use correctly.

Re: Show HN: Dumbo – Hono inspired framework for PHP

#66

Post by shikck200 »

toastercat wrote: post #62
shikck200 wrote: post #48

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 productivi…

This is really cool to hear as someone who used to experiment with Haxe for game development. Would love to read a case study.

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.

Re: Show HN: Dumbo – Hono inspired framework for PHP

#67

Post by shikck200 »

gr4vityWall wrote: post #56
shikck200 wrote: post #48

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 productivi…

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?

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

Re: Show HN: Dumbo – Hono inspired framework for PHP

#68

Post by endofreach »

crowcroft wrote: post #10

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/

While it's indeed too much boilerplate necessary for good DI, just the first paragraph sounds insane to me: "Tempest features a unique concept called discovery. Tempest will scan your code and find out what to do with it: from controller routes to event handlers, from console commands to dependency initializers; Tempest will detect everything without you having to write a single line of configuration or bootstrap code."

Re: Show HN: Dumbo – Hono inspired framework for PHP

#69

Post by endofreach »

dzonga wrote: post #2

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.

"The market" = facebook. It shouldn't be a surprise.

Re: Show HN: Dumbo – Hono inspired framework for PHP

#70

Post by endofreach »

no_wizard wrote: post #18
ITB wrote: post #12

Earlier quoted context omitted.

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.

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.

> GraphQL makes no mention of databases. It’s a resource agnostic protocol.

So the QueryLanguage is just marketing?

Post reply on HN