ElCoyote85

Есть несколько способов или подходов:

1) Да, есть библиотеки (фреймворки), которые генерируют файл спецификации по коду, а уже по этому файлу - документацию, например, Swashbuckle, NSwag и пр. В этом случае разработчику достаточно использовать специальные средства фреймворка (такие как аннотации) и обычные комментарии к коду, по которым и будет сгенерирован файл спецификации и уже после документация по нему. То есть этот файл - не посредник, а необходимый "артефакт", без него вы все равно не сгенерируете документацию.

Кроме того, по этому сгенерированному файлу уже можно будет автоматически генерировать код клиента на различных языках программирования. Например, для C# и TypeScript, используя Unchase OpenAPI (Swagger) Connected Service в IDE Visual Studio 2017/2019, можно легко это сделать (статья на medium.com).

2) Другой подход подразумевает сначала создание файла спецификации для REST API (в yaml или json), а после генерации из него и кода клиентов, и кода контроллеров сервиса (например, и то, и другое можно сделать с помощью Unchase OpenAPI (Swagger) Connected Service), а также документации. При этом сам файл не обязательно писать руками, есть конструкторы для OpenAPI сервисов.

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

Попробуйте обе библиотеки и выберите для изучения ту, которая больше понравится. Написать два Todo List много времени не займет.

sqlbolt.com — там теория и сразу можно потренироваться на практике и выполнить задания.

Из простых преимуществ постгреса - многие запросы в нём отрабатывают шустрее, можно весьма гибко прописать ограничения на данные (если в поле "а" что-то есть, то в поле "б" может быть только "с"), даже крупному магазину может хватить настроек по-умолчанию при которых база довольствуется смешным объёмом памяти.

Из недостатков по сравнению с Mysql - нет множеств (заменяется массивом перечислений), большая строгость работы (число или перечисление нельзя взять и сравнить со строкой "5 = '5'", нужно привести их к одному типу "5 = '5'::int" или " 5::text = '5'5 ", а ваша обёртка над базой может быть не готова к такому).

В контексте nosql баз данных например вижу преимущества в быстродействии, например, причем на порядок.

Увы, это преимущество скорее всего окажется мифом - сейчас как раз потихоньку выпиливаем MongoDB.
Если говорить про MongoDB, то в моих задачах он работал либо не быстрее мускуля или постгреса при поиске, либо в разы (в 2 - 50 раз) медленнее при записи. При этом Монга жрала 1,5 гига памяти, мускуль - 300 Мб, а постгрес - меньше 15 Мб (да, меньше жалких пятнадцати мегабайт).

Использую обе РСУБД. Предпочитаю Postgresql, хотя конечно начинал с MySQL. Из того, что на практике приводит к такому предпочтению:
1) Отсутствие проблем на по сути пустом месте. Из последнего было, в одной базе есть таблицы с большим количеством текстовых полей. При вставке в одно из них чуть меньше 200 символов он отказывался ссылаясь на то, что переводите на динамические. И я значит должен начать курить тему движков мускула и выяснять, что мне оказывается нужна Barracuda. При той же InnoDb. Хочется спросить такого черта.
Или вот еще вспомнил. При попытке записи в поле данных, больше чем это возможно для данной колонки он делает запись тупо обрезав лишнее. И проблему могут не заметить очень долго вплоть до момента когда подниматься из бэкапа поздно, там все уже битое.
Или вот взять и сменить могут дефолтные значение переменных в рамках минорной версии. База после накатки апдейтов и ребута может просто не подняться. На хабре даже была статься по этому поводу.
В общем множество подобных ситуаций после которых так и хочется воскликнуть "какого черта?!". Со слоном я не помню ни одной такой ситуации.
2) RETURN во вставках/обновлениях. Можно получить в ответе любое поле такого запроса. И ни каких тебе танцев с LastInsertId.
3) В последних версиях есть UPSERT которого очень не хватало.
4) В целом более строгий подход и нет ощущение бардака.
5) После запуска Postgres Pro появилась полностью руссифицированная документация. Помогает вкатиться в тему новичкам.

Из минусов некоторое время было отсутствие адекватного UI клиента. Но после того, как стал использовать PhpStorm эта проблема была закрыта.

Ответ работодателя:
Несмотря на то, что вы подготовили рабочее решение и владеете PHP, ваш опыт не соответствуют нашим текущим потребностям в части знаний ООП, composer (использовании сторонних библиотек). Приложение сложно расширять.
Мы ожидали увидеть приложение с использованием готовых библиотек для работы с HTTP, базой данных, работы с консолью. А также легко расширяемое и поддерживаемое.

Бесплатный сбор с кандидатов различных интересных архитектур и подходов на open-source решениях/либах для своих будущих разработок под видом тестирования. И ничего более...

Дак это не они должны окликаться, а вы должны искать. Я например когда работу искал, ни разу сам рабодателю не звонил и не писал, меня сами приглашали. А ваша уже задача предложить условия, которые лучше чем у других, чтобы допустим я, соизволил у вас работать) Увы, но для работодателя ситуация на рынке труда очень сложная.

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

Также могу порекомендовать порешать задачки на hackerrank.com и codewars.com.

Посмотрите тур по го - но там совсем базовые вещи. Есть и на русском, кажется.

Также неплохо будет почитать про бест праксис - это хорошо изложено здесь, но много.
Также сразу учитесь правильной организации файлов проекта здесь.

Ну и в целом читайте и смотрите все, что попадется под руку, поможет понять Go-way

Совместимы, работаю full-time на удаленке, фиксированная месячная зп - $5200.
Во время подписания договора оговаривали что мой рабочий день будет составлять 8 часов, я же непосредственно на работу трачу 5-6 часов, заказчик более чем доволен объемом работы, который я выдаю за это время.
P.S. Я мобильщик, отдельные знакомые бэкендщики (PHP/RoR) получают поболее.

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

Нельзя , апворк сделал автовывод, можно играться меняя интервалы вывода но в целом апворк не банк это раз, если ваш аккаунт заблочат никто вам деньги не отдаст.
Хранить все яйца в одной корзине глупо не будьте дураком

php.net/manual/ru/function.exif-read-data.php

<?php
$image = imagecreatefromstring(file_get_contents($_FILES['image_upload']['tmp_name']));
$exif = exif_read_data($_FILES['image_upload']['tmp_name']);
if(!empty($exif['Orientation'])) {
    switch($exif['Orientation']) {
        case 8:
            $image = imagerotate($image,90,0);
            break;
        case 3:
            $image = imagerotate($image,180,0);
            break;
        case 6:
            $image = imagerotate($image,-90,0);
            break;
    }
}
// $image now contains a resource with the image oriented correctly
?>

Попробуйте использовать axios :)

axios.get('/url').then((response) => this.data = response.data.response)
.catch((error) => console.log(error.response.data));

P.s: import axios from 'axios'; для использования

Не обижайте верстальщика, он тут ни при чем)
Прогер должен работать по техническому заданию, а не по макету.