Можно ли использовать firebase в чистом виде для приложения интернет-магазина?
Здравствуйте.
Один из лекторов на одной конференции сказал, что firebase хорош, если у вас есть куча пользователей и каждый пользователь заходит к себе в кабинет и что-то там делает. В интернет-магазине этот самый кабинет - его личный кабинет буквально. Это индивидуальная часть для каждого пользователя. Firebase хорош для этого. Но как быть с той самой общей частью (причем интернет-магазин здесь используется только как модель, схема может быть применена не только к магазину)? Например, есть перечень структурированных элементов, которые может просматривать каждый пользователь, и каждый пользователь может добавлять себе в "личную зону" что-то. Этой общей частью управляет администрация приложения.
Нормальное ли это применение для Firebase?
Тогда по-другому. Только начинаю изучение и апробирование firebase. Концепция мне сильно понравилась. Возникает логичное желание засунуть эту в хорошем смысле "белиберду" везде. Имеет ли тогда вообще какой-нибудь смысл использовать firebase в модели интернет-магазина? В чистом виде, видимо, нет...
Тогда как должно выглядеть хранение данных и обмен этими данными? Стандартный REST API на php в качестве "задницы" на каком-нибудь хостинге для всех товаров и личных кабинетов пользователей. Куда может "встать" firebase в этой схеме?
Из функционала в приложении будет real-time чат с администрацией, уведомления об акциях, новых товарах и пр. оперативная информация. Авторизацию friebase'вскую тоже не "прикрутить"? Какого место firebase в общей картине, если вообще нужно его выделять?..
Не буду предварять ответ фразой "не сочтите за дерзость", "извините, но..." или "не обижайтесь... (я же не знаю что вы за человек, вдруг обидчивый)", т.к. это не дерзость и не требует извинения, и тем более не должно быть обидно адекватному человеку. Вы мне уже отвечали, спасибо вам за это, поэтому пишу с "заходом". Можете, конечно, добавить меня в "черный список", но я просто пишу прямо (видите, как мягко обернул, чтобы не обидеть и не отбить желание отвечать :), а мне как раз ответы нужны, а не ваши обиды и агрессия ). Вы сейчас говорите как исполнитель заказчику. )
Я не продукт у вас заказываю, я изучающий технологию разработчик. ) Бюджет тут вообще ни при чем. Интерес - академический. Я думал, что это очевидно, но если нет, то расширю вопрос в ваших терминах.
Какое бы, например (это ключевое для того, чтобы понять суть, рассмотрев реальный кейс применения), могло быть ТЗ (естественно, в минимальном объеме, достаточном для понимания необходимости применения или неприменения firebase, я не продукт заказываю... это еще раз... на всякий случай), чтобы было оправдано применение firebase + реляционная база данных?
Оффтоп: не могу не вспомнить анекдот, по-доброму. ) Американский форум. Задаёшь вопрос, потом тебе отвечают.
Израильский форум. Задаёшь вопрос, потом тебе задают вопрос.
Русский форум. Задаёшь вопрос, потом тебе долго рассказывают,
какой ты мудак.
havemanyquestions, вместо предисловия лучше нажимайте линк "Ответить"
Как исследователь вы должны _самостоятельно_ решить, что и в каком случае лучше и почему
Простой пример - в тз прямо указано использование технологии или стека
команда состоит из фанатов serverless или из фронтендеров, которым лень пилить бек
Я не вижу нормального кейса для использование связки фаебейз и РСУБД
ПС: Вы видимо мало общаетесь на англоязычных ресурсах
Если вы общаетесь на англоязычных ресурсах больше, чем я, то да, очевидно, что в сравнении с вами мало. Я этого не знаю, и тем не менее пусть это будет так, как вы говорите. Для меня этого достаточно (основной критерий этого самого "много/мало") и это продуктивно. Не количество этого общения определяет результат, а его качество. Или по-другому. Вам нужен месяц, чтобы поднять 100 кг штангу, а я буду год тренироваться и не подниму. Для меня и года будет много, а вам и дня не надо. Все относительно. )
"Я не вижу нормального кейса для использование связки фаебейз и РСУБД" - по существу, спасибо.
Простой пример - в тз прямо указано использование технологии или стека
команда состоит из фанатов serverless или из фронтендеров, которым лень пилить бек
Чрезмерно простой пример. Появление технологии было обусловлено какими-то исходными проблемами, которые эта технология была призвана решить. И наверняка основным требованием не было создание еще одного слова для добавления его в ТЗ. Это все философия. Я - про конкретные ситуации применения. Возможно, кто-то сталкивался с оправданной комбинацией...
Суть понял. Чтобы не уйти не туда в обсуждении на данный момент принимаю ответ, чтобы не потратить ваше время впустую. Если будут другие версии у других пользователей - не буду против.
sim3x, т.е., если сильно утрированно, это инструмент, который слеплен на "своем поле" своими же, чтобы сильно не отвлекаться на огород за забором? А по вашему, если взять за данность, что это просто удобно, то где это удобство заканчивается, за которым имеет смысл уже вернуться к классической схеме? Какой-нибудь чат (а-ля фейсбуковский, сделанный с помощью их же React'а, выросшего из этого же чата) с обновлением данных в реальном времени? Это, наверное, самое яркое и оправданное применение firebase'а?
Опять же... есть сокеты...
т.е., если сильно утрированно, это инструмент, который слеплен на "своем поле" своими же, чтобы сильно не отвлекаться на огород за забором?
да
А по вашему, если взять за данность, что это просто удобно, то где это удобство заканчивается, за которым имеет смысл уже вернуться к классической схеме?
если в доках нет прямого вашего конкретного примера использования = вам придется делать костыль
Пороговое количество костылей у разных команд разное
Какой-нибудь чат (а-ля фейсбуковский, сделанный с помощью их же React'а, выросшего из этого же чата) с обновлением данных в реальном времени?
чат твича был примером. О багах в нем ходят легенды
Это, наверное, самое яркое и оправданное применение firebase'а?
оправданное применение - легкое приложение с визуализацией чего либо, без нагрузок и большого количества юзеров
оправданное применение - легкое приложение с визуализацией чего либо, без нагрузок и большого количества юзеров
Можете привести какие-нибудь реально существующие приложения в качестве примера, чтобы оценить, что это за ниша такая? И кстати, гугл же вроде как заявляет, что может быть более (в планах сказано) 100k одновременных пользователей, а это сильно популярную штуку надо придумать, чтобы разом столько народу висело. Видимо, это пока просто заявление, много багов?
которые не стоит применять для чатов
Почему?
Видится мне, что чат - это самое народное применение firebase. )
Сложный
Средний
Простой
