Алексей Уколов

Операция проверить есть запись и вставить - не атомарная. У вас одновременно может выполнится вагон проверок и начать вставку.

1. Использовать локи. Залочили таблицу, проверили, вставили, убрали лок.

2. Повесить unique на связку поле ['user_id', 'post_id'], и через catch ловить нужный exception.

3. Повесить unique на связку поле ['user_id', 'post_id'], и добавить макро upsert - на вставку pivot.

https://dev.to/mlimonczenko/3-must-know-difference...

Если HTTP - это тупо текст поверх TCP, то HTTPS - это текст, завёрнутый в TLS, который идёт поверх TCP.

что значит "модификация"

1. Хз что ты там читал, но мне вся выдача гугла говорит, что HTTPS - это расширение HTTP
2. Если не вдаваться в этимологию, то "расширение" - это когда суть расширяемого объекта не меняется, но добавляется что-то ещё. В случае HTTPS - у нас остаётся вся семантика HTTP, но добавляется шифрование.

По факту это всё-таки другой протокол, который не совместим с обычным Http

tldr: подключайте svg и не мучайтесь.

а) Трудозатраты
Подключить картинку быстрее и проще.
б) Надежность
Изображение будет гарантированно отображаться как надо на всех устройствах. Если где-то вдруг не загрузится шрифт, или не успеют прогрузиться стили, вы потеряете оформление.
в) Индексация
Теоретически может оказаться полезным то, что текст будет прочитан и учтен поисковиками, хотя обычно это не дает каких-то преимуществ.
г) Оптимизация
В разных случаях меньше будет весить картинка или оформленный текст.
Если для текстового логотипа надо прилинковать пару нестандартных шрифтов, это значительно увеличит количество кБайтов. Если нет, текст будет немного меньше весить, но выигрыш будет несущественным.
д) Особенности дизайна
В некоторых случаях может быть нестандартный дизайн, где текстовый логотип — необходимость.
е) Действительно простой логотип
Ну и конечно, если логотип — это банально название компании / марки, набранное уже подключенным шрифтом, и никаких дополнительных итераций (интерлиньяж, трекинг и т.п.) не требуется, тогда, действительно, проще набрать текстом.

1. создать элемент
   
2. в него положить исходный HTML как innerHTML
   
3. забрать из него уже textContent
   
   

const textFromHTML = html => {
  const el = document.createElement('div');
  el.innerHTML = html;
  return el.textContent;
}

textFromHTML('на уровне около $300') // "на уровне около $300"

Вам виднее, нужны ли они в вашем проекте. Обычно это зависит от сложности проекта и темпов его развития. В чëм-то мелком и мало изменчивом внедрение через интерфейсы - это карго-культ. В большом и сложном проекте, который постоянно изменяется - это жизненно необходимый подход, без которого работа сначала превращается в ад, а потом и вовсе становится невозможна.

Единственно правильный ответ - никак.

Такой вопрос можно задать только от безграмотности. От непонимания того, как работают сессии.
Потому что сессия в обязательном порядке блокирует файл с данными на время работы с ним. И именно отсюда возникают многочисленные вопросы "а почему у меня долгий процесс в одной вкладке блокирует сайт во всех остальных вкладках?". А теперь представим, что один и тот же файл блокирует не один юзер, а все по очереди. Таймаут будет постепенно накапливаться, и в итоге сайт у всех пользователей сначала начнет ощутимо подтормаживать, а потом и вовсе встанет колом.
Поэтому такая вещь, как "сессия сразу для всех пользователей" заведомо является бессмыслицей.

Если под "сессией" имелось в виду общее хранилище для всех пользователей, то оно называется "база данных". И в этом смысле "БД не предлагать" выглядит беспочвенным капризом. Как правильно заметил N в комментарии, такое заявление звучит как "Как кушать суп? Ложку не предлагать."
Такие заявления надо всегда подробно обосновывать. И в этом случае вам либо действительно подскажут, как обойтись без БД, либо объяснят, что это просто блажь.

Если хранилище не нужно, то есть значение переменной не меняется со временем, то, как правильно сказано в соседнем ответе, просто делается константа в конфигурационном файле, который по умолчанию включается во все скрипты.

Я так понимаю что база данных MySQL. И у вас на локалке один strict_mode, а на проде другой. На локалке не правильный - и вам соверженно правильно пишут что нельзя выбирать поля в селекте если они не используются в group by.

