Pull to refresh

Comments 15

Не уверен, что есть смысл полностью уходить с Firebase. Их авторизацию можно использовать без всего остального, и она очень удобна на мой взгляд.

Если говорить про базы, то да, если вам нужны ACID транзакции, Firebase базы уже становятся не лучшим решением. Но это всё про бизнес требования и их решения. Вы скорее всего пропустили нужный момент миграции. Но частично эти проблемы можно решить с помощью cloud functions и state машин. Собственно мы это и делаем, но проект небольшой.

Резюмируя - Firebase не так плох, но нужно понимать, когда его перестаёт хватать. Он и правда хорошо экономит на старте.

Сервис не плох, но вот авторизация по SMS коду перестала присылать сообщения. Это длится уже пару-тройку месяцев. Работает раз через десять. Может какие проблемы у мобильных операторов в нашем регионе, но смс не приходит. Связь с сервисом есть, API работает, в личном кабинете видно телефон, на который пришел запрос авторизации, а дальше тишина.

SMS сам по себе довольно плохой канал для передачи какой бы то ни было информации. По-возможности лучше использовать интернет-канал - push, мессенджеры. Да даже голосовые звонки надежнее SMS.

Тут беда, как мне кажется, в том, что проект позволял приложениям сразу писать в Firebase Database. Это просто и, одновременно, разрушительно. Если сделать все записи только через API, реализованный (например) на Functions, все проблемы с разрушением структуры, дублированием и т.п. уйдут.

Иными словами: неверная архитектура как при проектировании, так и при принятии решения об уходе с платформы.

Стартап, данные хранились тоже в Firebase.

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

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

А как бы вы организовали в Cloud Firestore хранение данных для приложения аля Tinder, где нужно выдавать пользователю анкеты, на которые он ранее не реагировал?
UFO landed and left these words here

Неча на зеркало пенять, коли рожа крива.

По поводу разных платформ неверно. Было приложение на Android, iOS и веб версия. Firebase хорошо подошло для аналитики и краш репортов. Также у них есть интересный функционал для тестирования приложений. Наша личная проблема была то что мы работали на Android и iOS без мультиплатформенной среды. Когда закончился переход на Flutter, стало намного легче.

Посоветуйте группу или сообщество русс.яз по firebase , буду признателен любым материалам , спасибо !

При всем уважении, но большая часть описанных в статье проблем не имеют отношения к конкретной используемой СУБД, а очевидно являются проблемами архитектуры, точнее отсутствия управления рисками на этапе проектирования валидации потоков данных и консистентности глобального состояния для совокупности клиентов.

Sign up to leave a comment.

Information

Website
inlyit.com
Registered
Founded
Employees
31–50 employees
Location
Россия