Дмитрий Свиридов

pgloader

Для начала я бы попробовал bulk_create, поделив эти 150к на чанки определенного (установить опытным путем) размера. А вообще конкретизируйте задачу, пожалуйста. Не очень понятно, зачем вам 150к строк в базу нужно писать каждые 10 секунд.

В идеале сначала написать приемочные тексты для текущих страниц сайта, чтобы после переезда на SPA с SSR, быть уверенным, что ничего не пропало, не отвалилось и работает так, как работало.
После этого делаете нужные API прямо в своем Ruby-бэкенде. Параллельно с этим создаете новый репозиторий для фронтенда и, собственно, его делаете. Тут вам поможет сам React и такая штука для него, как NextJS.
Когда все сделаете, запускаете приемочные тесты и убеждаетесь, что вся функциональность работает, как и раньше.

1. Включить логирование медленных запросов MySQL, после чего оптимизировать, добавить индексы.
   
2. Обратить внимание на то, что индексы могут приводить и к падению производительности, так что неиспользуемые лучше удалять.
   
3. Убедиться, что не просто индексы проставлены, а проставлены правильно.
   
4. Включить логирование atop на несколько дней, чтобы была возможность понаблюдать, что происходить в системе, когда "начинает виснуть всё". Может быть, вообще не в MySQL дело?
   
5. В Laravel запросы делаются к базе с помощью Active Record - бывает так, что вместо JOIN в базу летит гора запросов циклом - это не оптимально.
   
6. Как уже выше писали, нужно использовать кеширование - это ощутимо снизит нагрузку.
   

Плюсы раздельных репозиториев:

• Раздельный деплой. Фронты могут релизиться отдельно от бэкендеров. По факту правда на практике все равно им приходится согласовываться и релизиться разом, потому что почти всегда одни зависят от других.
  
• Возможность издеваться над бэкендом: переписывать на другой язык, дробить на микросервисы и т.п. - и это никак не отразится на репозитории с кодом фронтенда.
  
• Разделение команд. Фронтендеры не трогают (могут и не иметь доступ) код бэкендеров
  

Минусов лично я не вижу

Сам недавно с такой же примерно задачей столкнулся, правда в Питоне. Храню позицию в базе, а при смене позиции "сдвигаю" нужные элементы, чтобы нужные позиции перестраивались. Возможно, Вам пригодится:

touched_question = TestQuestion.objects.get(id=kwargs['question_id'])
questions = TestQuestion.objects.filter(test_id=touched_question.test_id)
for question in questions:
    if question.id != kwargs['question_id']:
        if touched_question.number < question.number <= new_number:  # Сдвиг вправо
            question.number -= 1
            question.save()
        if new_number <= question.number < touched_question.number:  # Сдвиг влево
            question.number += 1
            question.save()
    touched_question.number = new_number
    touched_question.save()

Правда в моем случае данных мало, а в Вашем это решение, возможно, не будет оптимальным. Потому что тут запросы в цикле))

Ставите с помощью Composer библиотеку Guzzle и юзаете с флагом 'allow_redirects' => true - она сама будет следовать по редиректам, если сервер вернет 301/302.

Зачем Вам ОБЩИЙ вольюм, доступный всем контейнерам? Если там ваши php-скрипты, то при деплое собирайте образы, пропихивая туда нужные файлы - и все.

А для элементов с классом tab-pane кто будет класс active добавлять в зависимости от get-параметра?

Учитывая, что во многих проектах достаточно много простых запросов (выборка по одной таблице, вставка, обновление), ORM для них использовать удобно. Единственное, когда у вас имеются связи между сущностями, следует внимательно следить за тем, какие запросы делаются к СУБД и главное, сколько их. Для Django есть [django-debug-toolbar](https://github.com/jazzband/django-debug-toolbar), с помощью которого это можно отслеживать.

Минусы ORM - неочевидность и недостаточная гибкость. Например, если мне нужно сделать UNION нескольких таблиц, для конкретного поля каждой из которых сделать alias (потому что нужные для сортировки поля называются в них по-разному), по которому выполнить сортировку всех результатов, думаю, от ORM придется отказаться. В реальных проектах, к сожалению, такие запросы встречаются сплошь и рядом, поэтому вместо ORM удобней использовать query билдеры.

Но в Django на встроенную ORM много чего завязано, поэтому отказаться от нее сложно. Я имею в виду, что если не использовать в проекте на Django встроенную ORM, то и использовать Django вообще особо смысла не имеет.

То, как Вы все реализовали, называется Flat PHP. Такой код невозможно поддерживать, развивать или хотя бы просто покрыть тестами. Я бы порекомендовал взять какой-нибудь более-менее известный фреймворк, и эту же функциональность реализовать в нем. По крайней мере, ознакомитесь с шаблонами проектирования. Если говорить конкретно про Ваш код, то переделать надо все. Начиная с отделения шаблона от логики и заканчивая вынесением в конфигурационный файл приватных данных для подключения к СУБД. И, кстати, зачем вам в скрипте код создания таблицы?

Гугл может проиндексировать, но гарантий нет. Яндекс точно не проиндексирует. Так что не рекомендую так делать. А если у вас SPA-сайт на React/Angular/Vue, то обязательно сделайте SSR, если рассчитываете на органический трафик.

Тут для начала надо определиться, что такое sass. И это не фреймворк. В нем нет готовых компонентов, это просто метаязык, упрощающий написание css-кода. Например, есть переменные и т.п. А бутстрап - это набор стилизованных готовых компонентов (например, кнопки, таблицы). То есть это разные вещи, и sass не является заменой бутстрапу.

Я бы Celery прикрутил и асинхронно эти команды выполнял.

Все http-запросы делаете axiosом к api, написанному на Laravel или ещё чем-то. Laravel в свою очередь ходит в базу данных, достаёт оттуда данные (или пишет туда) - и отдает их обратно в json (например) в http-ответе. Напрямую с фронтенда в базу не ходят.