Верное у меня представление о разработке fullstack web приложений?

Правильно ли у меня представление о создании fullstack веб приложений ( или же сайтов )?
Возьмем обычное приложение, допустим, интернет магазин: его функционал: чтение товаров, удаление, добавление, просмотр определенного товара, обновление товара ( ну короче CRUD ):
Правильно ли что изначально создается бэкенд RESTful api для такого сайта (на подобии такого: https://only-to-top.ru/blog/programming/2019-11-06...)?
А после уже приступают к созданию фронтенда ( https://only-to-top.ru/blog/programming/2019-11-11... )

То есть это везде так и всегда? Вне зависимости от языка серверного, вне зависимости от того, пишите вы на голом js или react каком-нибудь?
Или сейчас так не делается? Точно также идет работа в компаниях? Где бэкендеры делают бэк сайта, api для него, выводят данные в формате JSON чтобы фронтендеры могли делать ajax запросы к этому api и уже работать на клиентской стороне?

Скажите, эти ссылки вообще актуальны или так делали в 2003 году?:)
Как разрабатываются приложения...:(
То что описано в первой ссылке это как раз основная работа бэкендера? Столько вопросов..

Я всегда был фронтендером, могу работать с API всякими открытыми, типа погоды или сделать на firebase базу и отправлять запросы..
Но я особо понятия не имею о работе бэкендера)

Дополнительно:

Зависит от компании. бычно фронт занимается своими делами, а бэк своими.

В лучшем случае, вы будете делать то, что говорит Тим-лид. Если нужно делать фронт на готовое от Бэка 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 проект.

• Хочется узнать о фулл стэк разработке и чисто для портфолио свое веб приложение запилить прост) Верный ли это вообще подход или нет - не знаю просто, могу плюнуть и на firebase оставить бэкенд часть приложения
• Niksak, существует такое понятие как рабочий инкремент. Например форма авторизации.

  Сначала делается бэк часть: БД, модель, валидация реквестов и формирование респонса.
  Потом фронт часть: верстка и ajax запрос.

  В таком духе делаете инкремент за инкрементом. Обычно это укладывается в рамки рабочего спринта.

• AgentSmith72, ну а вообще если, то по ссылкам вещи достаточно полезные и актуальные ведь если с нуля свое писать? Я для диплома хотел) Такое можно вообще на любом яп серверном сделать же
• Niksak, я когда-то давно, тоже искал пример проекта с restfull api, и возпроизвел этот проект, что вы скинули в ссылке в вопросе.

  Теперь спустя время я понимаю, что это далеко от того, как реализуется rest api сейчас.

  Если планируете искать работу, и сделать востребованный restfull api проект в портфолио, то лучше создайте проект по современным стандартам разработки, сразу с ddd и с востребованными на работе технологиями. Этого уже хватит, чтобы найти работу в хорошей компании.

  Рекомендую этот курс

• AgentSmith72, неактуально значит, ладно:( а за курс спасибо емае
• Niksak, обновил ответ, добавив код ревью.