Server-side code на сайт с Java

Здравейте, за 7-8 години бях изоставил програмирането и от около година започнах да се завръщам с бавни темпове. Преди 10-15 години например за backend частта на даден сайт с Java се ползваха сървлети, JSP , JSF ,JSTL. Сега се опитвам да направя сайт с новинарска насоченост и логване на потребители евентуално и за известен период си мислех, че мога да ползвам почти същото, което съм знаел и преди. Например от книгата "Интернет програмиране с Java" на Светлин Наков . Предполагах, че ще има нововъведения за последните 10-ина година, но идеята ми беше, че за server-side код спокойно пак ще мога да използвам JSP ,JSF и подобни средства.За целта изтеглих и ето тази книга https://www.amazon.com/Beginning-Jakarta-We...&s=books&sr=1-1 , тъй като от годината на публикуване (2020) си правех изводите, че е сравнително скоро и вътре описаното за уеб програмиране с JAVA имаше доста допирни точки с това, което знаех преди. Относно front-end програмирането(HTML, CSS , JavaScript ) ,както и по бази данни имам съвременни знания , остана само server-side частта.
Обаче от няколко дни започнах да имам съмнения дали не трябва да уча Java framework от рода на Spring, което ще ме затрудни много, защото това вече си е съвсем различно нещо от познатото ми от онова време. На някои места в reddit прочетох, че JSP например било каменната епоха и в наши дни се ползвало Spring. Добре, но нали работи, и то бързо.В посочената книга по-горе "Beginning Jakarta Web Development ... " повечето код е на тази основа, а тя е от 2020, не е от 2005. Ако направя сайт с подобни технологии, толкова ли ще е лошо? За мен е важен performance-а , т.е. да се обработват голям брой заявки(request-и) в секунда.Няма да кандидатствам по обява за Java уеб програмист , където да се иска да познавам Hibernate и Spring. Аз с базите данни съм на добро ниво - и по отношение на design , и по отношение на оптимизиране на заявките и т.н. Front end знанията ми са напълно съвременни, за състезателни алгоритми да не говоря. Много ли ще ме тегли назад, ако за сървърен код използвам леко осъвременени(чрез книгата "Beginning Jakarta Web Development ... ") старите ми знания получени от книгата на Светлин Наков?

Това мнение е било редактирано от nd11 на 13-10-2023, 21:14

Не ти трябва spring. Придържай си се към стандартите и остави модата на модерните

Като цяло, архитектурата на чистото jsp е стара като концепция и напомня доста на php. В смисъл, че ти позволява да правиш страшни мацаници. В което няма лошо де.

Ако искаш обаче да направиш "чист" сайт трябва да се постараеш да приложиш MVC или MVVM шаблон на най-високо ниво. В контекстът на jsp това означава, че трябва да използваш jsp само и единствено като изглед. Там jsp в комбинация с jstl и el са изключително мощен инструмент. За контролери се ползват сервлети (включително, jax-rs имплементация ако ти се налага да разработваш restful приложение).

Лично аз, когато правя сайт поставям всичйи jsp файлове в web-inf (така си гарантираш, че не можеш да ги ползваш диретно и сам се принуждаваш да парвиш контролер през който да ги ползваш). Сървлетите които ползвам за контролери обикновено са мапнати към нещо стандартно като *.html За контролерите обработващи post/put заявки и имплементиращи prg патернът използвам мапване към разни описателни имена като doLogin, doLogout...

С други думи, jsp-то няма да те върне на зад в никакъв случай, независимо как го ползваш.

Между другото, от jsf се отказах, защото налага доста ограничения в опит да раздели изгледите от контролерите, които не ми допадат.

Това мнение е било редактирано от thrawn на 14-10-2023, 06:20

В днешно време сайтовете се правят на JS, и се комуникира със сървъра по REST/GraphQL апи . JSP-та и подобни server-side rendering технологии не се ползват.

Много зависи какво и къде искаш да работиш, ако искаш backend - Spring, a напоследък и Quarkus. За фронтенд - react

Това мнение е било редактирано от Bender++ на 14-10-2023, 09:58

Rest е архитектура и в тоя смисъл изказването е безсмислено.

Ако се абстрахираме от това, какъвто и комуникационен протокол да избереш json, soap, graphql то ти трябва имплементация на нещо което да го обработва от страна на сървърът. Сам по себеси, протоколът не се обработва така че и тук не виждам особена логика.

