Google App Engine *

Вступление

Многие знают про инфраструктуру от google под названием gae, некоторые считают её слишком проприетарной, другие слишком дорогой. Да она не дешевая, и мы попробуем написать оптимальное приложение для gae, которое жрало бы очень мало ресурсов и в идеале не выходило из бесплатных квот даже при хабраэффекте. Опишу мои ошибки, удачные технологические решения при написания сервиса японских кроссвордов. Фишка сайта в том что он позволяет создавать свои кроссворды и из обычной картинки тоже и делиться ими с друзьями.
Для построения сайта используется след. технологии:
backbone.js — фреймворк для обработки запросов на javascript'е. C его помощью будем надеяться, что уложимся в бесплатные квоты, так как весь код выполняется на клиенте, с сервера запрашиваются только данные о кроссвордах в json формате.
require.js — библиотека для дозагрузки любых ресурсом(js, html), можно указать код, который выполнится после загрузки всех ресурсов. Идеальна если у вас есть на сайте javascript и он используется в 1% случаев, и вы не хотите включать js-файл в index.html, то она вам подойдет.
undescore.js — всякие плюшки для слежения за изменением всего объекта или за конкретным его свойством. Очень большая и крутая библиотека, но я использую её как шаблонизатор.
bootstrap — чтобы не заморачиться с дизайном.
less — не ну, а почему б не использовать? (Потому что мы можем)
Ну и конечно же gae — на чем все это будет крутиться.

Наверняка каждый из вас в своей жизни находил удобный для себя файловый хостинг, а через какое-то время обнаруживал, что на нем от количества рекламы начинают болеть глаза, условия уже далеко не такие лояльные и вообще пора бы уже найти что-то новое. Вариантов дальнейших действий два — или найти новый, пока еще не раскрученный файлообменник и использовать его, пока он не испортится, или организовать собственное решение. Для второго варианта, в свою очередь, можно приобрести хостинг (придется правда набить шишек, пока не найдется добросовестный хостер с качественными услугами) или воспользоваться облачным сервисом.

Довольно интересной находкой оказался PaaS-хостинг от Google — Google App Engine (далее GAE), который дает возможность хранить до 5 Гб файлов при 1 Гб входящего и 1 Гб исходящего трафика в день, и кроме всего прочего, в нем используется модель High Replication, то есть ваши данные будут хранится сразу на нескольких серверах по всему миру!
Особенностью GAE является несколько нестандартный интерфейс для работы с файлами, поэтому я и сделал собственный сервис, о чем расскажу в данной статье.

Подключение PayPal Standard Checkout

В данном руководстве последовательно описан мой опыт внедрения PayPal Standard Checkout с использованием языка Java на платформе Google App Engine. Данная статья рассчитана на людей уже имеющих опыт работы с облачной платформой GAE.

Задача

Потребовалось мне интегрировать платёжную систему PayPal на сайт собственного проекта который будет предоставлять сервис по подписке. Начав работу с PayPal Express Checkout API через некоторое время пришло осознание того что система приёма платежа становится слишком громоздкой, в то время как у готовых кнопок Standard Checkout отсутствует необходимая гибкость, которая требуется в случае интеграции сайта с другими платёжными системами.
Выход был найден в использовании инструментов Standard Checkout которые предоставляет PayPal разработчикам сторонних “корзин” для сайта.

Недавно в одном моём проекте понадобилось добавить простенькую статистику. Не буду углубляться в детали самого проекта, скажу лишь, что это shareware программа, которая стоит у нескольких десятков тысяч пользователей. Моя цель — знать сколько человек в день пользуется Trial версией программы.

Очевидным решением является поставить веб-сервер, написать маленький скрипт, обрабатывающий запрос на некий URL вида http: //myproject/ontrial и далее моя программа при запуске должна делать запрос на этот URL.

Ранее я уже делал небольшие поделки на GAE, поэтому есть кое какой опыт, да и развертывания сервисов меня привлекла. Поэтому долго даже не думал над тем где расположить свой сервис, тем более он состоит из 1 простого метода, который по сути ничего не делает. Что еще более обрадовало, так это статистика в панели администратора GAE, в которой можно видеть какие методы и сколько раз дергались. Далее привожу сухую статистику использования и цены (много картинок)

Возможно, кто-то из читателей сталкивался с этой проблемой. В багтрекере GAE она уже давно висит в виде незакрытого Issue 3379. Кажется, изначально проблема касалась только Java, но сейчас она наблюдается и в Python (по крайней мере в 2.7). Описание ошибки и решение для Java можно найти, например, там, а в этом топике речь пойдёт про Python.

