Развитие ядер для запуска приложений за 2019 год. Часть 1

Денис Гордиенко, руководитель Bright Mobile, об итогах развития собственных продуктов в 2019 году и планах на 2020. Рассказываю что и почему не получилось в ушедшем году и какие сделали выводы. В этой части буду говорить про ядро для маркетплейсов услуг, ядро для досок объявлений и сервис по обработке персданных в РФ.

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

Закрытие Сервиса ПИ

Год начался с того, что мы закрыли наш первый коробочный проект «Сервис ПИ». Домен уже недоступен, но что он из себя представлял можно посмотреть здесь. Изначально это было ядро для запуска маркетплейсов услуг с сайтом и приложниями, но в один прекрасный день мы поняли, что он слишком оброс функционалом, и с этим нужно было что-то делать.

Судите сами: у него было 37 экранов, причём, экранов и приложения, и сайта. Продавался он тогда в районе двухсот тысяч рублей, но ситуация была такова, что клиенту все эти экраны просто не требовались. Получалось, что клиент хотя и покупал продукт по низкой цене (ведь разработать с нуля всё это было ещё дороже), но переплачивал, так как из приобретённого часть так и оставалась для него ненужной.

По назначению использовалось лишь 50‑70% функционала, а остальное клиент попросту просил удалить. Нередко заказчики даже сами предлагали нам урезать продукт и продать им лишь то, что они хотели за полцены, но поскольку работа над сокращением функционала сама по себе требует дополнительных временных и трудовых затрат, такое предложение не устраивало уже нас.

Таким образом, покупка продукта отнимала у клиента лишнее время и деньги: нужно было удалить то, что ему не нужно, а также добавить доработки под идею. Такие манипуляции выставляли более жёсткие требования к гибкости ядра. Ядро, к слову, было на Битриксе, который уже не вытягивал заявленные функции и скорость.

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

Именно поэтому в конечном итоге мы приняли решение этот проект закрыть, но вместе с тем сделать новое ядро «RTPlatform».

Запуск RTPlatform

Мы решили сохранить в новом ядре идею маркетплейса, но сменить парадигму внедрения. Сервис ПИ продавался, как готовое решение с сайтом и приложением, на котором уже можно было тестировать MVP маркетплейса услуг. RTPlatform стал неким ядром, которое требует доработки, но не несёт избыточного функционала. То есть получается такой скелет, который дополняется «мясом» конкретной идеи.

Технически ушли от использования Битрикса, как серверной части, да и вообще от работы с реляционными БД. Ведь в маркетплейсе важна скорость — уведомления о заданиях, уведомления о новых откликах, сообщения в чате, это всё должно приходить моментально. Стали смотреть в сторону баз данных реального времени и больше всего понравилась Firebase. Больше всего зацепила готовая серверная инфраструктура от Гугла. Из основных плюшек, которые нам понравились выделю:

  • Возможность СМС-авторизации с бесплатными 10 000 СМС в месяц
  • Собственное хранилище файлов
  • Собственный push-сервис FCM
  • 100 онлайн подключений даже на бесплатном тарифе, с расширением до 200 000 за $25 и кластеризацией, если этого будет мало.
  • Мониторинг производительности. Очень удобная штука, чтобы посмотреть на что расходуется серверный трафик и оптимизировать нагрузку.

Возможно, кому-то из коллег будут полезны и другие фичи, вот полное описание тарифов с ценами.

Сами приложения реализовали кроссплатмформенно на Ionic.Framework. Изначально в нём было около девяти экранов – потом необходимый функционал вырос до пятнадцати. Мы учли прошлый опыт и сохранили лишь то, что нужно было всем клиентам Сервиса ПИ, отрезав 22 экрана и весь сайт, которые использовались далеко не во всех проектах. Благодаря этому смогли понизить стоимость продукта в начале года, когда он ещё был недостаточно оттестирован и доработан.

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

Итак, мы начали продажи нового ядра по стоимости в 50 тысяч рублей, потом, исправив все баги, увеличили её до 90 тысяч. Сейчас оно продаётся за 190 тыс. К изначальным 15 экранам и багфиксу добавилось несколько важных для старта фишек:

  • Делаем три произвольные доработки под клиента бесплатно. Это позволяет запустить более индивидуальное решение, даже при ограниченном бюджете на MVP
  • Переработано разделение функционала компонент и сервисов. Не вдаваясь в технические детали удалось увеличить скорость работы приложения до уровня натива.
  • Реализован паттерн отображения асинхронных данных в т.ч. отображение процесса загрузки при их отсутствии
  • Подписка на Push-уведомления перенесена на сервер для лучшего контроля подписки, теперь в мобильном приложении нужно только сохранить подписку — это удобно для программистов поддержки, которые далее развивают проекты клиентов.
  • Серверные функции переписаны на TypeScript и благодаря строгой типизации ошибок до сборки будет выявляться больше. Опять же, для программистов поддержки важно в паблик выложить проект без багов.

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

Структура экранов

На данный момент RTPlatform имеет такие экраны в ядре:

  1. Регистрация / авторизация [бесплатные 10 000 СМС в месяц]
  2. Список своих заявок
  3. Создание новой заявки
  4. Все заявки в сервисе [фильтруются по подпискам]
  5. Подписки на категории заявок [приходят push при новой заявке в подписанной категории]
  6. Просмотр заявки и отклик на неё [как в YouDo мастера отправляют предложения на заявку]
  7. Просмотр профиля мастера [c возможностью позвонить или написать в чат]
  8. Создание своего профиля мастера
  9. Список всех мастеров сервиса [альтернативный способ, если не хочется создавать свою заявку]
  10. Переписка с пользователем [у мастера показывается ссылка на профиль]
  11. Уведомления [список всех пришедших push — новые задания, новые отклики, сообщения в переписке, движения по балансу]
  12. О Сервисе [общая информация о приложении]
  13. Пользовательское соглашение [юридическая информация о сервисе]
  14. Баланс [движения по балансу мастера и интеграция с Яндекс.Деньгами, с возможностью изменить эквайера]
  15. Меню

По сравнению с Сервисом ПИ ядро стало куда проще функционально, но подготовленное к более серьёзным нагрузкам. Вместе с этим, использование Firebase повлекло за собой требования к обеспечению серверной части в юрисдикции РФ.

Тест идеи FireDump

К моей статье про разработку один из наших конкурентов, продающих схожее ядро для маркетплейсов услуг, написал несколько комментариев о нарушении законодательства РФ:

Речь о том, что вы втираете клиентам про Firebase, про сто миллионов чего-то там - они ведутся.Но проблема в том, что вы всё тупо храните там, потому что это очень просто, примитивно и дёшево в реализации.Но почему ваши клиенты не получают от вас информацию по 12 статье 152ФЗ?

Или инфраструктура Firebase переехала куда-то под Волгоград или в Химки чтобы можно было это использовать в качестве основного и по сути единственного хранилища ПД?

Руслан Семагин, Разработчик Сервиса поиска исполнителей, биржа услуг

Отбросив культуру общения Руслана в сухом остатке остаётся одна претензия к Firebase / нашей реализации:

  • Если приложение использует персональные данные пользователя, то обработка и прочие действия необходимо производить на территории РФ.

Вместе с тем, допускается одновременное использование ресурсов сервиса в РФ и зарубежом. Здесь важно сделать лирическое отступление и разобраться в целесообразности траты ресурсов.

Проблема курицы и яйца

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

  1. Составление требований по законодательству — это вопрос явно не разработчика. Если основатель собирается серьёзно зарабатывать с проекта, то потратить 10 тыс на консультацию юриста можно без проблем. В принципе, это и делали те наши клиенты, которые подписывали договора с бюджетом от 800 тыс за проект.
  2. Самый важный вопрос. Что мы собираемся делать — зарабатывать деньги или соответствовать закону?

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

По моему убеждённому мнению, нужно заниматься делом, а не бюрократией, иначе останешься с ооошкой, но без денег.

Перекладывая этот принцип на запуск стартапов, можно тестировать идею и проверять разные способы привлечения трафика нарушая закон, а вернуться к соблюдению юридической чистоты, когда появится уверенность в бизнес-модели. Можно заморочиться на соблюдение законодательства и потратить деньги на создание дублирующего РФ сервера, а потом понять, что нужно всё переделывать, т.к. идея не пошла.

К слову, по нашим оценкам сделать такой дубль — это всего 50‑70 тыс к сумме проекта, но, повторюсь, на мой взгляд — это нужно делать на второй-третьей версии, а то ведь можно совсем уйти в дебри и пойти регистрироваться оператором персональных данных, соблюдать закон о мессенджерах, получая лицензию в ФСБ, а, если вдруг у вас есть новостная лента и большое количество пользователей, то и закон о СМИ нависает…

Но, есть и более простое решение. Сам телефон — это 11 цифр, которые не являются объектом персональных данных. Ник или просто имя — тоже. Соответственно, в большинстве проектов можно избежать самого попадания под закон о персданных просто изменив формат собираемых данных. Если сильно страшно, но не хочется тратиться на дубликат сервера — это хорошее решение.

Вместе с тем, предполагаю, что не один Руслан боится проблем с Роскомнадзором и есть люди, которым нужны фишки Firebase, но есть страх получить претензии. Как раз для этого мы решили сделать Saas-решение c идеей хранилища персональных данных и соблюдения всех законодательных норм. Прошу написать мне на почту читателей, которых волнует этот вопрос и есть или планируется проект на firebase — мне сейчас важно собрать общую картину, чтобы грамотно сформулировать saas.

Ядро для приложений доски объявлений SalesBoard

Изначально наша идея заключалась в том, чтобы создать общую коробку, а также опциональные модули, которые будут приобретаться клиентом по желанию. Иными словами, реализовать всё, как в «Сервис ПИ», только более умным способом: создать конструктор из маленького ядра и деталей, которые он берёт лишь если оно ему нужно.

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

Доску SalesBoard мы запускали как отдельный продукт научившись на «горизонтальном продукте», но вс-равно пришли к тому, что доска объявлений и маркетплейс услуг, где есть либо объявления о заданиях, либо каталог исполнителей, это очень близкие сущности, где просто либо есть отклики на объявления, либо их нет. Всё остальное на 90% одинаковое.

Для доски, к концу года, вышла такая структура:

  1. Регистрация / авторизация [бесплатные 10 000 СМС в месяц]
  2. Список своих объявлений
  3. Создание нового объявления
  4. Все объявления в сервисе [фильтруются по категориям]
  5. Категории объявлений [приходят push при новой заявке в подписанной категории]
  6. Просмотр объявления с возможностью позвонить или написать во внутренний чат продавцу [как в Авито]
  7. Создание своего профиля продавца
  8. Просмотр профиля продавца
  9. Переписка с продавцом [у пользователя показывается ссылка на профиль]
  10. Уведомления [список всех пришедших push — новые объявления, сообщения в переписке, движения по балансу]
  11. О Сервисе [общая информация о приложении]
  12. Пользовательское соглашение [юридическая информация о сервисе]
  13. Баланс [движения по балансу продавца и интеграция с Яндекс.Деньгами, с возможностью изменить эквайера]
  14. Меню

На данный момент оба ядра продаются, как отдельные коробочные решения и как основа для индивидуальной разработки.

В заключение поделюсь статистикой запусков за 9 месяцев после первого релиза. Всего было заключено договоров на 27 проектов, из них 3 по той или иной причине не дошли до публикации, 5 были запущены на чистом ядре с бесплатными, либо небольшими доработками, остальные 19 — это либо кастомные проекты на основе ядра, которые уже запущены, либо те, которые в процессе разработки.

Некоторые приложения, которые уже запущены и не под NDA можно посмотреть в плейлисте:

Спасибо всем, кто продержался до конца статьи. Планирую, в ближайшем будущем написать ещё 2 части: про ядра для товарного маркетплейса и социальной сети, и про ядра, которые у нас не пошли с выводами почему так случилось.

PS Если вы мой коллега и занимаетесь разработкой сайтов или приложений, то напишите мне в ВК или Fb, за месяц бывает 5‑10 обращений, которые не профильны для моих продуктов и бывает нужно посоветовать грамотных разработчиков. Ценовой сегмент разный.

0
39 комментариев
Написать комментарий...
Руслан Семагин

Ох, это называется как прижали к стенке начал крутить задом.

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

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

И всё. Предельно же просто кажется. И вопрос автоматически закрывается.
А не заниматься очковтирательством.
Просвещение и предложение реализации это часть профессии, если только деятельность не сводится к тупому выгребанию бюджета.

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

Хотя конечно, учитывая что в реальной жизни ~99% покупателей такого рода ПО - заканчивают ничем потому что даже ничего и не начинают - им это как говорится зайдёт нормально. Но до первой же абузы. Потом начнутся страдания.

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

Что касается совершенно дурацкого и не умного вывода «…а то ведь можно совсем уйти в дебри и пойти регистрироваться оператором персональных данных, соблюдать закон о мессенджерах…» - вы не поверите, это не дебри как вы выразились, это прямая обязанность владельца проекта, и об этом разумеется он (владелец) также должен знать, но в этом случае скорее сам, т.к. это не связано с конкретной реализацией о которой он без уведомления не будет даже догадываться (ваш случай). Так что будет владелец это соблюдать или не будет - его дело, но представлять это как некую чушь по меньшей мере глупо и не серьёзно с вашей стороны.

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

Так что ок, принимается. Единственное что, с удовольствием бы почитал/посмотрел про вашу реализацию как вы выразились «дублирующего сервера», чувствую вот там будет где разгуляться, учитывая ваш уровень владения предметом.

Осталось теперь подтянуть терминологию в видео, а то иногда прям совсем позор.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Руслан, подскажите ссылочки на проекты Ваших клиентов, получивших статус оператора персданных и полностью соответствующих всем законам

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

Хотя за 60 тыс вполне неплохой софт уровня добротного дипломного проекта. Жаль только, что Вы пытаетесь самоутвердиться за счет моих статей, интересно было бы почитать Ваш авторский материал без подобной токсичности, ведь есть, наверное, чем поделиться, не только ж чужие разработки засирать умеете?

Ответить
Развернуть ветку
Руслан Семагин

Ой, Денис, вы прекратите уже притягивать сюда за уши если что-то не относится к теме. Я - читатель, не более. Я - ни на что не претендую, и никоим образом не самоутверждаюсь. Всё что мне нужно - у меня есть.

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

Если когда либо я, как и вы, или кто либо ещё, напишу статью, или сниму видео - я отвечу за себя и свой контент.
Но я ничего не пишу. Это не является ни достоинством, ни недостатком, так есть и всё.

Отмечу, что я ещё ничего не засирал, как вы выразились.
Я поставил вопрос, который пусть и не удобен для вас, но т.к. вы об этом даже и не думали, вам бы ещё и поблагодарить надо за этот вопрос.

К сожалению, ответить точно и адекватно вы на него не смогли. Ну чтож, как смогли, так смогли. Это лучше чем ничего.
А по сути для вас один только плюс, т.к. вы уже будете чесать затылок как выйти из ситуации.

Что касается ссылочек, опять таки, вы не передёргивайте, как увидите какой либо проект - у владельца и спросите, т.к. это исключительно его забота и от  зона ответственности.
Не умно и не серьёзно представлять это  для конечного клиента как нечто ерундовое и недостойное особого внимания, вот в чём дело. 

"А что касается технических вопросов... Как научитесь у себя в решении делать регистрацию через приложение или хотя бы не перезагружать экран по кнопке Назад, так и поговорим с Вами про архитектуру." - честно говоря даже не сразу понял о чём речь, а когда допёрло - понял, вы нашли какой-то где-то баг и как-бы мне его предъявили? А, ну ок, пусть будет, оставим специально, назовём имени вас.
Только не совсем понял при чём тут "архитектура", или вновь проблемы с терминологией?

Но если стоит вопрос о разборе, то можем и ваши исходники разобрать где нить на хабре.
Вы что-то в этой статье написали по старому "ядру", что там по каким-то причинам закрыли..., ну ну, только там они не совсем те, точнее скорее совсем не те в реальности. И толпа страдальцев осталась с этим наследием, и вот там-то есть что разобрать.
Это отвлёкся, один раз в качестве оффтопа, больше не буду :)

Ответить
Развернуть ветку
Виталий Подольский
 Но если стоит вопрос о разборе, то можем и ваши исходники разобрать где нить на хабре.

😂

Нечего там разбирать, тем более на Хабре. О Медиуме даже речи быть не может! Я видел его код (если он конечно его, а не его унылого программиста, что пришел с 1С), там дорога на https://govnokod.ru

Честно сказать, мне уже надоело эту дичь комментировать, но тут попалось упоминание вашего имени в статье... 

 поговорим с Вами про архитектуру. 

Очень смелое заявление! И веселое... Дениска знает что-нить про архитектуру?! Или он в очередной раз что то другое имел ввиду?!

О чем речь? О паттернах проектирования? Или что то вроде SOA?

@Денис Гордиенко по сути, Руслан все правильно написал, там даже запрос отправлен и ответ опубликован (на который зассали ответить). Так что сопели бы дальше в две дырочки, делая вид, что это не вас так раскатали на простых вещах.

И еще, по качеству кода: есть три основных уровня разработчика - junior, middle, senior. Так вот, человек писавший то, что я видел, носит почетный статус "дибилопер"

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Спасибо что Вы страдаете из раза в раз, но всё равно комментируете. Как всегда конструктивно и по теме. 

Ответить
Развернуть ветку
Виталий Подольский

Да не за что. Всегда рад помочь! Раз вам нравится, не ставлю и дальше без внимания.

Ответить
Развернуть ветку
CLOU D

с сентября персональные данные, это и телефон и почта - это официально, можно даже без имени

Ответить
Развернуть ветку
ugnich
 Технически ушли [...] от работы с реляционными БД. Ведь в маркетплейсе важна скорость...

Восхитительно. Вы не только в маркетплейсах, но ещё и в реляционных базах данных ничего не понимаете.

Ответить
Развернуть ветку
Игорь

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Игорь, эти «идиоты» запускают проекты в узких нишах, где аналогичных проектов нет. Выживаемость на третий год где-то 30%, зарабатывают на сервисе ~5% тех, кто запустился, выжил и не забил при первых проблемах. 

Ответить
Развернуть ветку
CLOU D

в узких нишах нужно еще объяснить зачем это им нужно, после того как еще найдешь эту самую узкую ца

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Само собой, что обращаются основатели, которые примерно уже представляют, как будут развивать свой проект

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

А в чем была проблема с этим если вы используете firebase?

Ответить
Развернуть ветку
Руслан Семагин

То о чём он пишет, там не было никакого FireBase, там у них была тупо одна таблица в основной БД (возможно до какой-то версии) в которую они пихали как могли, и статусы слушали используя адов треш.

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Да да, Руслан. Все уже поняли, что вы тут в облике Зорро-обличителя и инфраструктуру моего решения знаете лучше меня. Давайте уже отправляйте моих "недовольных клиентов", которых по Вашим же словам толпы в какой-то там группе вотсапа, с официальными претензиями. А то уже достали своим бульканьем, а по факту - пусто. Попахивает недобросовестной конкуренцией. Какие же у нас там штрафы по этому поводу? Вы же хорошо знаете последствия, судя по комментариям.

Ответить
Развернуть ветку
Руслан Семагин

Ох, Денис, и снова вы за своё.

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

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

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

"А то уже достали своим бульканьем, а по факту - пусто." - простите, что за бульканье, и что должно быть по факту "полно"?

Принимайте с достоинством, не передёргивая и не переводя стрелки.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Да мне все вопросы удобны, я всё понимаю, читатель, Руслан. Будем принимать меры. 

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Это было в предыдущем ядре, которое работало с серверной частью на Битриксе + mySQL. У Firebase само собой такой беды нет.

Ответить
Развернуть ветку
John Doe

Про дублирубующий сервер очень интересно было бы почитать во всех технических подробностях

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Пока собираю информацию от тех, кому это реально нужно. Общая суть сводится к следующему: 

1. Собрать с заинтересованных перечень используемых персданных для понимания масштаба трагедии.
2. В законе есть оговорка, что допускается дублирование обработки. То есть можно работать с зарубежным датацентром параллельно с российским. 
3. Делается российский дублёр, который встраивается в инфраструктуру проекта. Например, приложение отправляет дубликат запроса в Firebase и на VDS в мухосранске, чисто чтоб соблюсти закон. 
4. Мухосранский VDS Полностью дублирует процессы по созданю, обработке, удалению и прочим манипуляциям с персданными, которые есть в реальной инфраструктуре проекта, но "удар" не держит и служит чисто, как отмазка для закона, хранящая нужные логи и персданные.

Если в Ваших проектах есть использование зарубежных ДЦ, напишите мне, обменяемся опытом.

Ответить
Развернуть ветку
Руслан Семагин

Не в ту сторону копаете.

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

Иными словами, вы только читать по сути из FireBase можете, при такой формулировке и позиции. А все ключевые операции проводить только в РФ.

Ответить
Развернуть ветку
Руслан Семагин

Иными словами, FireBase это хороший инструмент, для реализации каких-либо задач, но он не может являться единственным хранилищем несмотря на все увиденные вами преимущества. Как-бы мир разработки немного сложнее, и очередей из проектов где только FB на горизонте не видно. Не задумывались об этом?

Ответить
Развернуть ветку
Виталий Подольский
FireBase это хороший инструмент, для реализации каких-либо задач

FireBase - еще та гадость. То он авторизацию не шлет, то еще что не хочет нормально исполнять. По мне, проще написать свой серверный слой (хоть я не серверник), ну и расширять/масштабировать по потребностям.

У меня подозрение про дублирующий сервер... Если он и будет, то это скорей всего:https://github.com/parse-community/parse-server

Я честно сказать удивлен, что @Денис Гордиенко его не стал пользовать вместо гуглового выкидыша. Но да ладно, может его в гугле заблокировали, когда он гуглить пытался =)

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Вы само собой лучше гугла напишите, кто ж спорит. 

Ответить
Развернуть ветку
Виталий Подольский

Свой баг я могу поправить, коробочное решение НЕТ. Просто признайтесь, что такого курса не нашли )

Ответить
Развернуть ветку
Артём Лисовский

Денис, сосед, при всём уважении, займитесь чем-нибудь более полезным. Запилить копию Uber'а/доски объявлений/.. может любой, только зачем? Все понимают, что без десятка миллионов бюджета это мертворождение. И вы должны это понимать лучше других, но продолжаете заниматься распродажей платформ для хомяков. Я понимаю - деньги они такие, но это wrong way, имхо.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

К нам как раз за ядром и идут «любые» кто попробовал запилить с фрилансером уберлайк а вышло, что пуши не работают, на 100 заявках приложение тупит, в мессенджере экран обновляется. Таких поделок насмотрелся за 3 года кучу. 

что касается 10 млн, я уверен, дать любому, как Вы говорите 10 млн, так он просрет их заработав, к примеру 500 тыс. только смысл то какой? Я считаю, что пока человек не набьёт все шишки на бюджете в 100 тыс на раскрутку, то миллионы ему давать нельзя. А для таких тестов и подходит готовое решение, которое я продаю. Опять же смысл пилить полгода-год кастом, чтоб потестить каналы и саму идею?

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

Ответить
Развернуть ветку
Артём Лисовский

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

Для первых двух надо реально много денег на продвижение или шанс успеха вашего клиента будет безумно мал(если есть деньги на продвижение, то скорее всего он не купит у вас mvp за ваши ценники). Третье неактуально почти ни для кого - все кто пытается запихнуть свой "дико популярный" интернет-магазин / доставку в кастомное приложение никогда его не окупают - надеюсь тут вы со мной спорить не будете.
Поэтому для "поиграться" подойдет codecanyon за 20$ + пара десятков часов фрилансера.

на 100 заявках приложение тупит

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

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Егор Рабцевич

А я могу вот лично в Ваш и по той же теме критиковать. Начать надо или все таки перестанете людей обманывать? Либо пишите правду что продаёте дешевое говно на попробовать, а сделать нормально не получится не у Вас не переделать это после Вас, либо уже пора уйти с темы...
Являясь стороной пострадавшей, но не гремевшей «маркетплейсами» искренне не хочу что бы кто то отдавал Вам иной раз единственные средства просто за «поболтать» с Вами о «экспертизе в теме» и «топ 20 в мобильной разработке»

Ответить
Развернуть ветку
Виталий Подольский

Что и требовалось доказать для упоротого @Денис Гордиенко ! Есть что сказать по этому поводу? Мне бы было интересно послушать, да и @Руслан Семагин наверняка подключится. А то тут пачки пафосных статей по теме, какие они все классные кодеры, дают людям реализовать мечту не за дорого =) Что нейтив, это не более чем развод заказчика на бабки (при этом путая нейтив с чем то другим).

Вам сочувствую! Если будет желание, постучитесь в личку, постараюсь подсказать как попробовать вытащить проект. Но допиливать его за Денискиными дибилоперами я не буду!

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Что Вас не устроило в 100к подключениях?

Ответить
Развернуть ветку
Denis Kiselev

На бесплатном плане - написано 100 подключений к бд, не 100к

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Спасибо, действительно, бесплатным не пользуемся, поэтому проглядел, когда переписывал. В статье поправил.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Почему?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
36 комментариев
Раскрывать всегда