If you interact with any of Amazon’s Web Services using PHP you should be using their SDK.
It’s very powerful and pretty simple to get started with.
In my case I did not want to checkout their whole repository into my frameworks namespace and decided to use .phar file they provided as
To me, using a .phar file for third party libraries kind of makes sense if I’m not planning to extend or overwrite any of the available functionality.
Plus if you have your own directory conventions and don’t want to bother re-factoring Amazon’s structure, .phar might come in handy.
The issue I ran into (not really an issue but inconsistency always bothers me as an engineer) is that if you are using namespaces and your own autoloader, requiring .phar file anywhere you need to access AWS is pretty ghetto.
The way I solved it is by using a very simple wrapper that either loads configuration (using \library\configuration as an example) containing your key/secret or takes key/secret as a constructor parameter and simply stores instance of AWS internally while routing all the calls directly to it.
You can check out this approach on my GitHub page located here: https://github.com/AlekseyKorzun/aws-sdk-wrapper
Facebook released updated Roadmap SDK/OAuth 2.0, you can read more about it here: http://developers.facebook.com/blog/post/525/
I will keep a close eye on it, since the change-set will affect my php-sdk patch:
No need to settle for older (v2.2.x) version of SDK or create dirty work arounds in order to retrieve and pass token data to PHP.
Grab it from: https://github.com/AlekseyKorzun/php-sdk
Here is a diff if you just want to patch v.3.x SDK on your own: https://github.com/AlekseyKorzun/php-sdk/commit/dbb230a8acb9ccfa0b6fa90fcd3caecd3b677dac#L0L315
P.S Facebook will be making changes to authentication system for both JS and PHP SDK’s so keep an eye on their GitHub for further updates.
Usually when developers focus on page load times, things like third party API’s are often overlooked or simply ignored (it works, why should I re-implement this?!).
In some cases, the subjects already use the new SDK (due to integration of social plugins) on top of the legacy SDK.
This is a case of double dipping that will cost you traffic and revenue.
Old SDK loads a total of 5 files in a package that’s roughly 241.93KB in size.
On the other hand the new SDK loads a total of 2 files in a package that’s roughly 125.07KB in size.
That’s almost 50% less data for end user to transfer and 50%+ less requests for their browser to make.
Both versions are hosted on Akamai but there is a difference between the two approaches.
a1875.g.akamai.net has address 22.214.171.124 a1875.g.akamai.net has address 126.96.36.199
e3821.c.akamaiedge.net has address 188.8.131.52
As you can see the new SDK is hosted on Akamai Edge Platform which is basically a Akamai CDN on steroids.
Akamai’s EdgePlatform is one of the world’s largest distributed computing platforms. It is a network of more than 84,000 secure servers equipped with proprietary software and deployed in 72 countries that relies on applied mathematics and algorithms to help solve congestion and vulnerability problems on the Internet. These servers reside within approximately 1,000 of the world’s networks monitoring the Internet in real time - gathering information about traffic, congestion, and trouble spots. Akamai uses this intelligence to optimize routes and replicate data dynamically to deliver content and applications more quickly, reliably, and securely.
You can read more about it here: http://www.akamai.com/html/technology/edgeplatform.html
So go make a switch now, your users will thank you.