Коротко о сути. Часто сайты пытаются установить более одной cookie за раз. Делают они это путём указания нескольких заголовков Set-Cookie в ответе на запрос. По странному ведёт себя в этом случае urlfetch (и базирующиеся на нём urllib/urllib2): все эти заголовки склеиваются в один и разделяются запятыми. Надо ли напоминать, что запятые также присутствуют в полях expiries, а порой и в самих значениях cookie, что очень затрудняет обратный разбор такой строки. А стандартный HTTPCookieProcessor из urllib2 и mechanize просто не справляется с такой ситуацией.

Итак, если ваш проект использует поддержку cookies «из коробки» в urllib2 или mechanize, то вам безусловно подойдёт

Спустя три с половиной года после презентации платформы на Campfire One, App Engine выросла и стала полноправным продуктом Google. Мы создавали прокдукт, следуя простой философии: «удобно использовать, просто масштабировать и легко начать». Сейчас у нас более 100 миллиардов посещений в месяц, более 300 тысяч активных приложений и более 100 тысяч разработчиков, использующий продукт. Подход полностью оправдал себя. Спасибо за Вашу поддержку. Google верит в светлое будущее App Engine.
via The App Engine Team

Python 2.7, повышение лимитов, Cloud SQL Preview, Google Storage for Developers, Premier Accounts

Неужели свершилось? Основное ограничение, мешавшее переносу существующих приложений на платформу GAE — отсутствие обычного, нормального SQL уходит в прошлое? Компания Google анонсировала свой новых продукт: Google Cloud SQL.

Для того, что бы получить доступ к данному API необходимо на странице Services вашего проекта в GAE «Запросить» данное API — заполнить небольшую форму (кстати реализованную при помощи Google Docs) — и остается дальше только ждать когда же дадут доступ — что бы воочию пощупать — действительно ли там нормальный SQL без каких-либо ограничений?

Вышла новая версия GAE SDK 1.5.4.

Основные изменения:

• Blobstore API — появилась возможность задать максимальный размер для загружаемого файла
• Datastore — улучшение внутреннего механизма выборки по нескольким полям с использованием операции = (равно)
• Prospective Search API теперь доступна и для Java
• Memcache — стало возможным делать запись в Memcache без ожидания ответа от сервиса. Мы просто передаем данные, и не дожидаемся пока они будут обработаны этим сервисом для продолжения работы

Несмотря на последние события, связанные с повышением цен, Google App Engine продолжает работать над улучшением качества своего продукта, что нас радует.

Список изменений для Python
Список изменений для Java
Скачать GAE SDK 1.5.4

Источник: официальный блог Google App Engine

P.S. В текущей версии SDK не появилась возможность выборки по условию несоответствия <, >, !=.

В стандартном фреймворке webapp есть много полезного и мало лишнего. Но есть в этом неплохом творении гугла одна особенность — все используемые модули подгружаются при старте приложения. Это удобно для разработки и отладки, но грозит одной проблемой: слишком долгий старт инстанса немаленького приложения. В результате пользователь вынужден ждать пока загрузится всё приложение, даже если для отображения нужной ему страницы нужна лишь малая часть кода.

Сегодня мы «научим» webapp не загружать лишнее.

Google объявила об изменениях, касающихся введения новых правил учета ресурсов, используемых приложениями под App Engine.
Главная новость в том, что теперь будет предоставлено 28 бесплатных часов в сутки на приложение вместо 24. Это дает хороший шанс для слабо нагруженных приложений оставаться в рамках бесплатных квот.
Кроме того, переход на новую систему отложен до 1 ноября. Peter Magnusson (технический директор Google, ответственный, за App Engine) признал, что было ошибкой дать так мало времени пользователям системы на предварительную оценку ситуации и оптимизацию своих приложений. Обещаются улучшения в консоли, касающиеся учета инстансов, а отчеты (usage reports) теперь будут доступны уже на следующий день.
Также продлен срок действия 50%-ной скидки. Теперь она будет сохранена до 1 декабря (предполагается, что к тому времени будет доступен Python 2.7).

App Engine полным ходом идёт к светлому будущему и новой методике расчёта за ресурсы. Паника и хаос вселились в ряды разработчиков под AE — слишком многое держится в строжайшем секрете (или в компании тоже толком не знают что как будет). Но сегодня мы не будем обсуждать, будет ли blobstore включен в бесплатные квоты, или за один лишь доступ к нему придётся платить. Не обсудим куда податься, если новые цены совсем не по карману и не будем говорить о $50 «халявы», которыму гугъл пытается смягчить переход на новые рельсы (тем более, что эту радостную весть разослали всем администраторам приложений).

