NYCPHP Meetup

[Gary A. Mort]

I'm working on getting my site up on Google App Engine.... so far it's 
been an interesting process and it took me a day to get to the point 
where I was ready to actually install Joomla.  :-)

I figured I'd post my notes for anyone else interested in it as well
https://gist.github.com/garyamort/7758663

It's an almost "from scratch" process as it includes pre-install steps to:

1) Use PHPStorm's cool Google App Integration features.  By creating a 
"new" GAE project through their interface, it prompts for all those GAE 
settings I needed later to push changes up to the server as well as 
running the local GAE dev test environment.  I go ahead and push the 
hello world project up to GAE as well as make a few changes to get 
comfortable with their control interface.

2) Once I have a working PHPStorm GAE project, I use Git and github to 
merge the Joomla CMS code into my code.

3) After it's all merged, I discovered I needed to make a few tweaks to 
get the Joomla Installer to work under GAE.  There is probably a cleaner 
way to organize them and when I actually go back and do it a second time 
I can make a more detailed step by step.


What I find exciting about using the GAE environment is something which 
first seemed to be a big negative.  You can't modify files on the server 
from within your server code.  You have to "deploy" files to the server 
to change them.  This means installing Joomla Extensions, making 
configuration changes that modify configuration.php, and uploading 
images for articles have to be done on your local system and then 
"deployed" to the server.

There are some work-arounds for this, so it is possible to get around it 
- and I've got a few possibilities in mind for setting up restricted 
access for site managers to a special "version" of website where they 
can make these changes.  However, for GENERAL usage, this "con" is 
actually a big plus!  Every security problem I have ever encountered in 
Joomla has involved someone making changes to the files on the file 
system.  Untraceable changes, no idea how they got them there because 
file changes were not being logged by the system.  Was it some hidden 
php file?  Was it a compromised FTP account?  I have no clue.   By 
restricting file changes to the GAE deployment process, this means I get 
Google logging for free.  Every file change can be tracked down to a 
user account and an ip address.  I will gladly hop through one extra 
hoop to never have to worry about someone uploading images into my 
server and using it to host inappropriate material.


With GAE your not deploying your app on a traditional web server, where 
all the PHP files get executed if their accessed via the web. Instead 
when you "deploy" a set of files to your GAE project Google uses a 
configuration file to do some processing.  All the "static" files[css, 
javascript, images] will be stored on a completely separate server which 
is optimized to deliver them.  All the other files, get placed on your 
GAE instance, but only the "entree points" you have configured will 
actually be executed.  IE in my configuration, any request for the 
installation or administration folder will cause the index.php file from 
that folder to be run. Everything else goes to the primary index.php file.

This means you completely close off any security issues where someone 
discovers an extension with a hole that lets you do something like 
http://yourjoomlasite.com/plugins/content/somecoolcontentplugin/somecoolcontentplugin/lib/somelib.php?action=someexploitablecommand

All those problems are eliminated.


Security: one nice feature is that you can restrict access to some of 
the entry points using Google Authentication.  In my case, I set things 
up so you can't even access the installation or administration 
interfaces unless you are logged on to a Google Account and have been 
assigned admin rights to the project.


Usage costs:  Usage costs are a bit on the odd side.  With GAE you don't 
have a server that is "always running" whether or not your website is 
active.  Instead, when someone attempts to connect to your website, 
Google spins up 2 micro virtual systems - a web server and a mysql 
server - configured with your PHP code and your database.   When the 
system stops being accessed for at least 10 minutes, those systems are 
turned off.  You only pay for the minutes that your system is actually 
running.

Scalability: Since your forced to run 2 separate "instances" - one for 
the database and one for the PHP code, you get some basic scalibility 
for "free".  GAE can actually run anywhere from 1 to 1,000[or more!] 
"instances" of your PHP application - and they all access the same 
database.  So a website that suddenly gets so popular that it's 
overloaded can reconfigure their account and increase the maximum number 
of instances allowed to run...instant scaling.

Alongside all of this, there are a lot of fun little features you can 
play with once you have an app engine deployment running.  They allow 
you the option of integrating Google's Pagespeed service into it which 
will optimize images and compress/minify javascript and css with a 
dizzying array of switches, dials, and toggles to turn on/off different 
optimization.

They have a User API which PHP apps can use to use Google Apps for 
authentication/user information.

There is both a "free" memcache service and a paid option

Lots of things to twist and turn and play with.