LINUX.ORG.RU

Web на Java: вспоминать основы или лучше сразу Spring+Vue?

 , , , ,


1

2

Давным-давно, лет 5 назад у меня был курс по вебу с сервлетами и JDBC. Уже тогда это было немного устаревшим и разрозненным курсом, а теперь и подавно. Тем не менее JSP и прочие HTTPRequest лежат в основе любого Java фреймворка. При том, что во многом построение страницы нынче делается на клиенте при помощи JS, а сервер лишь ассинхронно передает JSON-ы из базы через Hibernate (если я правильно уловил суть нынешнего мейнстрима в вебе).

Вопрос состоит в следующем: стоит ли мне тратить время и делать проекты как практику на сервлетах или же забить и лучше делать приложения сразу на Spring+Vue?

Ответ на: комментарий от Begemoth

Я скорее в плане насколько стоит лезть в механизмы работы спринга внутренне? Или все настолько бесполезно и проще не париться?

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

JAkutenshi ()
Ответ на: комментарий от JAkutenshi

а пошли они с сервлет-страниц для передачи данных и вызовов функций

Там общего только название, фактически. По смыслу спринговые бины ближе к EJB. IoC, контейнерные транзакции и вот это вот всё.

hippi90 ★★★★ ()
Ответ на: комментарий от JAkutenshi

Бины отдельно, сервлеты отдельно. В современном спринге вообще есть WebFlux, который не основан на сервлетах, а использует асинхронные движки, netty, например.

Begemoth ★★★★★ ()

Я как java-кодер спрошу, почему не go? Платформа относительно новая, многие вещи пишутся не так как на java, там меньше легаси.

Вот например сервлеты у java предполагают что приложение будет запускаться через сервет контейнер, т.е. через jetty или tomcat/jboss которые реализуют Servlet API и могут выступать в роли веб сервера, в это же самое время за пределами java мира все работает self-hosted, т.е. само запускается и конфигурируется, это облегчает деплой в контейнерах. И что же сделал Spring? Как ответил на вызов времени? Появился Spring-Boot со встроенным сервлет контейнером, т.е. легаси хвост.

ИМХО тебе будет тяжело разобраться во всем этом ворохе, а это путь к карго культу, т.е. следованию рекомендуемым практикам без понимая что происходит за ними, наверное заработать сможешь, но хорошим разработчиком так не стать. Я бы начинал расти вместе с комьюнити, т.е. выбрал бы более молодую технологию, где нету 10 разных путей, 10 авторитетных мнений, 10 темплейт энжинов... такая свобода только помешает процессу обучения.

Aber ★★★ ()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от Aber

Я java уже_знаю, так что это не про выбор технологии. И да, у Вас странное в логике:

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

Ну и да, на го насколько я знаю не один веб-фреймоврк, я лично о двух наслышан

JAkutenshi ()
Последнее исправление: JAkutenshi (всего исправлений: 1)

стоит ли мне тратить время и делать проекты как практику на сервлетах или же забить и лучше делать приложения сразу на Spring+Vue?

делать на Spring + любой фронтенд фреймворк.

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

drsm ()
Ответ на: комментарий от JAkutenshi

спринг сделал это удобным

Нет, он сделал это чтоб работало, чтоб можно в быстро свичнуть с сервелт-контейнеров в self-hosted. Servlet API это еще один фреймворк, потому WebMVC это фрейворк над фреймворком и многие вещи без Servlet API не работают, например spring security завязан на фильтры из Servet API, убираешь Servlet API получаешь проблемы с spring security, с жизненными циклами сессии (т.к. сессией управляет сервлет контейнер), и т.д. Так что если выбросить Servlet API станет проще но все поломается и многие старые вещи перестанут работать, поэтому Spring это сложно, путано и проблемы решать затратно по времени. Ну а начинающим разрабам эти сложности и слои абстракций только помешают, зато они легко загонят в стан карго культа.

