Comments 18
Интересная идея, но на хостинге я бы сэкономил в пользу GitHub Pages, используя таблицу как базу данных.
все же время отклика у гугл таблиц большое. тот же Гугл просит чтобы сайт отечал за 250 мсек (!), хотя лет 10 назад 1 секунда считалась нормой. сейчас нет, не норма. То есть данные надо "кэшировать" но можно в простом файле, не обязательно в БД. И про картинки - адрес фото - он временный, нельзя вставить картинку с адресом, как его показывает гугл. Надо скачать и отдавать от себя.
Нет, этот подход к вопросам бизнеса неправильный. В wordpress и других cms база данных, эксель это плоская база со всеми ограничениями. Работать в ексель тоже нужно уметь, это отдельный навык.
В итоге нет возможности ничего поменять без программиста, это не масштабируется на большое количество товара без потери скорости; нельзя подключить дополнительных админов, что бы данные не утекли. Утечка данных - это основная боль мелкого бизнеса, у них текучка , они этого боятся. И допущенный работник получает доступ сразу ко всему - тут и ошибки сразу на всю базу и саботаж и шпионаж от конкурентов и все остальные риски.
Где то у меня есть целые статьи, где я расписывал эти десятки возникающих проблем для сомневающихся клиентов, во времена когда я массово делал сайты. Проще научить админке или выбрать cms попроще для удобства, но в целом готовая цмс даёт не сопоставимый выигрыш по всем показателям в сравнении с ексель.
Что касается защиты данных - она ровно такая же как у любой CMS. А что собственно говоря вы хотите сохранить в секрете? Утечка чего вас пугает? Что такого есть в прейскуранте, чего вы публично не выкладываете на сайт. Не понимаю... Другое дело, если вы начинаете вместо сайта строить систему CRM хранить данные клиентов, телефонные номера и прочее.. Но статья о другом. О простом сайте с возможностью один раз сделать его и дать администратору работать с контентом.
CMS ставится за минуты и тоже дает администратору возможность работы с контентом, только на гораздо более профессиональном уровне.
Ексель не даёт выигрыша как база данных, наоборот сильно проигрывает. Это не удивительно, поскольку ексель и базы данных это разные продукты для разных целей. Можно ли сделать ексель как админку - можно, у меня где то есть такой проект, сам делал лет 6 назад, для тестирования. Только у меня был локальный файл ексель, редактируем файл на компьютере, за несколько секунд заливаем новый файл на хостинг и всё работает из нового файла.
Только если мы говорим про бизнес, то не нужно наступать на все грабли, уже всё сравнили и выводы сделали. Для бизнеса лучше цмс с базой данных и админкой из цмс. Ничего сложного в тех административных панелях нет, учатся за минуты.
Это решение для людей, которые хотят начать работать уже сейчас, а не отправляться на курсы администрирования MODX. А знаете сколько стоит обучение администрированию одной и отечественных систем сайтостроения? 60 тысяч рублей. Только для того чтобы научиться как заполнгить прейскурант.
И вы не прочитали наверное статью до конца. Exell нужен только как средство ввода данных. Потом по нажатию кнопки данные выгружаются в базу данных сайта или куда вам будет угодно.
Что касается выводов про бизнес - вы эти выводы делаете как разработчик или как представитель бизнеса? Я никогда на скрывал перед своими клиентами, что есть много разных CMS. Называл цену внедрения и они делали свой выбор.
Утечка чего вас пугает?
Данные поставшиков хранятся в цмс. Смотрят в панель - закончился товар и сразу заказывают. Делать две базы - в одной продукция, в другой контакты очень неудобно.
Количество продукции на складе, скорость продаж, поставщики. клиенты, цены закупки, себестоимость - при оглашении таких критических данных бизнес обанкротится за два дня.
вы куда то в другую сторону ушли. И вопросы которые сейчас поднимаете - это управленческие вопросы. Статья о другом. Статья о том, что есть вариант очень быстрого, понятного в работе и простого решения, не требующего обучения персонала. И этот вариант не отменяет других, тех, с которыми Вы привыкли работать.
Что касается лично моего мнения по этой бизнес теме - я лично как разработчик и как человек, имеющий опыт собственного бизнеса в торговле, считаю, что не надо вести в одном месте ваш публичный сайт и вашу внутреннюю бухгалтерскую кухню. Это не для дискуссии, это просто мое мнение. И если сайт будет отдельно, то тогда вы будете стремиться распространить полезную для вашего бизнеса информацию, а не бояться ее потерять.
Нет, этот подход к вопросам бизнеса неправильный.
Какое смелое, в духе последней инстанции, утверждение. Однако вызывает разве что улыбку, учитывая селлеров на различных маркетплейсах, которые активно используют Google таблицы как админ-панели для своего бизнеса.
который скачивает данные из гугл таблицы, пишем их в базу данных
Если все равно пишите в свою БД, то Гугл-таблица излишня. Например, для работы с БД есть отличная десктопная программа HeidiSQL - ее интерфейс - это та же Гугл или Excel таблица. Принцип работы такой же. Только надо прописать в настройках соединение с БД и всё. Данные хранятся в одном месте - в БД хоста, а не в двух местах как у вас.
Ловил себя на мысли, что, действительно, админку заменяет, если весь сайт на БД завязан.
"Гугл-таблица излишня" да нет же!!! Общий доступ, возможность комментировать, приглашать отписывать, работа с сотового телефона!
Я пожалуй тоже соглашусь, что раз есть своя бд и таблицы, то гугл таблица неуместна.
В качестве альтернативы, посмотрите headless cms, мне очень понравилась Directus. Ставиться просто в докере, работает с вашей БД без добавления своих полей в ваши таблицы, имеет красивую и удобную админ панель. Может хранить файлы как в s3, так и в файлах сервера. Никаких кастомных админ панелей или платных решений на laravel
Безопасность плачет
Безопасность неудобная, но нормальная. Что может случиться плохого - утечет наш "вэб-хук". То есть та ссылка, по которой мы обращаемся к себе на сервер. Ссылка только в статье удобочитаемая но я обращаю внимание, что ее надо сгенерировать случайным способом и использовать https. Допустим, даже произошла утечка нашего вэбхука, но что злоумышленник может сделать? Задедосить только. Внести подложную информацию - нет, не получится, потому что вэб хук просто сообщает, что надо считать данные, а данные считываются с конкретной spreadsheet. Даже диапазон в принципе можно не передавать, это вариация - передавать диапазон. Можно читать данные из строго заданного диапазона.
Другими словами: безопасность системы обеспечена ровно настолько, насколько ее обкспечил Гугл для своих таблиц. Если только сам пользователь не передаст злоумышленнику права на доступ к странице, ничего разместить на сайте будет нельзя.
Приведите свой сценрий атаки и ее последствий, будет больше конкретики - будет пища к размышлению.
а нельзя ли SSG - перегенерить весть сайт в HTML ? при максимум 1000 товаров их можно все загрузить в страницу индекса
Здесь в основе лежит потребность заказчика получить простой интерфейс управления товарами ну или контентом если хотите. Стоит человек за прилавком с сотовым телефоном включает отключает товары, дает скидки или генерит промокоды... а уж как эти данные превращаются в html код - это второй вопрос...конечно можно SSG, я для себя искал наименее затратный способ по времени, и чтобы работало.
Я бы не использовал Sheets API на сервере совсем, не вижу тут необходимости. Средствами Apps Script можно легко сформировать JSON вместе со ссылками на картинки и отправить все одним запросом.
Ограничение в 1000 товаров, поверьте, у вас сильно занижено...
Google Apps - мощнейшая штука, очень много чего можно реализовать. Так то там и к БД можно подключиться.
Универсальная админка к сайту — это Гугл Таблица