Будущее веб-приложений: Джошуа Шахтер

Это первая из серии статей по материалам конференции "Будущее веб-приложений" (The Future of Web Apps summit), прошедшей в 2005 году. В этой статье собраны и обработаны выдержки из выступления ведущего разработчика del.icio.us Джошуа Шахтера (Joshua Schachter). Скачать и прослушать выступление на английском языке в формате mp3 можно отсюда.

В своем выступлении Джошуа рассказал о многих моментах, с которыми столкнулась команда разработчиков del.icio.us. Ниже приведены некоторые из упомянутых тем.

Веб-браузеры

Огромное количество времени у вас отнимет отладка работы вашего приложения в разных браузерах. JavaScript и CSS работают по-разному, отображение страниц отличается. Обязательно найдется какой-нибудь пользователь «Оперы», который будет ныть и портить вам жизнь. Вам придется разобраться с реализацией кеширования страниц у Microsoft Internet Explorer. В общем, готовьтесь к сложностям в этой области.

Масштабирование

Не тратьте время, пытаясь угадать будущие проблемы. Решайте настоящие

Не пытайтесь масштабировать ваше приложение с самого начала. Угадать, где будут проблемы, очень тяжело, и вам не стоит тратить на это время. Вы и так все увидите. Тем не менее стоит иметь в виду некоторые моменты.

Почитайте статьи Кала Хендерсона (Cal Henderson) из Flickr и Fitzpatrick из LiveJournal о тех проблемах, с которыми они сталкивались, и о том, как они их решали. Подумайте о том, как разнести ваше приложение на несколько серверов. Например, вы можете отдавать основной контент, RSS^*-каналы и изображения с разных машин. Поставьте кеширующий прокси-сервер между вашим веб-сервером и пользователями. И вообще используйте кеширование везде, где только можно.

Помните о том, что многие проблемы сегодняшних веб-приложений плохо решаются с помощью SQL^*. Проверяйте скорость выполнения каждого SQL-запроса. Старайтесь уменьшить размеры индексов. Будьте хитрее — помните, что никто никогда не будет просматривать результаты на страницах 100, 101, 102 и т. д. А тот, кто туда доберется, может и подождать.

Решите, в каких местах вашего приложения допустимы задержки, и по максимуму их используйте. Например, никто не заметит, если обновления ваших RSS-каналов отстают на несколько минут. Обновления статистических страниц с опозданием на несколько секунд или даже минут не заметны для ваших пользователей, однако могут существенно облегчить работу вашей базы данных.

Не менее важным является знание вашего веб-сервера. Изучите работу Apache. Тонкая настройка веб-сервера может значительно ускорить работу вашего приложения. Используйте модули, позволяющие контролировать скорость выкачки данных, такие как mod_throttle или mod_bandwidth.

API

Чем раньше вы сделаете API, тем лучше

Постарайтесь реализовать API^* как можно раньше. И вам будет проще, и вашим пользователям. Наличие API помогает популяризировать ваше приложение. Сделайте API как можно более простым. Такие технологии, как SOAP^* и XML RPC^*, замечательны, но гораздо больше народу знает, как использовать обычные GET- и POST-запросы вкупе с HTML^*.

Постарайтесь минимизировать работу пользователей. Не требуйте регистрации пользователей и ключей разработчиков (API keys) для тех функций, которые могут выполняться без этой информации.

Безопасность

Иметь безопасность в виду при разработке приложения полезно, но, так же как и с масштабированием, не пытайтесь предугадать проблемы. Они появятся в любом случае. Гораздо эффективнее чинить то, что поломано. Помните, что идиоты умнее нормальных людей и у них больше свободного времени. Что бы вы ни сделали и какую бы защиту ни поставили, идиоты все равно найдут обходной путь и все сломают.

Прячьте детали реализации

При разработке приложения позаботьтесь о том, чтобы серийные и легко угадываемые ключи (index.php?id=10) не выставлялись наружу. Обязательно найдется какой-нибудь умник, который решит перебрать все ключи, для того чтобы стащить ваши данные. И это несмотря на присутствие API. Прячьте детали реализации проекта от посторонних глаз. Например, в del.icio.us вместо серийных цифровых ключей используются MD5-хеши. Это помогает.

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

Мониторинг

Установите и постоянно подстраивайте системы мониторинга (Nagios, MRTG). Наведите цифры и графики на все, что можно. Системы мониторинга помогут вам в двух вещах.

Во-первых, проинформируют вас, когда что-то не так. Если у вас упал сервер или перестала работать база данных, то вы об этом узнаете незамедлительно.

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

Обнаружив нестандартное поведение, вам нужно решить, что делать. В частности, вы должны определиться, хотите ли вы поощрять данное поведение, игнорировать его или наказывать. Это позволит проекту развиваться в том направлении, которое вам ближе, и поможет вам выбирать набор функциональности, которую вы хотите или не хотите реализовывать.

Функциональность

Аккуратно выбирайте функциональность

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

При принятии решения о реализации той или иной функциональности для del.icio.us учитывается наличие этой функциональности в других проектах или протоколах. Например, в del.icio.us нет и не будет функции, которая бы позволяла посылать сообщения от пользователя к пользователю. С этим замечательно справляется электронная почта.

В любом случае, что бы вы ни сделали, пользователи будут просить вас добавить ту или иную функциональность. Пытайтесь разобраться в причинах. Поймите, почему пользователи просят эту функциональность, какая проблема стоит перед ними. И решайте эту проблему.

Ссылки по теме

• Проект mod_throttle на FreshMeat
• Проект mod_bandwidth на FreshMeat
• Прокси- и веб-сервер Perlbal
• Механизм кеширования memcached