Strannyk

Сначала идет ТЗ. Потом - протоколы взаимодействия. А потом - уже все равно, хоть одновременно и веб и фронт. Это в сферическом идеале.

namecheap

обычно, наличие клиентского роутинга подразумевает, что сервер на любой url должен отдавать один и тот же index.html. потом, уже на клиенте в этом index.html инициализируется клиентский роутер и в зависимости от url'a в адресной строке браузера показывает юзеру тот или иной интерфейс или данные(страницы 404 и подобные, также завязаны на клиентском роутере). серверный роутинг в даном случае может применяться для создания endpointo'в для API.

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

Про сессию уже написали. Ещё вариант - это использовать local strorage на стороне клиента и писать-читать из него (немного поработать с js).

Если варианты выше не подходят, то можно в отдельной таблице хранить проекты заявок. Т.е. пользователь сначала создаёт проект заявки первым запросом - сохраняем его в отдельную таблицу, а потом на каждом шаге в эту запись добавляются данные с отдельных форм. В финале этот проект становится заявкой - удаляется из таблицы проектов и переносится в таблицу заявок. Это решение не зависит от состояния сессии и local storage. Пользователь может продолжить заполнять заявку с другого клиента в другой сессии, ведь мы храним его проект у себя в базе. Как бонус, таким макаром можно при необходимости организовать пользовательские шаблоны заявок (если форма большая и пользователем большая её часть вводится одинаковая), чтобы быстро создавать новые заявки из сохранённых шаблонов.

Если требованиями not null полей можно немного принебречь, то можно ввести статусы заявки или флаг является ли заявка проектом и хранить их в одной таблице. Тоже, что и в предыдущем варианте, но только всё в одной таблице и в итоге мы просто меняем статус или флаг записи.

Ещё вариант, если у вас есть html, который не меняется по ходу изменения форм (т.е. вы просто меняете куски страниц при переходе по формам), то можно завести скрытые поля, куда дублировать заполнение формы пользователем. В итоге у вас эти скрытые поля заполнены и именно их содержимое отправляется на сервер в итоге. Видел такое на старых проектах.

В проектах с SPA такой проблемы нет, т.к. в таком случае на клиенте просто выполняется управление состоянием и роутингом

Аккумулировать данные в сессии

через ref:

<button @click="$refs.child.someMethod()">call child method</button>
<child-component ref="child"></child-component>

IDE тут вообще не при чём. Всё можно хоть в блокноте делать.
Для генерации проекта с кучкой зависимостей, которые вы выбираете мышкой вам сюда - https://start.spring.io/ .
Разберитесь с maven и pom.xml, как подключить репозиторий. Всё, что вам надо знать - это название либы, дальше идёте в mvnrepository, ищите её и там даже код есть для копи-пасты - https://mvnrepository.com/repos/central. Например - https://mvnrepository.com/artifact/org.apache.comm...
Можете в jar запихать с embedded tomcat, можете в war пихать. IDE тут не причем. Всё можно делать в комьюнити. Не знаю, какие туториалы вы смотрите, но советую посмотреть на https://spring.io/guides - они простые, там всё описано по шагам, даже содержание pom.xml. Даже есть переводы - spring-projects.ru/projects/spring-framework

Гуглим по запросу

Fatal error compiling: invalid target release: 11 -> [Help 1]

Переходим на ссылку: https://stackoverflow.com/questions/28291691/fatal...
Читаем и понимаем что не та версия jdk использовалась
Анализируем разницу и понимаем что нам нужен target release: 11

Никаким. Если вы скопируете неупорядоченный массив, то получите ещё один неупорядоченный массив.

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

Важно понимать, что паттерны проектирования - это просто хорошие идеи по поводу того, как организовать большой объем кода в той или иной ситуации. Это не "изучи тайное знание, запомни, и делай так всегда", не "используй паттерны, потому что великие их используют", это скорее "если не уверен как организовать код, возьми готовую идею, она вроде работает". Если вы будете просто решать задачи, то через N лет практики вы сами их все "изобретете", только не будете знать, что у них есть названия. Эффективно будет организовать себе заметку о том, какие из этих идей для чего примерно применяют, а потом, в процессе работы, в нее подглядывать, если встал вопрос "как организовать этот код".

import ItemCard from '@/components/card/itemCard.vue'

Object.values(obj).reduce((sum, current) => sum.concat(current), []);

где obj ваш исходный объект

Самый модни-мжвячни-современни способ - это так:

Object.values(yourObject).flat()

Естественно, flat не работает в микрософтовских браузерах, поэтому понадобится Бабел или полифил.

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