Show HN: PHP API Bindings for Open Brewery DB | Hacker News Reader

Show HN: PHP API Bindings for Open Brewery DB

github.com

50 pointsjoeymckenzie39 comments

Howdy! I'm a recent PHP convert after a decade of laughing at PHP memes on r/programmerhumor, and wanted to dive a bit deeper into the language by building something practical with it. I also love beer and decided to combine the two by building a PHP library for the Open Brewery DB API (https://openbrewerydb.org/). Hope someone finds it useful!

Open articleView on HN

I work extensively in PHP, am rather fond of it, and have built out quite a lot of tooling in the language. The reputation it has from the early 00s is quite mismatched against its current capabilities and I'm glad to see more people picking it up. The API you've put together is modern and follows a lot of the best practices so thanks for your hard work!

I don't think it's capabilities were ever in doubt -- it had early adoption because it had capabilities that other languages didn't have/express well, not because it was a particularly nice language to work with.

The OPs code is quite readable and I wouldn't mind maintaining it (vastly better than the real-world legacy PHP code I have to maintain), but my main takeaway is "this is like Python with Java syntax" (interestingly the opposite of Kotlin, i.e. Java with Python syntax).

Appreciate the feedback!

I'll be the first to admit I have a tendency to C#/Java-ify code in languages that I attempt to learn (could definitely argue it's a bad habit) due to nearly a decade of working with them. Any advice you might have to make things a bit more idiomatic to modern PHP? Always looking to improve the code however I can.

It's my opinion (but one I strongly hold) that good maintainable code is modularized and clean - with strict types and a heavy emphasis on clean contracts between different components (since in an organization/large open source project many people will be contributing in parallel). It relies heavily on common patterns and styling for easy recognition and tries to do things in the least sneaky way possible.

If you're aiming for this state of a codebase you'll lean heavily towards Object/Modular oriented styles which strongly resemble Java/C++ etc - even languages that express them in dramatically different manners (like OCaML) end up looking really familiar when built in a sustainable manner. There is a common visual expectation we have around code that promotes readability[1] and we'll form code in most languages to match that common visual expression. This is actually one reason I decidedly dislike python - since it's visual expression is encoded into the syntax evaluation of the language itself.

Anyways the TL;DR is that, IMO, clean maintainable code looks like clean maintainable code and the language only minorly impacts this appearance.

1. That isn't to say this is necessarily the best visual expression - it could just have been chosen early on and then just ingrained in us all.

I completely disagree with this. The classic Java-style "enterprise OOP" code is a symptom of poor software design and papering over bad abstractions with more abstractions.

There's a lot of this code also written in Python. However, I think Python's forced indentation and cleaner syntax is a boon because it makes bad code look bad and unreadable. Too often, variations in style conventions are used as a smokescreen for rubbish software.

Thank you! I've found modern PHP to be quite a joy to work with, given how much it gets dunked on in the greater tech community. It has some awesome tooling that's on par with other the languages/ecosystems I work in, and I'm always looking for a reason to write more it now.

I run and pub and brewery in the east of England that was established in 1991. We have lots of breweries around here and none of them seem to be on openbrewerydb. I have joined the Discord and will see if I can contribute some info.

I look forward to adding it to the dataset. Cheers, euoia!

As a Suffolk resident, can I ask which one?

Green Dragon in Bungay, pop in and say hello some time

Will do. I’m further South but up that way occasionally for raw milk!

Hey OP I don't think I've seen this mentioned yet, but one important thing to consider is the collection of PSRs (PHP Standard Recommendations), several of which are around HTTP clients.

This is an important component to decoupling packages from specific underlying implementations like Guzzle.

You can even use the auto-discovery package to have whichever conforming HTTP client is installed (like Guzzle for example) be utilized, or allow via dependency injection an existing HTTP client to be passed in.

This would be a great enhancement since the PHP community has done a great job with these shared standards, it is a common expectation across packages to utilize them.

This is an excellent idea. I assume you're referring specifically to [PSR-18](https://www.php-fig.org/psr/psr-18/)? I wasn't aware of those PSRs around the HTTP client implementations, just digging into them now. I've got my Saturday morning reading covered!

Heck yeah, more PHP things here please!

Check OpenBreweryClient.php for comment rot, e.g. references to Blizzard and ‘game’ APIs.

Thanks for pointing that out. Definitely some leftover copy/pasta from another learning library I was writing for PHP. Updated!

Welcome to PHP! :)

Glad to have you join the community!

This looks great!

Is there an open database of beers/ratings similar to Untappd? Bar/brewery owners I know hate Untappd because of the exorbitant fees they charge.

None that I'm personally aware of, Open Brewery DB seems to be most complete dataset of breweries I've found out in the wild so far though just for breweries.

I'm curious, what made you decide to use final classes and private properties in your Client class? I'd recommend taking a look at https://ocramius.github.io/blog/when-to-declare-classes-fina... if you haven't seen it before.

