Можна спробувати, прийдеться тільки юзати implicity flow, бо без сервера треба синхронізація

Дякую!

Добре, записав )

Про SRW я писав — для lego каталога тут не швидкість, а актуальніть данних, тому network-first стратегія. Якщо Lego щойно випустила нову серію, і я додам її в API, користувач із SWR-стратегією при першому скануванні в магазині отримає стару базу з кешу. Сканер видасть помилку, і лише у фоні кеш оновиться для наступного разу

З мінусів відсутність інвалідації кешу для бази даних IMAGE_CACHE. Якщо картинка оновилася на сервері, користувач ніколи не побачить нову версію.

Це вирішено через хешування в назві картинки — якщо вона змінилась, то і назві зміниться, а значить буде видаватися нова (йде генерація з однієї картинки форматів avif, webp що видавати браузеру тей формат, що він підтримує). Також додатково вбудований механізм чистки старих картинок по даті доступу — ті які по даті найстаріші (давно відкривалися) — видаляються, щоб кеш картинок не зростав безконтрольно.

Немає стратегії stale-while-revalidate для API-даних. Якщо кеш застарів, а мережа повільна, користувач бачить старі дані, доки не оновить сторінку.

Хороше зауваження — тут можна додати кнопку якщо API fetch був з кеша в інтерфейсі щоб зробити force-fetch update. Тут SWR не підходить, бо треба пріоритет на свіжі дані, якщо мережа жива, а не швидкість по даним, які оновлюються «на перспективу»

Дякую за коментар

Дякую. Ідея була щоб не ставити ще один додаток на телефон, але при цьому мати можливість користуватись без інтернету.

Таку базу можна прикрутити, хоча тут вже виникне ситуація якогось центрального збереження саме Ваших данних, щоб на телефоні і на комп’ютері це було синхронізовано. Хоча може ці додатки про це не думають і все зберігають локально, тоді це спрощує задачу

wal-g.readthedocs.io
wal-g.readthedocs.io/PostgreSQL

І інкрементальні бекапи будуть, а не «в нас останній бекап 12 годин назад робили», і на диску не буде сміття

Я думаю тут все просто — їх не реквестять в достатній кількості комʼюніті через форму

medium.com/...​am/excellent-65c87fcc8114 — цей коментар вже все непогано написав.

Тестувати PostgreSQL для роботи в шаблонах доступу та моделі даних MongoDB, і при цьому MongoDB все одно не змогла показати успіх у своїй роботі (в десятки і сотні разів), тобто в інших шаблонах роботи в неї (напевно) все ще гірше )

А при чому тут «лінійки» до останньої версії бази?

Останні версії були: PostgreSQL 15.1 — 2022-11-10 (якраз тоді вийшов 14.6 з патчами), PostgreSQL 15.2 — 2023-02-09.

15 лінійці не було ще і півроку

і на що це впливає? PostgreSQL випускає не Bethesda, щоб треба чекати працюючої версії по пів року

вона давала дещо гірші результати на GIN індексі ніж 14

покажіть ці цифри

> Використовувалися PostgreSQL 14.6 і MongoDB 6.0.3. Тести проводилися на початку 2023 року, коли ці версії були останніми.
> October 13, 2022 — PostgreSQL 15 released (improves on its in-memory and on-disk sorting algorithms, with benchmarks showing speedups of 25% — 400% based on which data types are sorted)

No comments

Так, не великий відрив. Ось якщо порівнювати з С + emscripten (тут варіація — webp.leopard.in.ua/ ), то нормальний відрив (звичайно rust і go багато докидує своего в wasm)

3.3M  - browserslistwasm_bg.wasm
3.6M  - parser.wasm
253K  - webp.wasm

vmail.leopard.in.ua — без сервера перевіряє які HTML теги чи CSS правила не будуть працювати у email клієнтах. Wasm модуль написаний на GO (опенсорс).

З мінусів — GO WASM найбільший за розміром (мегабайти), ніж якщо писати на C чи Rust. Tinygo може в цьому допомогти, але не будь який Golang код можна через нього конвертувати в компактніший WASM

Для прикладу browserlist.leopard.in.ua WASM на Rust значно меньший за розміром

движок із спрощеним діалектом заради продуктивності

Продуктивності чого саме? Швидше працює чим PostgreSQL?

Так, є проблеми з великими джойнами, де задіяно 20-30 таблиць і інколи доводиться гратися з ’optimizer_search_depth’ - але це теж ціна за цілком зрозумілі та корисні плюшки.

Надайте будь ласка приклад, чому PostgreSQL в важких випадках може використовувати генетичний алгоритм для складних запитів замість динамічного програмування, а MySQL отримує корисні плюшки, які я, наприклад, цілковито не знаю які.

s3_force_path_style = true

Переключение на S3 path перестанет работать на AWS в конце сентября

aws.amazon.com/...​an-the-rest-of-the-story

Так что лучше уж делать локальные виртуальные домены под бакеты

Мы на своем проекте принципиально отказались от inline-скриптов, и даже код-сниппеты, такие как Google Analytics, перенесли в отдельные файлы

Этого не нужно делать. Можно воспользоваться для таких скриптов хешом или nonce. nonce будет удобнее, если контент динамический (чексумма меняется и хеш статический не привязать). Тут подробнее: www.troyhunt.com/...​es-nonces-and-report-uri

Ну а вообще, всякие аналитики и Google Tag Manager может подключать (c сохранение CSP), чтобы не дергать разработчиков и не деплоить ради новой аналитики или трекинг ивентов приложение.

Забыл добавить, что поэтому certonid по умолчанию требует пароль от ключа, который зашифрован (и опциональное шифрование самого ключа). Тоесть скомпроментированный архив бесполезен без ключа шифрования, который будет в том же AWS KMS или Ваш симметричный ключ.

Між запусками AWS Lambda мій zip архів з приватним ключем десь зберігається в AWS?

Все верно — AWS у себя его хранит.

Наскільки надійний цей сторедж?

Я думаю настолько, как и AWS KMS и другие сервисы от AWS, которые хранят секреты

Хто і як може отримати до нього доступ?

В данном случае доступ будет иметь те люди, которые могут менеджить эту AWS lambda функцию (теже самые люди, что и создали эту самую функцию с ключем). Менеджить доступы можно через тот же AWS IAM. Как часто бывает — это security team.

Больше по безопасности AWS Lambda можно подчеркнуть здесь: docs.aws.amazon.com/...​t/dg/lambda-security.html

Да, если рассматривать serverless как отдельную машину. Данное правило верно, если и вас машина, где генерятся ключи и будет центром сертификации.

Но серверлес функции не мутабельны — код не может создать артефакт и положить его рядом для следующих запусков (функция как это говорят stateless). Если генерить сертификат изначально на серверлес, его придется хранить в другом месте, а значит уже перемещать на тот же AWS S3 или другое хранилище (я собираюсь добавить в certonid читать ключи не из файловой системы, а внешнего хранилища). Что в контексте этого правила, опять неверно. Но тут нужно понимать, что машины при серверлесс у нас нет. Поэтому целесообразнее положить сертификат в сам серверлесс, хоть и придется его передать по HTTPS на Амазон.

Благодарю. Да, данное решение отлично подходит если у Вас все сервера на AWS. Подобными решениями обладает Google Cloud и возможно другие облака (я не работал с Azure, не в курсе что там есть).

У Certonid хороший плюс в том, что оно не привязано где находятся ваши сервера, а значит позволяет его использовать для разнородных серверов (Digital Ocean, Linode, Hetzner, metal, прочее), не только те, что есть в данном облаке (оно только использует возможности AWS для работы)