Россия
beet-lab.com Share

BEET LAB

Мы разрабатываем мобильные приложения с 2011 года. За это время мы реализовали более 15-ти успешных проектов под разные платформы. Разработанные нами приложения побывали в топ-5 и даже топ-1 сторов. Н...
Страна: Россия
Город: Москва
Год основания:
Количество сотрудников:
Специализация:
Продукты и сервисы:
Технологии:
Количество приложений: 3
PR/Медиа:
Показаны записи 1-3 из 3.
фотография
Free
развлечения
Free
 
 
08-07-2016, 11:17
BEET LAB

Как помочь техническому отделу выполнить ваш заказ?

Часть вторая – клиент-серверные приложения, или «давайте добавим ещё 2 поля в базу данных»!

(Никита Семенов, CTO Beet Lab)

Итак, как я уже писал в первой части - вы решили, что вам нужно приложение. Во время первой встречи с представителями студии, вы слышите страшные слова – «Приложение клиент-серверное, вам нужен сервер». Не стоит волноваться на данном этапе – сейчас существует множество предложений по аренде серверов. Главные классы среди них– облачные и статические. Основная разница в том, что в случае облачного решения, вы платите по факту использования процессорного времени, объёма пересылаемого траффика и времени работы систем управления базами данных. В случае статического решения вы платите фиксированную арендную плату в месяц за конкретную машину с конкретными техническими характеристиками, которые потом в случае необходимости можно будет дополнить.

  • Здесь моя рекомендация будет следующей – определитесь с контентом на сервере, прежде чем программисты разработают базы данных и напишут API для взаимодействия с клиентами на мобильных устройствах.

Естественно, серверные сценарии пишутся также с прицелом на дальнейшую масштабируемость и сопровождение, однако не все серверные команды ( наша команда – исключение!) обращают внимание на такие вещи, потому изменение вида хранящегося контента, например, вы решили хранить на сервере ещё и паспортные данные сотрудников и добавить возможность их редактирования с клиента, примерно на этапе бета-версии, могут сильно задержать релиз и повлечь рефакторинг исходников как на сервере, так и на клиенте.

5353eb42b28ea4.88767484.gif

Ещё хотел бы отметить следующее. В последнее время встроенные покупки в приложениях приносят гораздо больше прибыли, нежели платные версии программы. Потому наверняка, поддавшись современным веяниям, вы заходите иметь такой функционал в своем продукте. Но будьте осторожны – особенно с платформой Android – приложения можно взломать, и, если контент не защищён должным образом, в скором времени ваша программа с полностью разблокированным функционалом может оказаться в свободном доступе и доход резко упадёт.

  • Не пренебрегайте хотя бы простейшей системой безопасности для защиты встроенных покупок – особенно, если контент хранится на сервере. Это, скорее всего, потребует дополнительных ресурсов и времени, особенно, если речь идет о серверной валидации купленного контента, но при грамотной реализации поможет избежать большинства атак и неплохо защитить контент.

Прямо спрашивайте и добавляйте в техническое задание пункт о защите контента, пускай даже просто проверки, установлено ли приложения напрямую из стора, это будет неплохой гарантией безопасности ваших доходов. Конечно, какой-нибудь очень добрый борец с системой и сторонник гегемонии FreeBSD может выложить свой логин и пароль от учетной записи с разблокированным и загруженным контентом, так что остаётся лишь нажать на кнопку «Восстановить покупки», но существуют технологии, позволяющие бороться и с такими атаками.

Что же, вы-таки решили, что вашему бизнесу просто необходимо приложение. Но вот незадача – база данных, которая теоретически должна обеспечивать бэкэнд будущего продукта была написана 10 лет назад, документации нет, писавший её программист уехал в США через Израиль, и, вполне возможно, написана она не под всем известную MySQL, а под PostgreSQL, или, вообще, вне шаблонов – No-sql! И, давайте совсем сгустим краски – представляет собой 20к строк кода в файле с расширением “.sql” . В такой ситуации не стоит отказываться от идеи любой интеграции с подобной базой данных. Но будьте осторожны – если после того, как серверная команда заявила о заведомо нереальных сроках написания сценариев серверной части и цена стала заметно выше средней – лучше поменяйте студию. Скорее всего, данная команда не имела опыта интеграции с подобной СУБД, а люди с опытом смогут провести профессиональный аудит и в будущем либо перевести сервис на другую СУБД, либо заниматься сопровождением существующей.

В заключении ещё раз повторюсь - прежде, чем программисты начали работу, всегда вмораживайте спецификации карты приложения, дизайна и функционала. Возьмите паузу на пару дней, изучите составленное тех. задание, подумайте, возможно, вы что-то не отразили в нем, сообщите об этом студии. Новые идеи лучше отнести к следующему билду, нежели вносить правки в текущий и задерживать релиз. Только в этом случае ваш продукт будет качественным и технологичным, выпущенным в срок и не имеющим проблем с review team в App Store и Windows Phone Store. 

 
разработка
сервер
серверная часть
приложения
мобильное приложение
рекомендация
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться