Ещё не определился. Сложный выбор.
Слово "архитектура" в этой простыне выглядит как случайное недоразумение.
А советы "архитектора"..., ну, уволил бы сразу.
Денис, пора таки прекращать срамиться на технические темы, лучше по старинке, про общую водяную воду.
Без обид, ну правда же...
Николай, а атаку идти не стоит. Я с Вами не дискутирую. Прочитайте внимательно мой комментарий, и найдите в нём желания бесплатного, или что-то в этом роде. Написано же, это пример, иллюстрация того как иногда бывает проснувшись утром, и когда к этому не готов. Всё. Ничего больше.
Ещё раз, в хорошей архитектуре не может быть такого узкого места, каким является облако когда оно одно и всё, ничего больше. Это исключительно моё мнение, и я его не навязываю.
Я работал в компании, средний счёт которой был на уровне 100 тысяч долларов месяц. И никто не жаловался.Так работайте на здоровье, вопрос то в чём?
Бояться облаков действительно не стоит, но и важно понимать, что облако не может в хорошей архитектуре являться единственным хранилищем данных, единственным сервисом и т.д.
По поводу "хорошего трафика", это да, но ситуации бывают разные.
Приведу конкретный пример (см. скриншот), один клиент в прошлом году получил списание в пользу гугла за использование облачных сервисов в размере 14000 долларов США за один календарный месяц. Да, это не опечатка.
Там было списание за несколько картографических сервисов, сумма накапала за месяц, списана единовременно по окончании отчётного периода.
У человека была привязана бизнесовая карта, это та, которая напрямую к расчётному счёту привязана, плюс деньги были списаны в минус, банк это позволяет вполне.
Этот пример конечно не относится конкретно к FireBase, это просто иллюстрация того, как бывает иногда в реальности.
И это главная ошибка.
Своевременная отправка возражений должна быть как угодно, тем более уже что называется назрел конфликт.
Возражения имеются ввиду на бумаге с отправкой сканов и оригиналов в догонку.
"...но блин почему Денис Гордиенко везде заявляет обратное...." - ну, продавать себя никто не запретит в принципе, поэтому и нужно вникать в детали и информацию брать из разных источников. И главное не пренебрегать формальностями.
Итого в целом:
Не устаю повторять (в том числе клиентам), нельзя на базе какой-либо коробки построить большой проект. На чудо не нужно надеяться.
Коробка - это чисто поиграться в стартапера, не более.
Можно использовать лишь тогда, когда человек лично может и готов делать какие-либо работы по проекту. Всегда когда начинаются доработки, это как правило несколько порядков от стоимости коробки в конечном счёте, к чему большинство не готовы, ни морально, не финансово.
Коробка может хорошо если как говорится посмотрели, всё подходит как есть и ничего не надо, или надо мало и можете сами - можно брать.
Это искренне и честно, моё субъективное мнение.
А самое главное - что это (доработки) лишено всяческого смысла, потому что за доработками тянется балласт различных составляющих (платформа, неиспользуемые функции и пр.), что в результате зачастую не приносит ничего кроме головной боли и бесконечного сложного дебага.
Общее:
Чудес не бывает, если вы имеете «имперские амбиции» и не имеете денег - можно хоть сто коробок купить - результат будет нулевой.
Доработки готового ПО - это заблуждение, потому что даже имея деньги результат всё равно будет нулевой, потому что никакой разработчик не примет проект «как родного», и не будет над ним сидеть 24/7, а будет только выполнять конкретные требования, и будет это делать до поры до времени пока не надоест, а оно 148% надоест. Потому что частный проект - это частный случай, разработчик к нему не прикипит на вечно.
Так называемые «доработки силами стороннего программиста» - это ещё большее заблуждение. Большинство - интроверты. Подходы, квалификация, методы… - у всех разные. Вникать в нечто написанное десятком других ДО - никто не будет, и всё пойдёт по бесконечному кругу. Наверняка не раз слышали стандартный ответ: «нужно всё переписать».
«Подбор программиста в штат» - ещё большая дичь. Потому что хороший специалист работу не ищет, она его ищет сама. Хороший специалист если не трудоустроен, то ведёт свою деятельность самостоятельно, имеет широкий кругозор, интересуется и осваивает новые технологии/ЯП и т.д., и не пойдёт работать в конкретный непонятный микро-проект, на непонятном и ограниченном стеке, написанный хз кем и как.
Извиняюсь если много собрал и несколько сумбурно.
Безотносительно темы:
Единая проблема многих заказчиков - посредственный подход к оформлению и проработке деталей проекта, игнорирование и зачастую «юмористическое» отношение к составлению технического задания, в надежде на то, что «вроде всё проговорили значит проект будет соответствовать ожиданиям…» - Нет, он не будет соответствовать ожиданиям.
Вообще никакой проект не будет соответствовать ожиданиям без скрупулёзно составленного технического задания на уровне фанатизма.
Отсутствие фанатизма при составлении технического задания и соблюдении всех формальных процедур возможно, и приходит со временем в процессе длительной работы, когда люди уже достаточно хорошо знают друг-друга, понимают кто что может выдать, каковы компетенции, чего ожидать, с учётом накопленного опыта взаимодействия по текущему/прошлому проекту.
Составление технического задания это всегда больной вопрос для заказчика, потому что разработчик его (ТЗ) ждёт, а никакой заказчик его дать самостоятельно не способен, за редкими исключениями.
Соответственно, если своими силами, или в результате коллегиального обсуждения ТЗ составить не удаётся - лучше его заказать. Да, это отдельная статья расходов, но оно того стоит, т.к.:
Составив раз - это хорошая основа для собственного переиспользования в будущем с поправкой на проект.
В процессе его (ТЗ) разработки, как правило, заказчику и/или исполнителю раскрываются детали о которых они ранее не думали и не учитывали (если составитель не имеет цели что-либо скрыть/умолчать).
Корректное, не расплывчатое ТЗ с чёткими формулировками и техническими/технологическими требованиями однозначно дисциплинирует исполнителя, и с высокой степенью вероятности сильно укрепляет позиции добросовестного заказчика в случае судебных разбирательств или предварительной претензионной работы, и в случае судебного разбирательства существенно повышает шансы на взыскание/компенсацию.
Тоже самое что в п.3, только для исполнителя.
Есть и минусы:
Зачастую такой подход с учётом новых деталей проекта даёт увеличение стоимости проекта.
Наличие ТЗ не предусматривает и не учитывает изменения взглядов заказчика на проект, особенно если разработка занимает продолжительный период времени. Т.е. Если в процессе, условно через полгода заказчику проект «разонравился» - придётся заплатить.
По теме:
Конечно, наверняка за 8 (или сколько там) месяцев материала у вас сильно больше чем эти несколько скриншотов. Соответственно детали скрыты, поэтому что-то конкретное тут сложно понять. Но, если всё что я написал выше не ваш случай, и всё было надлежащим образом оформлено, то нужно более основательно подойти к вопросу и продолжить разбирательства.
Но если в суде ставился вопрос наличия проводимых работ в рамках абонентского обслуживания в принципе, и если либо подписанные акты, либо автоматически принятые например в следствие истёкшего срока возражений по актам - то хз что тут оспаривать. Для арбитража то всё равно, есть текст договора, если фактические обстоятельства - результат решение.
Оснований настаивать на экспертизе я так понимаю у вас не было, в плане того что если вы оспаривали время, то на какие вопросы должен ответить эксперт?
Если речь о технической экспертизе, то это наверное отдельный иск, не об абонентском обслуживании. Опять таки, на какие вопросы должна ответить экспертиза? Т.е. например прописаны некие требования, они не соблюдены и т.д.
Если не было никаких конкретных требований, то экспертиза для вас автоматически в результате обернётся расходами без удовлетворительного результата.
Экспертиза не отвечает просто на вопрос что там в проекте говнокод или не говнокод, т.к. Это неформальное понятие всё таки :)
Чисто по человечески всё разумеется понятно конечно же.
Иными словами, FireBase это хороший инструмент, для реализации каких-либо задач, но он не может являться единственным хранилищем несмотря на все увиденные вами преимущества. Как-бы мир разработки немного сложнее, и очередей из проектов где только FB на горизонте не видно. Не задумывались об этом?
Не в ту сторону копаете.
Если ещё раз внимательно посмотрите на такой скользкий момент из ответа РКН (см. скриншот), то ваше приложение по факту только читать может, без самых важных операций. Понимаете где подвох?
А то что описали выше вы - эту схему не реализует, т.к. вы дублируете указанные операции, т.е. фактически выполняете их там-же откуда и читаете.
Иными словами, вы только читать по сути из FireBase можете, при такой формулировке и позиции. А все ключевые операции проводить только в РФ.
Ох, Денис, и снова вы за своё.
Ну да ладно, видимо привычка, что поделать.
Мне нет необходимости, или какой либо нужды отправлять кого-либо куда-либо.
Я - читатель вашего так сказать блога.
Никаким другим образом не представляюсь, и как и другие читатели участвую в обсуждениях вашего контента, или не участвую. Я ни с кем не конкурирую ни в какой сфере, и не обозначаю свою деятельность, т.к. моя деятельность не имеет отношения к предмету статьи. Пытаетесь изобличить тут только вы. Это исключительно ваше право.
Чем там вам попахивает, это вам виднее, не могу знать, честно.
Ещё раз, вам был задан неудобный вопрос, и как выяснилось видимо случайно, вы о нём не думали, соответственно вот подумайте и примите меры, если вам это нужно, или не принимайте мер.
Гораздо лучше получить этот вопрос в обсуждениях, нежели действительно в реальном проекте. Но это мне так кажется, возможно вам комфортнее вовсе не обсуждать ничего неудобного.
Но явно не стоит в рамках вашего контента как-бы обходить или принижать значение важных деталей, которые вам или мне могут не нравится (ФЗ), но ни вы и не я их навязываете, и накладываете определённые обязательства.
"А то уже достали своим бульканьем, а по факту - пусто." - простите, что за бульканье, и что должно быть по факту "полно"?
Принимайте с достоинством, не передёргивая и не переводя стрелки.
Руслан Семагин
https://youtu.be/LM18xGeZPZ8