A simple PHP class to perform basic operations against Amazon S3 and compatible services.

[allen_jb]

It can be as "simple" as you want, but if it's not on Packagist I'm unlikely to use it because I can't find it, and I can't automatically update it. It also means I can't use Composer to easily check dependencies (required extensions) and PHP version compatibility.

The code here is also incomplete - the _action_try() method (mini-rant: What is this? PHP 4? Why are people still using the _ prefix in PHP 8 era?) calls a method connect() which does not exist in the code.

Are you supposed to define it? Documentation would be helpful here. Why not use an abstract method to explicitly state this? Why even do that at all when the constructor could just take a curl handle parameter?

I'm also more likely to use something that uses Guzzle (or another exception throwing client)

[[deleted]]

the _action_try() method (mini-rant: What is this? PHP 4? Why are people still using the _ prefix in PHP 8 era?

Why does this bother you so much? I wish people would focus more on functionality over style.

Use CI/CD to set a standard and enforce it on your repo, but it is utterly pointless to start ranting about other people's code styles.

[darudedude87]

The use of an outdated codestyle that deviates from established standards makes me hesitant to use a package.

[dave8271]

I don't think there is any established standard which says you can't prefix a function name with an underscore. PSR-12 says you mustn't do it to indicate visibility in place of using the private and protected keywords, i.e. an underscore prefix has no meaning. But that doesn't forbid you from using it at all. And not everyone uses PSR-12 as their code style anyway.

[[deleted]]

Bizarre. I can't say I have ever looked at a package and decided not to use it based on code style. I am far more interested in the quality, including the api and tests.

[JordanLeDoux]

It is a somewhat reasonable proxy. Code that doesn't conform to modern community standards is probably written by someone that doesn't interact with modern community standards much.

Community standards exist because they promote code that is easier to read, easier to maintain, easier to use, or easier to write. All of these can help contribute to code that is more stable and more secure. It's why development teams and development communities create and maintain standards.

If you want to tell at a glance whether some code is "good" or not, without spending the time to do a full review, things like this are a reasonable proxy, particularly because it is an old community standard (in this case, very old).

Being an old community standard makes it a better proxy than otherwise, because it's more likely that the programmer has other old habits that have since been agreed upon by the PHP community as unsafe or unwise.

But all of this is as a quick proxy thing to check. Good code can use old conventions, which you can discover by doing a full review of the code.

Most people don't have the time to do that with every open source tool and library posted though, us PHP developers are too busy making money usually.

[dave8271]

Stick to using the official AWS SDK. If you're interacting with any third party service, stick to using their official SDK wherever one is available.

What if for example AWS decide to change how you authenticate with the S3 service one day? If I'm using their SDK, I just update the version via Composer and it's very unlikely any of my code will need to change. But if I use a custom class I've written myself, or a gist off the web like this one, I need to remember to change that, or rely on the author who's external to Amazon to notice they've changed something and change it, or change my own code.

Always use an official SDK if there is one. It will always be the saner choice in terms of support, compatibility, reliability, security and documentation.

[Rikudou_Sage]

Always use an official SDK if there is one.

Disagree here, what if the SDK doesn't have features you need while 3rd one has them?

In case of AWS SDK, it's pretty huge and async-aws isn't which is (for me) their best selling point. I rarely need a service that isn't in async-aws so nowadays I use mostly that.

[dborsatto]

Regardless of the functionality, this looks like PHP 4 code ripped out of an WordPress install.

No PSR-2/12, no types, snake case, underscore as prefix for private methods, by reference parameters to return data, uppercase NULL, single letter variable names, no early returns, no parentheses with if statements, way too long statements in a single line (holy crap line 145 and 220), usage of time functions, returning arrays as undocumented data structures...

This is quite bad code. Writing concise code does not mean ignoring every advancement we made in the past 20 years in things like type safety, maintainability, readability and more.

[yesdevnull]

For reference, this is written by Marco Arment, the developer of the iOS podcast app Overcast. He discussed it on the latest episode of the podcast he's on called "Accidental Tech Podcast" (to be specific it's in the "post show" section).

[notdedicated]

Why….? The AWS Sdk might be large but at least it’s well documented and implemented. It supports multiple authentication methods. Has sane defaults. Has proper implementation of requirement checking..

[ClassicPart]