P.S. не связано с темой, но просто пример как раньше было просто начать кодить на ассемблере. Сейчас даже vim намного сложнее, чем встроенный в Apple ][ ассемблер.

Aber ★★★ ()
Ответ на: комментарий от JAkutenshi

Я не говорю что java плоха, даже сам язык не плох, есть популярные нынче языки которые на мили позади. Но вот spring, не знаю... я бы посмотрел в сторону vert.x, ktor если kotlin и т.д. Хотя я понимаю, что на рынке будет легче себя продать если в резюме будет строчка про spring. Не представляю как эту штуку изучить, а я кодю с ним 10 лет.

При том, что во многом построение страницы нынче делается на клиенте при помощи JS,

Да, сейчас все данные отдают REST'ами на фронт, а там динамически формируется содержимое страницы. Очень редко когда используют template engine, и тогда выбирают либо Thymeleaf, либо FreeMarker, и никогда JSP.

а сервер лишь ассинхронно передает JSON-ы из базы через Hibernate (если я правильно уловил суть нынешнего мейнстрима в вебе).

SpringMVC работает синхронно, Webflux работает асинхронно но его никто не использует, можешь загуглить по объявлениям. В нем асинхронность реализована фреймворком projectreactor, на java асинхронный код тяжело читать и дебажить, не хватает встроенных в язык async/await/suspend.

Hibernet/JPA никаким боком с асинхронностью не работает, у них нет асинхронных api. Если писать асинхронно, то будешь сильно огранчиен абстракциями по работе с базой, например в случае Spring, ReactiveRepository работают только с Mongo, может еще с чем-то но точно не с Redis, для асинхронной работы с Redis нужно использовать низкоуровневую библиотеку. Асинхронность + Spring = проблемы.

на сервлетах или же забить

забить, изучай Hibernet/JPA, реляционные базы данных (postgres популярен) и можно еще добавить не реляционную Mongo (на собеседованиях о ней часто спрашивают).

Aber ★★★ ()
Последнее исправление: Aber (всего исправлений: 1)

Я бы сказал, что лучше всего REST.

На транспортном уровне — JSON или XML поверх HTTP. API сервера описывается языконезависимым образом через WADL (это такой XML) или Swagger (YAML или JSON).

Соответственно, «морду» на этот REST натянуть легко любую — хоть произвольный «веб» хоть на голом jQuery, хоть толстый клиент на JavaFx или даже на Tcl с привлечением Tk, ибо от языка ты не зависишь. В принципе, Web UI можно даже развернуть на отдельном сервере — тебя ничто не ограничивает.

Смотри реализации спецификации JAX-RS 2.0 (Jersey 2, Apache CXF,..) и Swagger.

Bass ★★★★ ()
Ответ на: комментарий от Aber

Вот например сервлеты у java предполагают что приложение будет запускаться через сервет контейнер, т.е. через jetty или tomcat/jboss которые реализуют Servlet API и могут выступать в роли веб сервера

Не предполагают. Встроить полноценный веб-сервер и запустить его очень просто и ничем не отличается от того же Go. Servlet это просто описание API. То, что в Go называется import «net/http», в Java называется сервлет. Кстати если ты пишешь на GCP, насколько я помню, там точно такая же концепция и в Go, никаких self hosted. Это так, для просветления, что всё бывает в разных вариантах.

Кстати в Java есть встроенный веб-сервер и без всяких сервлетов и зависимостей.

Legioner ★★★★★ ()

А зачем тебе целый spring если у тебя на backend-е только rest-сервисы и hibernate? А зачем тебе асинхронно если hibernate работает поверх jdbc, которое имеет синхронный api? Тот же micronaut, что сверху советовали, для асинхронки лучше подойдёт так как у него под капотом rxjava поверх netty и DI статический. С ним ты сможешь ещё в компиляцию в нативный код с помощью GraalVM поиграться, например. Можешь ещё поиграться с реализациями микропрофайла если вдруг так исторически сложилось, что EE-шное тебе ближе. Свежий микропрофайл с CDI-ками сейчас неплох относительно spring и других фреймворков если тебе только rest-ы и реляционные базы надо. А если ты хочешь spring ради spring, а не какой-то специфической «плюшки» из спринговой экосистемы, то смотри в сторону project reactor и webflux-ов.

anonymous ()

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

Знать чего такое сервлеты/jsp и уметь с ними работать понятное дело нужно и полезно. Сейчас они применяются уже не столь широко, но у них есть своя ниша. Так что потратить сколько нить времени на них стоит, тем более они простые как палка.

Тем не менее JSP и прочие HTTPRequest лежат в основе любого Java фреймворка.

Это давным давно не так.

суть нынешнего мейнстрима в вебе

Java прежде всего это бизнес приложения и они не вебе. Они ентерпрайз. А в ентерпрайзе мейнстрим в разных направления очень и очень разный, так и платформы очень и очень разные.

vtVitus ★★★★★ ()
Последнее исправление: vtVitus (всего исправлений: 1)

Не представляю как эту штуку изучить, а я кодю с ним 10 лет.

+1. И это очень сильный аргумент за то, чтобы вообще с ним не связываться.

Встроить полноценный веб-сервер и запустить его очень просто

+1. Embedded Jetty — конфетка.

dimgel ★★ ()
Ответ на: комментарий от xperious
Курс о разработке веб-приложений на Spring

Общая стоимость 60 000 ₽ 

Необходимые знания

    Java Basics
    Multithreading (позже)
    Основы HTML/HTTP/JS
    Основы SQL
    Maven или Gradle

По-моему это бред какой-то, я может отстал от жизни, но блин, с такими знаниями не проще ли пойти работать за 500-1000 баксов java девелопером? А там уже в спринге разбираться по месту, тем более попасть на проект без сприга это как выиграть в лотерею, т.е. маловероятно.

В 2005-2010 годах помню фирмы набирали выпускников на свои курсы, не то что бесплатно, а платили за учебу стипендию (немного конечно - 100-200 баксов), потом оставляли себе лучших. В 10-15 году я работал в фирме которая себе набирала студентов, потом некоторые пришли в штат, никого не гнали, многие находили другие места.

Aber ★★★ ()
Ответ на: комментарий от Aber

ИМХО тебе будет тяжело разобраться во всем этом ворохе, а это путь к карго культу, т.е. следованию рекомендуемым практикам без понимая что происходит за ними, наверное заработать сможешь, но хорошим разработчиком так не стать.

Странная логика. Если тебе нужно сделать что-то, то ты берёшь инструмент и делаешь. Задача решена. Если поставить себе задачу заглянуть под капот, ничто не мешает тебе в свободное от решения первой задачи время изучать внутренности и копать глубже.

Ghostwolf ★★★★ ()
Ответ на: комментарий от Aber

По-моему это бред какой-то, я может отстал от жизни, но блин, с такими знаниями не проще ли пойти работать за 500-1000 баксов java девелопером?

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

xperious ()
Ответ на: комментарий от Ghostwolf

Странная логика. Если тебе нужно сделать что-то, то ты берёшь инструмент и делаешь. Задача решена

ну с таким подходом ты никогда не поставишь вторую задачу в твоем списке - зачем разбираться то под капотом, если задача уже решена?)

xperious ()