Сегодня речь будет идти об оптимизации приложений. Вы же уже оптимизировали своё приложение на минимальное потребление процессорного времени и памяти? Забудьте об этом, теперь это вторично и Ваши кровные будут сниматься по другим меркам.

Основные изменения:

• Blobstore API — нет ограничения на размер добавления
• Список Индексов — пограммный доступ к списку индексов и их статусам
• Datastore Admin — можно влючить из консоли администратора
• Memcache API для Python — теперь поддерживает CAS операции
• Java Обновления — с помощью команды AppCfg download_app, можно скачать любые файлы, загруженные с war каталога приложения

Подробности ниже…

1. Суть оптимизации
2. Page load vs forced refresh
3. Потребуется автоматизация
4. Реализация серверной части
5. Оптимизация серверной части
6. Особенности google app engine
7. Исходный код
8. Резюме

Рассматривается пример реализации для Google App Engine / Python.

Представляю вашему вниманию вольный перевод статьи под названием "A Simple Chat using the Channel API". Так же я решил немного добавить своего кода.

Сегодня мы представляем вам новую статью для Google App Engine посвященную Сhannel API, которое появилось в декабре 2010 года в релизе 1.4. С этого момента стала возможной отправка сообщений напрямую с сервера клиенту и обратно без использования polling.
Поэтому стало достаточно просто реализовать чат на Google App Engine. Процесс реализации описан под катом.

Доброго всем времени суток!
Недавно занялся разработкой своего первого приложения на Google App Engine и моментально столкнулся с забавной проблемой — эмулятор сервера GAE, входящий в пакет GAE SDK для Java отказывался применять изменения в коде проекта. Далее описание проблемы и то, как я от нее избавился. Возможно это сэкономит кому-нибудь время

— Новый runtime: Go. Пока в качестве эксперимента, с ограниченной поддержкой APIs. Go открыт, компилируем, легковесен и может пригодиться для CPU-нагруженных приложений.

— Backends. Теперь можно использовать постоянно запущенные инстансы с различными конфигурациями. Самый дешевый (128MB/600MHz) — 8 центов/час, в сутки дается 72 цента для бесплатного использования долгоживущего инстанса.

— Pull-очереди. Позволяют арендовать задания посредством REST API или непосредственно из приложения.

— High Replication хранилище теперь используется по умолчанию при создании нового приложения. Цена на хранение данных в этом типе хранилища снижена с 45 до 24 центов.

— Увеличены квоты на UrlFetch до 32М; для MailAPI, число бесплатных отправок снизилось с 2000 до 100.

В sdks появился новый пакет app_identity, который наводит на мысль, что в следующей версии наконец-то появится SSL. Ну и завтра, 11 мая, на google.io расскажут о полнотекстовом поиске в AppEngine, который, очень надеюсь, скоро появится в рантайме.

Полные списки изменений:
— Release Notes: Python
— Release Notes: Java
— Revision History
— Product Roadmap

— Files API: Теперь можно программно читать и писать в Blobstore. Доступно как в Python, так и в Java.
— Обновления в работе Task Queue и Cron: Для задач можно указывать версию приложения, с которой очередь будет работать, для крона аналогично + возможность указывать диапазон времени, например, «every 5 minutes from 11:00 to 17:00».

Для PythonSDK
— Prospective Search API: Экспериментальное АПИ, позволяющее по критерию в момент вставки сущности в хранилище делать что-либо. Типа обратной связи по какому-либо критерию.
— Testbed Unit Test Framework: Тестирование для AppEngine, тут все должно быть и так понятно.

Для JavaSDK
— Concurrent Requests: Теперь возможно использовать каждый инстанс может обстуживать мультипользовательские запросы в одно и тоже время, фича включается путем установки threadsafe в true в appengine-web.xml
— Remote API и Deferred API: Все по аналогии с PythonSDK.

Полные списки изменений:
— Release Notes: Python
— Release Notes: Java
— Revision History
— Product Roadmap

В прошлой моей статье про скорость работы с данными GAE был встроен графический счетчик показов. Каждый мог видеть значение счетчика и израсходованные ресурсы CPU. Как я уже говорил, счетчик был довольно «тяжелым»: создаваемая им нагрузка эквивалентна отображению на странице 1000 записей из базы данных без использования кеширования.

Эксперимент со счетчиком оказался весьма полезным, а его результаты несколько неожиданными для меня (отличными от запросов с одного IP-адреса). Хочу поделиться результатами эксперимента и поставить новый эксперимент, уже с учетом пройденных ошибок. Кстати, исходный код нового графического счетчика доступен для всех и приведен в статье.