Попробуем оценить некоторые практики, а также дадим технические советы, надеемся, это поможет делать гибкие и практичные приложения
В аппсторах уже миллионы приложений, а по настоящему популярны лишь несколько сотен из них. Почему так? Плохой UI, тормозит, глюкает – вот эти причины, с точки зрения юзера. Попробуем разобраться, что можно сделать с нашей стороны, чтобы приложения продвигались в рейтингах загрузок.
1) Применяйте стандартные протоколы. Или, по крайней мере старайтесь. Под “стандартными протоколами” имеются в виду HTTP и HTTPS, SSL, быть может еще изредка SFTP и RESTful, быть может еще подобные, столь же надежные и проверенные вещи. Они стали стандартом, поскольку в них внедрены проверенные механизмы handshaking-а, описывающие как коммуницируют клиент и сервер, как обмениваются уведомлениями. “Приложения на стандартных протоколах” более гибкие, и лучше настраиваемые, хотя быть может и не идеально-функциональные. Нестандартные протоколы, например проприетарные, разработанные вендором, часто сложны для внедрения, требуют времени для настройки, а далее усилий для поддержания серверов и приложения в работоспособном состоянии. Все это обязательно скажется, если приложение будет скачано в десятках тысяч экземпляров.
2) Никогда не “стройте на песке”, например на предположении, что все сервисы, предлагаемые приложением, будут находиться всегда там же физически, где они находятся сейчас, и что можно выделить им диапазон IP-шников или доменных имен и забыть об этом. Лучше всего здесь пользоваться внешним реестром, который будет “ресолвить” ваши “эндпойнты”. Можно попробовать балансировщик нагрузки с валидным виртуальным именем, далее применять его для устранения проблем с маршрутизацией.
3) Применяйте библиотеки совместимости, или же пользуйтесь услугами middleware-инфраструктурных провайдеров. Вместо того чтобы во всем полагаться на возможности локальной системы.
4) Никогда не теряйте из виду такую вещь как масштабируемость. Чтобы иметь возможности расширяться с ростом загрузок, советуем делать “generic and stateless” приложения. Приложение должно быть достаточно простым в своей идее, и не терять способность масштабироваться, после достижения первых результатов, набора пользовательской базы.
5) Применяйте стандартные принципы безопасности. Задайте четкую стратегию авторизации и аутентификации. Например применяйте фреймворк OAuth2, или другие безопастностные механизмы.
6) Не полагайтесь на локальные файловые системы. Исходите из того, что в один момент случится выход из строя локальной системы. Вместо нее, советуем хранить данные “в службе”, к примеру SQL либо NoSQL. Это также будет полезно, когда понадобится “поднять” логи приложений.
7) Отходите от применения session state в приложении. Помните, что расширяемость любого приложения ограничивается его statefulness. Советуем всегда стараться уменьшать влияние session state. Этого можно добиться, возможно, подключая внешнюю базу данных, или же in-memory систему хранения данных.
8) Чтобы приложение получалось более надежным и производительным, рассмотрите возможность построения мультирегиональной архитектуры для него. Имейте план избежания недоступности приложения для отдельного региона.
9) Тщательно выбирайте между синхронной и асинхронной интеграцией. Если время ответа на запрос синхронизации становится все больше, следует продумать, как поддерживать приличную юзабельность системы; возможно, вместо системной интеграции нужно применять интеграцию сервисов.
10) При разработке избегайте применения “инфраструктурных” API. Попробуйте независимые от инфраструктуры вещи, возможно опенсорсные, или качественные лицензированные; это поможет сделать код не зависящим от излишних зависимостей, “подтягивающихся” по запросу.
11) Мониторинг приложения, проверка его состояния является крайне важной вещью, для проведения проактивных, а также и корректирующих мероприятий. Если приложение работает в облаке, мониторинг – простая вещь, легко проводится при помощи сторонних сервисов. Весь стек приложений можно будет анализировать, оптимизировать, при необходимости устранять возникшие проблемы.
Итак
Пишите код со всей ответственностью, применяя весь свой опыт. Работоспособность приложения зависит от того, как все его компоненты смогут работать в связке, как целостная система; а также от того, какие сложности вы смогли предвидеть и устранить.
