Доступ по ссылке - от него рано или поздно администратор таблицы захочет отказаться и перейти на доступ по учетке. Обзаведется учеткой гугла, да, она не у всех есть :) и попросит повысить безопасность...
Почему Postgres - это маленькая БД? Он масштабируется на любой объем данных, здесь вы кажется не правы. Это просто придирка, комментарий в другом:
База данных - это не только инструментарий и табличная алгебра (очень хоргошая кстати), но и куча других накладных вещей, в микросервисах лишних. Хотя тот же постгрес позволяет отключить WAL для таблиц, то есть не вести журналирование при модификации данных., он все же требует подключения, проверки прав, создание нового процесса. И, кстати, при небольших данных, наверное не более чем 8Кб, то есть одна data-page, постгрес не станет применять индекс, все сделает брутальным способом, построчным сравненим и т.п. и т.д.
И даже если индекс будет применяться, то на на таблице в 1000 строк при применении индекса postgres прочтет с диска 5 буферов (те же page), то есть 40Кб. А сколько вам собственно положено потратить на один запрос? для микросервиса норма 100 милисек. Поэтому конечно вы правы, что не надо бояться применять в микросервисах базы данных, но надо повозиться с конфигами и прочими сессионными переменными, создать RAM-диск и отдать его под tablespace если это целесообраз-но, посмотреть на планы запросов... и в итоге может даже так случиться, что проще не лезть в БД, а применить известные алгоритмы прямо в коде вашего микросервиса.
Надо будет проверить. Приведу конкретный пример: в таблице на 1000 строк мне надо было раскрасить текстовые фрагменты, которые совпадают в двух соседних столбцах, визуализация совпадений, скорость раскраски после запуска ~ 4 строки в секунду, то есть совсем не аховая скорость. Раскраска листа в 1000 строк - больше 2 минут.
Функционал впечатлил, но осадочек остался.
function highlightVisibleText(columnLiter='B', color="#FF0000") {
const sheet = SpreadsheetApp.getActiveSheet();
const src = `${columnLiter}1:${columnLiter}`
// Если фильтр не применён, используем весь столбец A
const range = sheet.getRange("A1:A" + sheet.getLastRow());
const keywords = sheet.getRange(src + sheet.getLastRow()).getValues(); // Ключевое слово (регистронезависимо)
// Перебираем все строки в диапазоне
for (let i = 1; i <= range.getNumRows(); i++) {
// Пропускаем скрытые ст
const keyword = keywords[i-1][0].toString().toLowerCase();
const cell = range.getCell(i, 1); // Берём ячейку (i, 1) в диапазоне
const cellValue = cell.getValue().toString();
const richText = SpreadsheetApp.newRichTextValue().setText(cellValue);
// Ищем ключевое слово
const startIndex = cellValue.toLowerCase().indexOf(keyword);
if (startIndex !== -1) {
const endIndex = startIndex + keyword.length;
richText.setTextStyle(
startIndex,
endIndex,
SpreadsheetApp.newTextStyle()
.setForegroundColor(color)
.setBold(true)
.build()
);
// Применяем форматирование сразу к ячейке
cell.setRichTextValue(richText.build());
} else {
// Сбрасываем форматирование, если слово не найдено
cell.setRichTextValue(richText.build());
}
}
}
Все верно, Headless CMS. Именно это я и сделал - обратил внимание на тот факт, что для случаев табличных данных гугл таблица и есть готовая Headless CMS. Чем она хуже Chost-Strapi-Netlify? По моему ничем, оговорюсь, в рамках поставленной задачи.
Безопасность неудобная, но нормальная. Что может случиться плохого - утечет наш "вэб-хук". То есть та ссылка, по которой мы обращаемся к себе на сервер. Ссылка только в статье удобочитаемая но я обращаю внимание, что ее надо сгенерировать случайным способом и использовать https. Допустим, даже произошла утечка нашего вэбхука, но что злоумышленник может сделать? Задедосить только. Внести подложную информацию - нет, не получится, потому что вэб хук просто сообщает, что надо считать данные, а данные считываются с конкретной spreadsheet. Даже диапазон в принципе можно не передавать, это вариация - передавать диапазон. Можно читать данные из строго заданного диапазона.
Другими словами: безопасность системы обеспечена ровно настолько, насколько ее обкспечил Гугл для своих таблиц. Если только сам пользователь не передаст злоумышленнику права на доступ к странице, ничего разместить на сайте будет нельзя.
Приведите свой сценрий атаки и ее последствий, будет больше конкретики - будет пища к размышлению.
Здесь в основе лежит потребность заказчика получить простой интерфейс управления товарами ну или контентом если хотите. Стоит человек за прилавком с сотовым телефоном включает отключает товары, дает скидки или генерит промокоды... а уж как эти данные превращаются в html код - это второй вопрос...конечно можно SSG, я для себя искал наименее затратный способ по времени, и чтобы работало.
вы куда то в другую сторону ушли. И вопросы которые сейчас поднимаете - это управленческие вопросы. Статья о другом. Статья о том, что есть вариант очень быстрого, понятного в работе и простого решения, не требующего обучения персонала. И этот вариант не отменяет других, тех, с которыми Вы привыкли работать.
Что касается лично моего мнения по этой бизнес теме - я лично как разработчик и как человек, имеющий опыт собственного бизнеса в торговле, считаю, что не надо вести в одном месте ваш публичный сайт и вашу внутреннюю бухгалтерскую кухню. Это не для дискуссии, это просто мое мнение. И если сайт будет отдельно, то тогда вы будете стремиться распространить полезную для вашего бизнеса информацию, а не бояться ее потерять.
Это решение для людей, которые хотят начать работать уже сейчас, а не отправляться на курсы администрирования MODX. А знаете сколько стоит обучение администрированию одной и отечественных систем сайтостроения? 60 тысяч рублей. Только для того чтобы научиться как заполнгить прейскурант.
И вы не прочитали наверное статью до конца. Exell нужен только как средство ввода данных. Потом по нажатию кнопки данные выгружаются в базу данных сайта или куда вам будет угодно.
Что касается выводов про бизнес - вы эти выводы делаете как разработчик или как представитель бизнеса? Я никогда на скрывал перед своими клиентами, что есть много разных CMS. Называл цену внедрения и они делали свой выбор.
все же время отклика у гугл таблиц большое. тот же Гугл просит чтобы сайт отечал за 250 мсек (!), хотя лет 10 назад 1 секунда считалась нормой. сейчас нет, не норма. То есть данные надо "кэшировать" но можно в простом файле, не обязательно в БД. И про картинки - адрес фото - он временный, нельзя вставить картинку с адресом, как его показывает гугл. Надо скачать и отдавать от себя.
Что касается защиты данных - она ровно такая же как у любой CMS. А что собственно говоря вы хотите сохранить в секрете? Утечка чего вас пугает? Что такого есть в прейскуранте, чего вы публично не выкладываете на сайт. Не понимаю... Другое дело, если вы начинаете вместо сайта строить систему CRM хранить данные клиентов, телефонные номера и прочее.. Но статья о другом. О простом сайте с возможностью один раз сделать его и дать администратору работать с контентом.
Доступ по ссылке - от него рано или поздно администратор таблицы захочет отказаться и перейти на доступ по учетке. Обзаведется учеткой гугла, да, она не у всех есть :) и попросит повысить безопасность...
Почему Postgres - это маленькая БД? Он масштабируется на любой объем данных, здесь вы кажется не правы. Это просто придирка, комментарий в другом:
База данных - это не только инструментарий и табличная алгебра (очень хоргошая кстати), но и куча других накладных вещей, в микросервисах лишних. Хотя тот же постгрес позволяет отключить WAL для таблиц, то есть не вести журналирование при модификации данных., он все же требует подключения, проверки прав, создание нового процесса. И, кстати, при небольших данных, наверное не более чем 8Кб, то есть одна data-page, постгрес не станет применять индекс, все сделает брутальным способом, построчным сравненим и т.п. и т.д.
И даже если индекс будет применяться, то на на таблице в 1000 строк при применении индекса postgres прочтет с диска 5 буферов (те же page), то есть 40Кб. А сколько вам собственно положено потратить на один запрос? для микросервиса норма 100 милисек. Поэтому конечно вы правы, что не надо бояться применять в микросервисах базы данных, но надо повозиться с конфигами и прочими сессионными переменными, создать RAM-диск и отдать его под tablespace если это целесообраз-но, посмотреть на планы запросов... и в итоге может даже так случиться, что проще не лезть в БД, а применить известные алгоритмы прямо в коде вашего микросервиса.
Надо будет проверить. Приведу конкретный пример: в таблице на 1000 строк мне надо было раскрасить текстовые фрагменты, которые совпадают в двух соседних столбцах, визуализация совпадений, скорость раскраски после запуска ~ 4 строки в секунду, то есть совсем не аховая скорость. Раскраска листа в 1000 строк - больше 2 минут.
Функционал впечатлил, но осадочек остался.
Все верно, Headless CMS. Именно это я и сделал - обратил внимание на тот факт, что для случаев табличных данных гугл таблица и есть готовая Headless CMS. Чем она хуже Chost-Strapi-Netlify? По моему ничем, оговорюсь, в рамках поставленной задачи.
Безопасность неудобная, но нормальная. Что может случиться плохого - утечет наш "вэб-хук". То есть та ссылка, по которой мы обращаемся к себе на сервер. Ссылка только в статье удобочитаемая но я обращаю внимание, что ее надо сгенерировать случайным способом и использовать https. Допустим, даже произошла утечка нашего вэбхука, но что злоумышленник может сделать? Задедосить только. Внести подложную информацию - нет, не получится, потому что вэб хук просто сообщает, что надо считать данные, а данные считываются с конкретной spreadsheet. Даже диапазон в принципе можно не передавать, это вариация - передавать диапазон. Можно читать данные из строго заданного диапазона.
Другими словами: безопасность системы обеспечена ровно настолько, насколько ее обкспечил Гугл для своих таблиц. Если только сам пользователь не передаст злоумышленнику права на доступ к странице, ничего разместить на сайте будет нельзя.
Приведите свой сценрий атаки и ее последствий, будет больше конкретики - будет пища к размышлению.
Здесь в основе лежит потребность заказчика получить простой интерфейс управления товарами ну или контентом если хотите. Стоит человек за прилавком с сотовым телефоном включает отключает товары, дает скидки или генерит промокоды... а уж как эти данные превращаются в html код - это второй вопрос...конечно можно SSG, я для себя искал наименее затратный способ по времени, и чтобы работало.
"Гугл-таблица излишня" да нет же!!! Общий доступ, возможность комментировать, приглашать отписывать, работа с сотового телефона!
вы куда то в другую сторону ушли. И вопросы которые сейчас поднимаете - это управленческие вопросы. Статья о другом. Статья о том, что есть вариант очень быстрого, понятного в работе и простого решения, не требующего обучения персонала. И этот вариант не отменяет других, тех, с которыми Вы привыкли работать.
Что касается лично моего мнения по этой бизнес теме - я лично как разработчик и как человек, имеющий опыт собственного бизнеса в торговле, считаю, что не надо вести в одном месте ваш публичный сайт и вашу внутреннюю бухгалтерскую кухню. Это не для дискуссии, это просто мое мнение. И если сайт будет отдельно, то тогда вы будете стремиться распространить полезную для вашего бизнеса информацию, а не бояться ее потерять.
Это решение для людей, которые хотят начать работать уже сейчас, а не отправляться на курсы администрирования MODX. А знаете сколько стоит обучение администрированию одной и отечественных систем сайтостроения? 60 тысяч рублей. Только для того чтобы научиться как заполнгить прейскурант.
И вы не прочитали наверное статью до конца. Exell нужен только как средство ввода данных. Потом по нажатию кнопки данные выгружаются в базу данных сайта или куда вам будет угодно.
Что касается выводов про бизнес - вы эти выводы делаете как разработчик или как представитель бизнеса? Я никогда на скрывал перед своими клиентами, что есть много разных CMS. Называл цену внедрения и они делали свой выбор.
все же время отклика у гугл таблиц большое. тот же Гугл просит чтобы сайт отечал за 250 мсек (!), хотя лет 10 назад 1 секунда считалась нормой. сейчас нет, не норма. То есть данные надо "кэшировать" но можно в простом файле, не обязательно в БД. И про картинки - адрес фото - он временный, нельзя вставить картинку с адресом, как его показывает гугл. Надо скачать и отдавать от себя.
Что касается защиты данных - она ровно такая же как у любой CMS. А что собственно говоря вы хотите сохранить в секрете? Утечка чего вас пугает? Что такого есть в прейскуранте, чего вы публично не выкладываете на сайт. Не понимаю... Другое дело, если вы начинаете вместо сайта строить систему CRM хранить данные клиентов, телефонные номера и прочее.. Но статья о другом. О простом сайте с возможностью один раз сделать его и дать администратору работать с контентом.