Simple framework wrapper for Amazon’s AWS SDK for PHP 5

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
an alternative.

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: Jerry Cain Updated JavaScript SDK and OAuth 2.0 Roadmap

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:

http://alekseykorzun.com/post/6925234287/integrating-facebooks-social-plug-ins-with-facebook-php

Highlights:

July 22:

• Updated JavaScript SDK available
• Migration setting changes
• Renamed “OAuth 2.0 for Canvas” migration to “signed_request for Canvas”
• Added new “OAuth Migration” setting
• Defaulted all new apps to have “OAuth Migration” setting enabled

July 29:

• Updates to PHP SDK to be new-cookie-format aware.

October 1:

• All apps to have “OAuth Migration” setting enabled (Revised from Sept. 1)
• All apps to have “signed_request for Canvas” setting enabled
• SSL Cert required for apps on Facebook (Canvas and Page Tab apps)

Integrating Facebook’s Social Plug-ins with Facebook’s PHP SDK (v.3.0)

I made a quick modification to Facebook’s PHP SDK (v.3.0.0) that seamlessly integrates new token format that Facebook’s social plug-ins utilize.

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.

Why are you still using Facebook’s legacy JavaScript SDK?

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?!).

Today I noticed that one of the web sites I visit still used old Javascript SDK offered by Facebook. To my surprise that seemed to be a very common trend: http://www.google.com/&q=%22Cross-domain+Receiver+Page%22

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.

Footprint:

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.

Delivery:

Both versions are hosted on Akamai but there is a difference between the two approaches.

Old:

a1875.g.akamai.net has address 204.0.5.56
a1875.g.akamai.net has address 204.0.5.59

New:

e3821.c.akamaiedge.net has address 184.86.159.139

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

Conclusion

• Much smaller foot print
• Twice as less requests for additional data
• Better content delivery platform
• Most of the new social plug-ins already use it
• The only SDK Facebook actively supports

So go make a switch now, your users will thank you.