Что-то вы не договариваете, редиректы никто не блокирует, к примеру редирект с кодом 302 прекрасно работает. Блокируются только зацикленные редиректы сами на себя, когда браузер понимает, что выхода из этого редиректа никогда не будет. К примеру если вы перейдете по ссылке https://toster.ru/q/364913, то в итоге волшебным образом попадете на адрес https://qna.habr.com/q/364913, это и есть редирект и никакой блокировки нет)
Какое сообщение показывает браузер когда в вашем случае происходит блокировка редиректа?

Можно спарсить фрагмент HTML в документ, в котором обычными методами вроде querySelector() поискать нужный тег:

const code = `
<li class="search__list-item">
  <div class="search__img-wrap">
    <img class="search__img search__img_indents" src="search.svg" alt="Иконка">
  </div>
  <strong>поиск</strong>
  текста
</li>
`;

const parser = new DOMParser();
const doc = parser.parseFromString(code, 'text/html');

if (doc.querySelector('strong')) {
  console.log('Есть!');
}

memoization
это называется «мемоизация» (не от слова «мем», нет : ) Функция запоминает значения аргументов и результат выполнения. Если уже вызывалась с такими аргументами – вернёт «запомненное» значение, не выполняясь ещё раз. Статья на Хабре

В качестве кэша можно использовать объект или WeakMap, если аргумент – объект.

distributed lock
Из вопроса не вполне понятно: в контексте одного выполнения скрипта только один раз, или глобально? Для глобального случая можно использовать какое-то быстрое хранилище, например, Redis, и механизм MutEx ("mutual exclusion" – взаимного исключения), например RedLock.

На пальцах: вот есть аргумент X. То ли вызвать функцию, то ли параллельно уже другой процесс выполняет и скоро будет готовый результат — вопрос.

Генерится случайный ключ. Пара (X, ключ) отправляется в асинхронное хранилище, где если нет ещё сохранённого значения под этот X, ячейка запирается (lock) этим ключом. Тут необходима особенность механизма самого хранилища – в Redis это "NX" – записывать только, если уже нет значения. Это гарантирует, при параллельных запросах, что только чьё-то одно случайное значение запишется. Закон джунглей: первый прибежал — наелся!

Далее надо прочитать записанное значение и получить ключ. Сравнить со своим ранее сгенеренным ключом. Совпали? Значит, это именно мы заперли этот аргумент, и можно выполнить функцию. Не совпали – параллельный процесс выиграл. Просто запросим готовое значение чуть попозже.

Не совсем понял в чём именно проблема.
Вы не понимаете как поставить обработчик на Enter? В целом это обычный слушатель на событие keypress, например с проверкой свойства key (event.key === "Enter").

Или не ясно как в этом обработчике дальше логику строить?

также будет имитироваться клик на кнопку которая отправляет сообщение

Вам не нужно пытаться имитировать клик по кнопке, это усложнит код. Обработкой нажатия на enter и клика по кнопке отправки должен заниматься один обработчик. Т.е. у вас есть два слушателя (на enter и на клик по кнопке), но они должны вызывать одну функцию/метод который уже и отправляет сообщение.

Мммм, какой классный холивар, давайте я вставлю свои 5 копеек. Сначала прелюдия:
Redis:
это кэш с парой-тройкой фич. Не предназначен для хранения и поиска данных как класс

Elasticsearch, Sphinx:
Два принципиально разных поисковых движка. Хорошо делают свою работу, но не предназначены для хранения данных, только для хранения поисковых индексов.

1. Хранение данных каталога с быстрым доступом

Поскольку ни одна их указанных систем не является базой данных стоит задуматься о другом виде баз данных. В зависимости от того что выберете то и масштабировать придется по-разному

2. Поиске по информации, в особенности русскими названиями-запросами

Это умеет сегодня любой поисковый движок

3. Простота в использовании: синтаксис запросов, документация

Документация есть у всех адекватных поисковых машин, синтаксис везде достаточно простой

4. Наименьшая нагрузка на "железо"

А вот тут начинаем смеяться. Если мы говорим о поиске то первое правило - все выделенные ресурсы что вы выделите будут съедены. Даже если у вас 100 товаров по 2кб. Память будет съедена первой, потом получит свою порцию и процессор

5. Отказоустойчивость

Это не про поиск, а про архитектуру, сеть, сервера, и все в таком духе. Если что то горизонтальное масштабирование поисковых машин это боль - все хорошо пока не сломалось и там очень часто кластер не восстановись

6. Безопасность

Опять не про поисковые машины. Есть 3 части: encryption in transit (ssl), encryption at rest (AES), auth (зависит от движка). В принципе все и так поддерживают сегодня

7. Масштабирование

И снова не про поиск, а про архитектуру. Вертикально масштабировать проще всего в облаках и дорого, горизонтально масштабировать - больно