В контекстът на въпроса - jsp изглед може да генерира както html изход така и json, soap или graphql.

Единствения казус по който може да се дебатира в тая тема е, до колко има резон да се ползва spring в ее сървър.

Благодаря за отговорите!

Да, точно такова ползване на JSP и Servlet-и имах предвид , с MVC направено. Това,което си написал в този абзац е основен приом на примерите от книгата с линка от амазон от 2020 и съм го усвоил не лошо.
Значи казваш, че ако например сайтове като gol.bg или jobs.bg бъдат направени да изглеждат точно както са в наши дни(и са responsive) , но само сървърния им код използва JSP в комбинация с JSTL и EL , то на тези сайтове няма да се гледа като на демоде от програмистка гледна точка и няма да работят по-бавно в сравнение ,ако са направени със Spring? От страна на потребителя - повечето пъти не може да се разбере какъв език и технология са използвани за backend , но имам предвид програмист,който е в крак с днешните стандарти, ако види кода на такъв сайт ,то той няма да каже, че сайт написан така е един бавен боклук?

Jsp по същество е сервлет мапнат към *.jsp. Spring също е имплементиран като сървлет. Така че, в общи линии ако ще ползваш ee сървър в java за да реализираш web приложение, щеш нещеш минаваш на/през servlet.

От тук на татък, всеки фреймуорк надгражда и дава някаква допълнителна функционалност която да ползваш на готово. Какво би казал някой като види код не мога да кажа, но защото питаш за скоростта - директно извеждане на текст от сървлет (най ниското ниво до самия web контейнер) няма как да е по-бавно от извеждане на същия текст от произволен фреймуорк които в основата си е сървлет.
С други думи, jsp ще бие spring. Или ако не го бие, поне ще се представят на равно.

Това дали сайтът е демоде или не, не се определя от това дали ползваш някаква модерна библиотека а от това дали следва съвременните тенденции. Да речем, ако правиш асинхронно извличане на данни (модерна тенденция) ще си демоде ако ползваш xml (да речем soap). Този протокол отдавна е изместен от json и в момента, това се ползва масово. Ако искаш да си модерен обаче избираш graphql (аз не виждам особен смисъл в това да пестиш мрежов трафик за смета на изчислителен ресурс, ама все пак...).

Ами не е така. РЕСТ е дефакто стандарт за комуникация между сървъра и клиента. А това дали му казваме апи, архитектура или какво и да е друго е без значение. Ако не разбираш поне малко от рест, няма да те вземат и за сайт за лютеница.

Ами не, не може. Примерно GraphQL си има собствен език за описание на схемата на данните, И ти трябва framework, който да се занимава с парсването, извличането на данните и последващото форматиране, така че да отговаря на зададената схема.

ЕЕ сървърите умряха. Няма повече ЕЕ, безсмислени са. Никой не ги ползва продуктивно. Всичко се прави на спринг, а напоследък и Quarkus стана доста популярен, като и той е спрингоподобен.

Ако целта на автора на темата е да си намери работо, ЕЕ с нищо няма да му помогне. Никой не се интерсува от ЕЕ. За работа - спринг. Ако си цъка нещо за кеф, тогава е все тая.

Рест по дефиниция е stateless архитектура клиент сървър. Демек, 90% от нещата които са клиент / сървър имплементират rest. Включително и http е rest.

Това на което му се вика rest api или само api е приложение имплементиращо рест архитектура (клиент сървър) върху http протокол. На това му се вика restful (rest по дефиниция не е обвързан с протокол)

GraphQL също е rest.

Като имплементация - това (graphql) е ясно дефиниран комуникационен протокол следващ схема заявка / отговор и абсолютно нищо не ти пречи да си го разпишеш с гол сървлет (каквато ще е и имплементацията на всичко което живее в някаква що годе стандартна форма на web контейнер).
Дали има смисъл да го правиш? Най-вероятно не, точно както няма сисъл да си имплементираш json комуникацията (jax-rs).

Между другото, след като така си го захапал тоя graphql, spring поддуржа ли го директно?

Това мнение е било редактирано от thrawn на 14-10-2023, 16:23

То отдолу на джава е все сървлети и филтри, без значение какви "ла.на" има отгоре.

Ами не , не е рест. И да, поддържа го.