I'm not sure that this is the right use of the term "binding". Maybe more of an SDK?

Probably. I tend to use both interchangeably, though probably incorrectly. I think either could describe the use case here, in the sense the library is binding to the API for Open Brewery DB. SDK could fit the bill here, and that's ultimately the hope if I get it to a place where it would be the "official" way to use the API via PHP.

modern PHP has become indistinguishable from Java, which begs a question: why PHP, when Python is less verbose, if you want less verbosity and scripting.

and Java is same verbosity + has more mature (and arguably more performant) runtime + benefits of statically compiled language and rich library ecosystem?

what is selling point of PHP, that python and java don't fit into ?? (lets not even mention javascript/node with its runtime)

I can think of many reasons, but for starters (obviously focused on web dev): - pythons dependency management is insane. For PHP Composer seems a bit aged, but compared to all others i've had to work with in the last decade, it's still the best to work with

- the PSRs are pretty good & make the whole language seem like a good big framework

- php can actually be very fast nowadays

- decent type system (if you're unlike me any don't hate working with annotations, you'll be even happier)

- since php8 (especially 8.1 and 8.2) there were a lot of major new things (property promotion, named parameters)

On the contrary: - php.ini must die. It's not causing much issues for me anymore, but it just doesn't feel right.

I don't know why, but no matter how much i work in other languages, even if i really enjoy them (eg. go), nothing when starting from scratch for web server stuff, i always end up going with PHP. Whenever it's "just web" on the serverside, nothing beats php. Especially when you ignore the bad stuff and look at really well designed modern projects based on php8.

I just think it might be time to fork php8, start with a new name & get rid of all the old, dirty stuff that's still there for some weird & non-realistic backward compatibility.

If anyone is up for that task, i am happy to help & finance parts of that.

I agree with a lot of your comment, but what's wrong according to you with php.ini? I've always found it a really handy way to customise the behaviour of my php installs and apps, and I've actually learnt a fair bit from just reading through the comments and following the links it contains.

Actually, i can't say what i would propose as a better way without having to spend some time thinking. While i was expanding on my php.ini mini-rant, i realized that i wouldn't be able to answer a question like yours.

I just seem to be hater for no valid reason other than very personal things like: - hating the ini syntax - issues with module conflicts - how the overloading works

Might be my experience of annoyances when i didn't know the issues might be related to php.ini settings. And (still today), i only find out after googling issues like a moron.

I just have the feeling another solution might offer much better dev experience. But yeah, i can't offer any helpful insight here. Maybe it's just that i don't want to have to initialize at all, given that the PHP we talk about is not the one running on funny hardware, but rather purposefully configured servers anyway. But yeah, not sure what a better alternative would be right now without digging in to it.

You seem to be emphasizing syntax rather than features of the languages and the stack itself. PHP was designed from the ground up for the backend side of web. Python, JS and Java were not. Many fundamental web development features are built into PHP like sessions, cookies, HTTP request variables, while a language interface server like Gunicorn or runtime like node is required to generate much of that from the incoming request and forward it to your application. Once it gets to your application either you or a library then needs to track those cookies, sessions, etc.. That's all built into PHP. So instead of a call sequence for a python/node app being request -> nginx -> Gunicorn -> python app, with PHP it's just request -> nginx/apache -> php app. There are plenty of other web-specific features that are dead simple in PHP like header redirects and HTML templating, whereas with python/node/java they have to be implemented by you, your framework or a language interface server.

I like index.php type websites, that are not verbose.

but PHP code that consists of 30+ composers modules, each with 10+ classes with overengineered OOP crap does not encourage me to touch this code with a 10ft pole.

This has devolved into js type of crappy coding, and I can use JS for that, dont need PHP.

I'm not exactly sure what you're suggesting, but blaming sloppy codebases you've seen is an unfair, cheap shot at the language instead of calling out bad developers, which applies to every language. PHP is inherently less complex than languages like JS and python for the backend and results in fewer dependencies because it comes with more features specific to web development out of the box. Quite literally no features required to build even a very basic dynamic website come with JS out of the box: sessions, password hashing, database connectors, input sanitizing, cookies, html templating, etc... It all needs to be either written by you or installed as a dependency. They're all standard features in PHP.

Modern PHP isn’t necessarily verbose. It’s only when the authors choose to go that route.

I've written plenty of PHP, mostly out of necessity, but I find the language to be hideous. It's like they took only the worst parts of other languages and piled it all in to one full of `$` and `->` for no good reason. I've been a Ruby programmer for the last 15 years, but I spent 6 years writing lots of MFC flavored C++ and Java and I honestly can't fathom why given the opportunity to improve the language starting around PHP 5 they made the choices they did. It's like they saw good things other languages had and just did lazy imitations with the worst possible syntax. Composer is a half assed copy of Bundler and I still can't believe that a global php.ini is a thing.

Reply on news.ycombinator.com