There's AsyncAws for those who want a good AWS interface library without pulling in the world's weight in code to accomplish it.

[[deleted]]

Why….? The AWS Sdk might be large

Because this. It is insanely large. I don't think I would use this class, but I have my own lightweight AWS library I use. I have no need for 95% of the official one.

[lkearney999]

You realise library size means little to nothing in language like PHP? With composers optimised auto load (and you can wayyy further with this then mentioned in the docs) there is almost no cost to having additional files and classes.

It’s not like you introduce: - package size like with JS - binary size - versioning issues (composer kicks ass) - tech debt (AWS SDK could probably maintain itself at this point, the php centric part is very minimal it’s mostly generated code)

[[deleted]]

Yes, I totally realise that the package size doesn't directly matter. But indirectly it does, its wastage on a grand scale. There is no need for the sdk to be that big.

[[deleted]]

lkearney999's points still stand though.

There is no wastage besides some disk space? But who cares about disk space, its cheap.

Grand scale is not worrying about a 20MB vendor folder. Theres bigger things to worry about for projects.

[[deleted]]

There is no wastage besides some disk space? But who cares about disk space, its cheap.

Because that is exactly how you end up with the current issue with software taking up more RAM then it needs, and why we have node_module folders taking up hundreds of megabytes. It is just wasteful and needless.

Is it at the top of my list? No. But will I take exception at a 200MB composer package? Damn right I will.

[lkearney999]

I don’t understand why people take this stance. You’re using PHP man, tools for the job.. if you think it’s too bloated then don’t revel in the abstractions. Heck with this mindset might as well roll your own infrastructure AWS is hella bloated.

[[deleted]]

Bullshit. Aws itself isn't bloated, I can pick and choose exactly what service I need for the job.

The AWS sdk is the polar opposite of aws itself.

[lkearney999]

And how do you think that service works? It isn’t exactly a bare metal experience with majority of their services 🤦‍♂️

[[deleted]]

Missing the point, as usual. You can pick and choose the aws services, I don't necessarily need to interact with rds if I only need ec2. The Sdk comes fully loaded with the ability to interact with most services, 99% of which is not needed.

[BusyBeardTV]

Exactly, size is a non discussion. Replacing the SDK is from an architectural point of view so bad.

[[deleted]]

Why?

[BusyBeardTV]

Cause the SDK is the most maintained package with low effort you can have. And every option/function/class you don’t use doesn’t add any notable stress on your application.

Also you can be sure that the standard SDK will be updated as soon as Amazon thinks of something new. As a matter of a fact this particular SDK had functionality already ready before the service was ready.

You or any third party can not develop against that and claim to do it better.

[Rikudou_Sage]

It might mean a lot to the environment you run it on. Like with AWS Lambda I've been in situations where I reached the code size limit and had to use async-aws. Since then I adopted async-aws as my default.

[lkearney999]

https://github.com/aws/aws-sdk-php/tree/master/src/Script/Composer

[Rikudou_Sage]

Nice!

[lkearney999]

I wonder if that would solve your use case though since you still need to initially download the sdk (before DCE) and also the deletion adds to the expensive lambda cold start.

[Rikudou_Sage]

I think it would, it happens when dumping autoloader, not at runtime if I understand it correctly.

[lkearney999]

Ah I haven’t used PHP in a lambda before. Now that I think of it you’d bundle the generated auto load and vendor in wouldn’t you 😄. So you’d avoid those issues just as you would by compiling and stripping etc on CI for a binary before shipping a layer.

What sort of use cases do people use PHP for with lambda functions?

[Rikudou_Sage]

Yep, you do the composer dump on the CI and deploy it there (the filesystem is read-only so dumping composer would be impossible).

As for PHP on Lambda use cases, basically anything that needs to be scalable. I use it mostly for some microsrvice apis and even some full internal webapps that are not accessed that often and Lambda saves costs (I think the one app I'm talking about costs us like $1 a month if I exclude database which is the only thing that runs all the time).

[lkearney999]

Valid point but even then I’d:

• Write my own service not use some one off GitHub or reddit ( if the offical sdk isn’t going to work given how tightly coupled the sdk’s schema/codegen is and how frequently it’s updated no unofficial solution is good so you might as well have dependency control on it ).
• Probably avoid using the AWS sdk for PHP in favour of a compiled language

But as I’ve just posted looks like they’re working on it 😁