— FB всех кинул!
— FB пошел по пути microsoft и google!
— Почему вы нам рекомендовали делать приложение на Parse?
— Что нам теперь делать!?
Такие, а то и более жесткие сообщения мы наблюдаем на каналах связи 65apps последние несколько дней.
Новость о закрытии Parse всколыхнула рынок мобильной разработки. Тут же возникло 100500 «альтернатив парсу». Что же произошло и как с этим жить?
Пара слов про Parse
Если вы не технарь, то можете и не знать, что под капотом у вашего мобильного приложения сидит Parse. Что это за зверь?
Parse — это MBaaS платформа (mobile backend as a service), которая дает возможность за короткий срок создать бэкенд для мобильных или веб-приложений. Функциональность серверной стороны достаточно обширна, она включает хранение данных, push-сообщения, аналитику, администрирование пользователей, серверный код, SDK на популярные платформы, фоновые задачи, аналитика падений/ошибок подключенного приложения.
Не так давно, в 2013 году, Parse был куплен Фейсбуком за 85 млн долларов. Авторитетные ребята обещали развивать и поддерживать платформу, но 28 января 2016 года они объявили о грядущем через год прекращении работы сервиса.
Это действительно можно воспринимать как подставу. В данный момент в сервисе крутится более 500 тысяч приложений, и всем этим приложениям теперь необходимо куда-либо мигрировать. Опытные бэкенд-разработчики с этим справятся без проблем, а у остальных могут возникнуть вопросы.
Специально для вас мы проанализировали сотни различных способов и ниже опишем возможные варианты решения задачи.
Вариант 1: Свой Parse Server
В своем обращении Parse, кроме заявления о закрытии, сообщил, что они выкладывают часть исходного кода проекта в open-sourse. Конкретно это Parse Server, который реализует часть функциональности сервиса. Если у вас приложение, которое только частично использует функциональность Parse, то одним из самых быстрых и простых решений может являться разворачивание собственного сервера Parse. По умолчанию разработчики предлагают для этого использовать Heroku, но их цены всегда были достаточно кусачими. Мы рекомендуем развернуть Parse Server на vps-серверах Digital Ocean или на подобных им российских аналогах. В сети появилось много гайдов по миграции с Parse на Digital Ocean, нам понравилось, как это сделано здесь и здесь.
Из минусов такого варианта стоит отметить, что в документации к Parse указано, что выложенная ими версия будет немного отличаться от той, что на самом Parse, и тут могут быть проблемы. По мнению аналитиков, потеряются следующие вещи:
- интерфейс администрирования, панель управления;
- система деплоя;
- аналитика;
- авторизация через емайлы, твиттер;
- глобальные настройки;
- проверка внутренних покупок;
- отправка емайлов;
- фоновые задачи;
- механизм уведомлений (webhooks).
Также в open-sourse не попал функционал пушей, поэтому их логику необходимо будет переписать с использованием другого сервиса.
Вариант 2: Миграция на другую MBaaS платформу
В связи с закрытием Parse многие MBaaS платформы поспешили написать инструмент миграции с сервиса Parse в свой. Все правильно, ребята ловят момент, когда лидер уходит с рынка. Аналогов Parse достаточно много, они в разной степени реализуют ту функциональность, что есть в Parse, а иногда и предоставляют что-то новое. Пока очень уверенно выглядит Amazon с его AWS и AWS Mobile Hub. Google не отстает и имеет собственную платформу под названием Firebase. Microsoft также предлагает неплохое решение Azure.
Другое дело, что таких желающих чересчур много. Только на GitHub энтузиасты собрали 100 вариантов, и это далеко не окончательный список. Причем по ссылке выше есть аналоги как самой платформы, так и отдельных частей того функционала, которые предоставлял Parse. Кроме того, мы уверены, что в скором времени появятся сервисы, основанные на Parse Server и дублирующие работу оригинального Parse на 100%.
Основной минус такого переноса в том, что, как и сейчас, мы не можем быть уверены, что сервис не закроется через некоторое время. Также при миграции на другие MBaaS сервисы придется переписать значительную часть серверного кода, если он был. И особенно сложно будет тем, кто имеет в приложении сложную логику или интеграцию Parse с другими сервисами.
Вариант 3: Написание собственного бэкенда
Если ваш проект достаточно большой, требователен к нагрузкам, то оптимальным вариантом будет написание собственного бэкенда. Это обеспечит наибольшую гибкость и производительность системы, 100% кода системы будут в ваших руках и вы сами будете следить за его актуальностью и работоспособностью.
А основной минус этого варианта известен: собственная разработка бэкенда неизбежно повлечет за собой увеличение стоимости поддержания работы системы.
Алгоритм дальнейших действий
Итак, прецедент с FB наглядно демонстрирует, что MBaaS платформы хороши для реализации и проверки первоначальной идеи (MVP), но в долгосрочной перспективе вы не можете полагаться на них, так как могут возникнуть непредвиденные обстоятельства, в связи с которыми сервис прекратит работу. Написание своего парс-сервера потребует отдельного решения задач, функционал которых не будет поддерживаться. А собственный бэкенд может быть достаточно дорогим.
Исходя из вышесказанного, выбор оптимального варианта миграции — важнейший на сегодня момент для всех пользователей Parse (по крайней мере, до тех пор, пока не будет реализован и отлажен механизм автоматического переноса — кое-кто уже бьет себя пяткой в грудь, что через несколько недель мигрировать на их BaaS можно будет на раз-два).
Поэтому ваш алгоритм действий сейчас может быть таким:
- Если вам доподлинно не известно, необходимо выяснить, использует ли ваше приложение Parse. Это можно сделать посмотрев документацию\договор по проекту, либо напрямую спросить у разработчиков приложения. Если же документов по каким-то причинам нет, а разработчик недоступен, можете обратиться к экспертам. Правда, им для работы понадобится исходный код приложения.
- Проанализировать, какой вариант работы с серверными данными вам больше подходит. В процессе анализа вы, в первую очередь, должны ответить на вопросы:
— Есть ли сервисы, позволяющие произвести простой перенос с минимальным переписыванием кода?
— Сколько зависимостей в бэкенде и насколько трудоемким будет изменение процессов?
— Не будет ли проще реорганизовать всё? - Найти серверного разработчика, который займется переносом серверного кода.
- Не забыть о проведении тщательного процесса QA во время и после миграции.
А можете обратиться к нам. Мы проанализируем ваше мобильное приложение и выдадим экспертное заключение о наиболее подходящем варианте дальнейшей работы. И денег за это не возьмем. :)