Зависит от компании. бычно фронт занимается своими делами, а бэк своими.
В лучшем случае, вы будете делать то, что говорит Тим-лид. Если нужно делать фронт на готовое от Бэка api, то значит в команде все хорошо. В редких случаях, фронту приходится мокать данные с Бэка, и работать со статичными данными.
В худшем случае, это поддержка какого-нибудь сайта, где rest api и не пахнет.
Если вы фронтэндер, то познакомьтесь с Postman. Например в виде гугл плагина. Научитесь работать с ответами роутов сайта. Вы можете создать свой проект, только фронт часть, а через Postman брать ответы с любого сайта, например api городов и стран, и встроить этот api в свой проект. Вам тогда вообще бэк знать не нужно будет.
Проект по ссылке не столько не актуален, сколько ниже качества, чем нужно.
Бэк часть:
- Не рабочая концепция проекта.
- Не профессиональная архитектура. Обычно используется архитектура вида валидатор-контроллер-сервис-репозиторий. В данном случае это был бы ProductsService (директория products + класс в ней ProductsService). Также в этом сервисе лежал бы класс репозитория этого сервиса, где хранились бы методы запросов к базе данных. Запрос бы попадал в валидатор, затем в контроллер, оттуда в сервис, а сервис бы вызывал соответствующий метод в репозитории.
- База данных. Нет внешнего ключа у продукта к категориям.
- Нет типизации. Это нужно для статичных анализаторов, проверяющих код на ошибки. Пример public string $name - как свойство класса. public function getById(int $id) - как метод класса
- Нет валидации запроса. Например, что поля формы должны не содержать определённые символы, или быть конкретного типа. (Очистка от тэгов , используемая в модели, должна находится ещё до того как запрос попадёт в контроллер.)
- Коды и текстовки раскиданы по разным файлам. Всё должно лежать в одном файле, классе, куда будут обращаться все классы за результатом.
- Отсутствует MVC. В каждом файле создаётся новый класс, и дескриптор подключения, хотя это повторяющееся действие нужно вынести в отдельный класс.
- Коды ответа. Не соответствуют действительности. При создании не нужно возвращать 200. 200 подразумевает, что в ответе есть дополнительные данные. Правильный вариант 201
Фронт часть:
- JQuery это рудимент.
- Bootstrap не используется, если есть нормальный отдел разработки.
- Стили страницы не разбиты на верхнюю и нижнюю части.
- Не используется отложенная загрузка скриптов.
- Вместо файлов JS для каждого типа CRUD достаточно одного JS файла
- HTML код в JS. Загрузка JS это одна из самых затратных операций. Чем больше размер файла, тем выше время загрузки. Что сильно отщутимо на мобилке.
- Везде используется POST запрос. В restfull api POST для создания, GET - для получения, DELETE - для удаления, Patch - для обновления части модели, PUT - Для обновления всех полей модели.
Этого курса достаточно, чтобы сделать востребованный на рынке restfull api проект.
