Макс Кузнецов

Как один из вариантов — flexbox.
https://www.youtube.com/watch?v=EO8hH_2OwCU
Там 4 видео. Рекомендую пройти весь небольшой курс по вёрстке, парень очень толково и просто объясняет.

Пример: https://jsfiddle.net/6x2wuf51/1/

https://www.youtube.com/watch?v=Cj8hWtm_40M

Насколько знаю, таких встроенных возможностей у mysql нет. Поэтому остаётся вариант несколькими столбцами или хранение даты в виде строки 'YYYY-mm-dd'. Тогда сможете естественным образом сравнивать строки "2020", "2020-04" и "2020-04-05". Искать вхождение подстроки в строке через LIKE "2020%". Но скорее всего будут просадки по производительности. Тем не менее, если пользователей у вас немного и/или этот функционал не так часто будет запрашиваться, то такой вариант имеет право на существование. Только индекс на столбец не забудьте.

Пример с картинки делается стандартной браузерной валидацией. Просто укажите у инпута аттрибут required.

Но если хочется свою кастомную валидацию, которая будет работать во всех браузерах, тогда в коллбэке, обрабатывающем submit событие, нужно добавить event.preventDefault() и для верности в конце коллбэка вернуть return false.

https://developer.mozilla.org/ru/docs/Web/API/Even...

К сожалению, нет данных, почему базы удаленные и разделены на несколько. Это сильно влияет на ответ. Может быть это хотелка ваших клиентов, чтобы все данные хранились именно на их базах? Или по юридическим соображениям. Тогда имеет смысл вариант 3 — вы просто продаёте комлексный self-hosted продукт. Не думаю, что для админов составит много труда настроить системы мониторинга, сбора логов и бэкапа. Один раз написать скрипты и потом это автоматизировать.

Но если считать, что никаких ограничений нет, то я за вариант 2. Логичнее всего иметь одну базу, где каждая сущность имеет client_id, а в коде на уровне базовых классов ORM добавить фильтр по нему. С серверной стороны — шардинг по client_id:
— Всё будет работать быстро и масштабироваться горизонтально по мере роста клиентов
— Придётся архитектурно немного заморочить, но имхо меньше, чем в предложенных вами вариантах
— Можно иметь общий дефолтный ACL для всех клиентов с возможностью кастомизации для каждого из них (уверен, что это понадобится)
— Все данные в одной базе и при желании вы сможете сделать дэшборд для супер-админа, который будет уметь редактировать всё это хозяйство по всем клиентам сразу и онбоардить нового клиента: создать входной аккаунт для админа клиентской компании, установить дефолтные настройки и определить доступный набор фич. Если такое планируется, советую сразу продумать архитектуру, иначе будет потом крайне больно.

Если злоумушленник, декомпилировав игру получит прямые ссылки к скриптам PHP, может ли он в теории чего нибудь натворить плохого?

Эти скрипты PHP должны быть выполнимыми не должны быть скачиваемыми (обычно дефолтно настроенный веб-сервер так и делает). То есть при запрос скрипта, веб-сервер не отдаст его как текстовый файл, а выполнит все инструкции пхп и потом вернёт только то, что пхп выведет. Например, всё, что заключено в <?php .... ?> будет скрыто, кроме того, что выводится функциями echo, print и подобными.

Вы не скинули файл register.php целиком, но подозреваю, что он весь внутри <?php тега, поэтому можно не переживать, что обратившийся к скрипту пользователь увидит параметры коннекта к базе.

По безопасности в целом — есть два подхода:
1) Сделать обычную регистрацию и авторизацию внутри Юнити приложения. Как я понимаю, у вас сейчас так и сделано. После регистрации Юнити получает токен и использует его для всех последующих запросов. Токен желательно делать протухающим со временем.
2) Сделать регистрацию и авторизацию на сайте, пройдя которую человек может получить доступ к странице, в которую встроено Юнити приложение. И при рендеринге приложения ему сразу же передаётся такой же токен для запросов, что и в пункте выше.

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

https://dev.mysql.com/doc/refman/5.6/en/enum.html#...
Если используется кошерное enum поле, то сортировка идёт в порядке объявления значений в ENUM. Если поменяете порядок, то и сортировка изменится. Другого прямого способа нет.

Сергей правильно расписал. Для ещё большей гибкости я бы посоветовал использовать очереди.
Тогда первый сервис будет парсить tcp-соединения и класть сообщение в очередь (RabbitMQ, Kafka). Вторая часть, которая будет бэкендом для мобильных приложений, будет читать ещё и очередь. При получении сообщения из очереди, записывает в базу и шлёт PUSH сообщение на мобилки. Также мобилки могут иногда сами запросить данные (при первом запуске или при pull-to-refresh фиче, например), тогда ваше API вернёт данные из базы.

Если нужен прям реальный realtime, то тогда это вопрос другого порядка. Скорее всего нужно написать демона, который будет парсить tcp и транслировать UDP. А мобилки будут на это подписываться. Но тут есть нюансы с авторизацией и т.п. Зависит от вашего функционала. Но чаще всего настоящий realtime не нужен. Задержка в секунду более чем допустима для тех сервисов, которые нас окружают.