И заметила, что основная часть задач - инфраструктурная.Такой работы всегда много, но есть нюансы.
Настройка тестовДа, это в любой разработке будет, не только во фронте
CI/CDСомнительно, но окэй, знать это очень желательно, но в крупных проектах этим занимается девопс, как минимум настраивает скрипты. В малых компаниях это раскидывается на разрабов, есть такая практика.
OLAP CUBE, оптимизация запросов к БД.А это вообще чисто бэкендерские заморочки, конечно никто бить за понимание таких штук не будет, но в целом фронту это не особо важно, у него должно быть расписано апи/эндпоинты и чего туда пихать и что получать. Уж оптимизацией запросов чистый фронтендер точно не обязан заниматься.
Насколько известно, REST не хранит состояние клиента между запросам.Это не значит что он вообще не хранит состояние клиента, это значит что он хранит только состояние на момент синхронизации, а МЕЖУ запросами состояние клиента находится в неопределенном состоянии до момента следующей синхронизации. То есть это не принцип который надо соблюдать, а констатация факта. Кроме того, в вашем примере бэкенду/апи вообще должно быть фиолетово на состояние клиента.
Клиент передаёт необходимые данные в первом запросе. Эти данные меняют состояние сущности (лабиринт) на сервере.Сущность лабиринт НИКАК не затрагивается, у вас может изменяться только принадлежащие вам сущности, в данном примере у вас будет меняться состояние робота.
Если бы клиент располагал всеми данными,то он был бы бэкендом и апи было бы не нужно. Собственно апи - способ обмена запрашиваемыми данными.
Последующие запрос-ответы связаны с предыдущими, не имеют смысла без выполнения предыдущих, поскольку сервер хранит изменяемую сущность (лабиринт).Не лабиринт.
Как серию "запрос-ответ" логически объединить?Зависит. Так как вопрос у вас на пальцах и вообще без конкретики, то и ответ будет достаточно общим в рамках описанной системы.
GET someapi.tld/api/v1/robot/{id}, в результате назад вы получите объект робота с координатами. Что с ними делать зависит от вашего функционала, например можно задать новые целевые координаты.
if(!$_GET["request"] || typeof $_GET["request"] !== 'string')typeof здесь не в тему, так как у вас ВСЕГДА приходит стринг, в гет запросе (как впрочем и в любом другом) нельзя указать тип.
1. Есть ли лучшие идеи, чем мои?В принципе идея не нова, есть даже сервисы готовые под похожие задачи, типа cors-anywhere от heroku и еще куча по запросу cors proxy.
Я понимаю, что можно напрямую делать запрос к '/?request=''" и не заморачиваться с .htaccess, но такой вариант не красив.Это вообще 2 разные задачи. .htaccess настраивается на единую точку входа как написал Сергей delphinpro, далее вы в коде все запросы прошедшие к индексу проверяете на $_SERVER['REQUEST_URI'] (никакой /?request вам не нужен), вытаскиваете из него урл картинки и уже например curl используете для получения ее с другого сайта. Картинку запросу отдать как текст, предварительно отослав соответствующие картинке заголовки.
2. Как лучше всего обработать ошибку и сделать перенаправление при ненужном или неправильном запросе?проверять $_SERVER['REQUEST_URI'] на "правильность", например что запрашивается файл определенных заранее типов, ака вайтлист. В случае несовпадения можно тупо отправить 404.
3. Как обеспечить безопасность субдомена?Безопасность от чего?
if(!file_exists(folder)) { // проверка на существование папки / файла (так папки или файла?)
CreateFolder(folder, req) //а если это файл, все равно создаем папку с таким именем?
return //то есть вложенность больше 1 уровня папки создаваться не будут?
}1. когда вообще в базе надо создавать отдельного пользователя? Есть практики что что почитать?Когда человек регистрируется в системе, вроде очевидно.
2. есть ли какие паттерны проектирования баз под такое. Идея-то интересная.Есть конечно. Только подход с пользователями бд обычно тупая идея, так как смена роли/группы/доступа будет нуждаться в прямом вмешательстве в систему бд, что не есть гуд. Обычно RBAC не реализуется на уровне пользователей бд, а использует код, который ориентируется на данные из бд.
3. Какие слова вообще гуглить?RBAC <ваш фреймворк> library
Есть ли смысл начать с устаревшего материала?4-5 лет не сказать что сильно устаревшие. ИМХО спокойно можно учиться, основы будут одинаковы для любой версии языка, изменения в новых версиях большей частью касаются ООП составляющей, до которой еще дойти нужно. В целом и ООП код более старых версий совместим с последними версиями, во всяком случае с 5+, в обратную сторону конечно же работать не будет. Ну а новые фишки по типу тайпхинтинга и анонимных объектов можно доучить и самостоятельно.
разработчики все время советуют перейти на новые технологии а если точнее на Laravel и с MySQL на PostgreSQL чтоб сайт не только стал современным но и работал шустрее.Переход с самописа на лару - хороший шаг, переход на постгрес нужен только если нужны конкретные задачи, решаемые постгресом лучше чем мускулем. Например, если у вас есть большой массив json данных, хранимых в соответствующих полях и требующий каких-либо выборок на основании этих полей, то есть по сути - если у вас база хранит ненормализованные сортируемые данные. В остальном выгода от перехода с мускуля на постгрес будет не видна без микроскопа.
Пытаюсь сделать обязательными поля: country и birthdayДля этого существуtт атрибут required. Естественно это не отменяет проверки полей на бэкенде, но это немного другой вопрос.
где даже submit находится за формой (внесение его внутрь не помогает).Как вообще идея вынести из формы кнопку субмита пришла в голову? А главное - зачем?
Перепробовал все способы которые нарыл. Ничего не помогает.Плохо рыли. Это вообще дефолтное поведение формы, не требующее никаких скриптов. Форма не отправиться пока не будут заполнены указанные как required поля. Если нужны какие-либо еще манипуляции с формой на js, то делается по другому. Форма не трогается, а в кнопку никакие онклики не лепятся. На объект формы вешается событие онсубмит, после чего ПРОВАЛИДИРОВАННАЯ форма вызовет это событие, и дальше уже можно работать с данными формы, в том числе и отправить ее аяксом на бэкенд если необходимо.
Решением было только поменять кодировку таблицы базы данных MySQL, но в моем случае она была utf8mb4, которая должна поддерживать эмодзи.Так как utf8mb4 "обратно совместима" с utf8, все кроме 4байтных символов будет нормально отображаться. Соответственно при указании настроек соединения стоить исправить чарсет на utf8mb4, который по умолчанию у вас скорее всего utf8.
5) Какие главные минусы против чтобы временную метку хранить просто как число unixtimestamp? То что выборки , когда нужны всякие DATE специфичные функции, потребуют преобразования в тип дату в каждой строке? (это преобразование может не сложное?, ведь datetime и так хранится как число)Как минимум то что у вас дата не хранится как дата. Про то что не будут работать стандартные функции работы с датами типа разницы в год, месяц, неделю и прочие весьма неочевидные преобразования я вообще молчу, чего стоит банальное вычисление количества дней до, например, конца месяца, с учетом того что каждый месяц имеет разную длину, не говоря уже про високосные года, ну и всякие расписания, где работа с минутами/часами без готовых функций тоже так себе удовольствие. Кроме того, таймстамп имеет свои ограничения, например в нем нельзя хранить даты раньше чем 1970 год, то есть пользователи старше 55 лет дату рождения сохранить не смогут. Ну и горизонт планирования до 2038 года, дальше все. Алсо, вы теряете защиту от кривых данных на уровне типа поля, что тоже +1 в копилку встроенных типов.
Можете посоветовать как к этому подойти? Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать? Мне кажется, что это возможно, потому что Авито был до того как появился реакт, как-то же это сделалиПочти любой современный сайт состоит из 2 основных частей: Фронтэнда и бэкэнда. Фронт - то что отображается в окне браузера, бэк - серверная часть, отвечающая за чтение, изменение и сохранение данных, которые можно вывести для клиента в любой удобной форме. По этому для реализации вашего проекта понадобятся знания не только верстки и js, нужно будет и разобраться с серверной частью, которая обычно состоит из движка на каком-то языке, подходящем для веб разработки (PHP, Pyton, Java, JS...) и базы данных, где будут храниться собственно данные о пользователях, объявлениях, просмотрах и т.д.
Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать?А искали?