"Подружить" Spring Boot - REST API и html - JavaScript

Я верно понимаю? В итоге у меня должен быть проект JS который представляет собой Single Page Application и имеет какой-то свой URL по которому юзер его находит. И проект Spring Boot который имеет свой набор URL, но эти URL юзер не видит, они нужны для того что бы JS по ним обращался к бэкэнду.

- single page или нет - неважно, важно чтобы JS-код умел делать HTTP-запросы; - JS-приложение может работать под управлением отдельного WEB-сервера (Apache, Nginx и т.д.), в этом случае если закрыть для пользователя порты Spring-приложения, то бэкэнда он не увидит. Пример: сервер (софт) Nginx живёт на сервере (железка, виртуалка) по адресу http://myserver.ru (или для внутренней сети предприятия по адресу 10.11.12.13). У него в конфиге прописана папка с твоим приложением (index.html и т.д.). При старте сервера он начинает раздавать твоё приложение на порт 80. Это называется "раздавать статику" (несмотря на то что там есть не только html и картинки, но и Java Script). Если пользователь зайдёт браузером на страничку http://myserver.ru или http://10.11.12.13 - он увидит твой index.html. Spring-приложение работает на этом же (или другом) сервере, там крутится http-сервер Tomcat или Netty, который отзывается на порт 8080 и отдаёт твои REST-точки, например, http://10.11.12.13:8080/users?name=Вася отдаст JSON с инфой про Васю. Твоё JS-приложение знает адрес/порт бэкэнда, ходит по этим точкам, заполняет HTML-шаблон с разметкой данными про Васю и через Nginx отдаёт их пользователю. Если на сервере порт 8080 будет закрыт для доступа извне, то пользователь не увидит бэкэнд (те самые JSONы), а если открыт, то он может так же сделать запрос http://10.11.12.13:8080/users?name=Вася и получить тот же самый JSON. Это называется "предоставить API" чтобы пользователь мог сам получать "сырые данные" и пилить из них свои приложения. Пример из интернета.

- сервер, который поднимает Spring (Tomcat или Netty) - это http-сервер, а значит его тоже можно научить раздавать статику. У тебя в приложении есть папка src/main/resources/static. Ты можешь скопировать туда своё JS-приложение (прописав в нём все пути как относительные) и сделать соответствующий конфиг для Spring. В этом случае твой index.html будет показывать именно Tomcat (Netty) и при этом точно так же будут работать твои REST-точки. Но тогда ты не сможешь разделить фронт и бэк, т.е. если пользователь имеет доступ к web-страничке, то он точно так же имеет доступ к REST-точкам - порт-то один и тот же. ЗЫ: точнее, доступ разделить можно, приписав соответствующие правила для Spring Security

Спасибо за развёрнутый ответ, я почти всё понял. Главный вопрос для того что бы пробовать делать это руками: это будут два отдельных проекта, верно? Например один REST API на Spring Boot, а второй какой-нибудь React c прокаченной вьюхой. И работать это будет при запуске обоих серверов (например из двух окон IDEA) Далее я могу научить Spring Security воспринимать React как определённого юзера и запретить отвечать на запросы от кого бы то ни было ещё. Но это опционально.Так?

Есть вариант попроще. В Spring есть такое понятие как шаблонизатор, их несколько разных: Thymeleaf, Mustache и пр. Смысл такой же как в варианте с раздачей статики прямо из Спринга. Но простота в том что ты пишешь обычный HTML и него в определённом синтаксисе "внедряешь" Java-объекты. Например, пишешь

< p >Имя: {{user.name}}< /p >

а на страничке в этом месте увидишь поле name объекта user. Но шаблонизаторы предназначены для очень просто фронта, в расчёте на то что вся логика реализована в Java-коде. В любом из вариантов с раздачей статики из Спринга (шаблонизатор или сторонний JS-код как я писал выше) запускать надо только один проект - собственно Спринг. В случае когда фронт работает на отдельном порту - проекта будет два. По части secutiry - Spring настраивается на авторизацию с определёнными параметрами: логин/пароль, токен или что-то ещё. Фронт либо "пробрасывает" эти параметры от пользователя, либо они там захардкожены, но какая тогда тут секъюрность? Пример работы с шаблонизатором. Также рекомендую посмотреть и поделать примеры отсюда, также см. другие плей-листы с этого канала.

Если уж задействовать бекэнд часть, то можно ее написать на той же Java. Мне кажется ему хотелось делать запросы с фронта. Тут скорее ajax нужен имхо.

Да, речь о том что бы написать бэкэнд на Java и разработать для него достойный, современный фронтэнд. И самое главное увязать всё это вместе.

Я скажу сейчас не очень популярную мысль, но если ты бэк энд, то и будь бэк эндом. Фронт это отдельная и достаточно сложная дисциплина. Не нужно пытаться охватить все. Стань специалистом в чем то одном и у тебя уже будет профессия.

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

Ну я же сказал не популярную :) Работодатель в целом любит платить по меньше, отсюда появились все эти модные T-Shape и все такое - имхо - шляпа полная. Но вот аргумент про интересно я горячо поддерживаю, потому как это действительно так. А что до похожих друг на друга проектов, это уже больше от фантазии зависит :) У меня например нет каких-то ярко выраженных пет проектов, но есть ряд инструментов под собственные нужды. Один из них кстати с кривеньким фронтом сверстанным на бутстрапе и ванильном JS. Я к тому, что вот так сесть и выдумать проект конечно сложно и все они будут однотипными, но если начать реализовывать что-то прикладное, для повседневной жизни - спектр задач может расшириться существенно.

Я так и сделал когда решил узнать что такое JavaFX, написал калькулятор специфичный для коллег по прошлой работе. Но это заняло три дня. А вот придумать хорошую, разносторонне-развивающую задачу для пэт проекта, это пожалуй и есть самое сложное в пэт проекте. В этой ситуации достойной альтернативой кажется написание фронтэнда для уже существующего REST API, новый синтаксис, непривычный подход к решению задач - отличная тренировка для развития мышления за рамками шаблонов.