ПО для быстрой разработки кросс-платформенных ВЕБ приложений.

 
 
 
Сообщения:8
Опубликован набор ПО для быстрой разработки кросс-платформенных ВЕБ приложений.
За счет JEE сервера А-Джетти работает везде - Андроид и стандартная Джава.
Код библиотеки базового ВЕБ-интерфейса основанного на JSP/JSON - https://github.com/demidenko05/beige-web
Все остальное там-же.
Собственный ОРМ, генератор отчетов в PDF.
ОРМ работает быстро и на смартфоне за счет автоматической генерации SQL запросов с Join-ами по настройкам в ХМЛ файлах.
Все с открытым кодом и свободной лицензией.
Пробуйте, найдете ошибки - пишите.
 
 
Сообщения:1550
Jetty не является JEE сервером. А что такое «кросс-платформенное веб-приложение» я прям даже и не знаю. Кроме того, JSP/JSTL — это очень старо и неэффективно, так как не SPA. Ваш собственный ОРМ реализует спецификацию JPA?

Software and cathedrals are much the same — first we build them, then we pray.
 
 
Сообщения:877
YDemidenko:
Опубликован набор ПО для быстрой разработки кросс-платформенных ВЕБ приложений.
За счет JEE сервера А-Джетти

Вы представляете себе что есть JEE сервер? И какие спецификации он должен реализовывать?
 
 
Сообщения:8
Например JEE Servlets, JSP, Authentication...:
https://javaee.github.io/javaee-spec/javadocs/
...

JEE without EJB это классика на котором спринг, стратс и хибернейт победили

JSP - https://system.netsuite.com/pages/customerlogin.jsp - на чистом JSP, т.е. даже без сервлет-контроллера
Какой процент спринг (стратс...) приложений используют фэйслетс в качестве рендера по Вашему?
 
 
Сообщения:1550
Ок, чем ваше изобретение лучше Спринг Бута?

Software and cathedrals are much the same — first we build them, then we pray.
 
 
Сообщения:461
а еще есть kubernetes
 
 
Сообщения:1550
keekkenen:
а еще есть kubernetes
Кубернетис из другой сферы.

Software and cathedrals are much the same — first we build them, then we pray.
 
 
Сообщения:8
nazica:
Ок, чем ваше изобретение лучше Спринг Бута?


Программирование это абсолютно ТОЧНАЯ наука. Нравится/ненравится подходит для других областей.
Приведите пожалуйста другой РЕАЛЬНЫЙ пример СЛОЖНОГО (в т.ч. отчеты в пдф), быстро строящегося приложения, БЫСТРО работающего и на Андроиде (И сервер базы данных И сервер приложений должны работать на Андроиде).
И оно должно быть МАКСИМАЛЬНО по ДЖЕЕ стандарту (например вар, веб.хмл...).
И большие системы работают с прямыми СКЛ запросами т.к. быстрее чем ДЖПА.
Из нестандартного что заменяет стандартное в данных библиотеках только легкая ОРМ автоматически генерирующая ОПТИМАЛЬНЫЕ скл запросы.
Автоматические нтмл формы сделаны на ДЖСП и простых настройках из ДЖСЕ хмл пропертиес файлов (95% стандартного, 5% кустарная библиотека по извлечению настроек)
 
 
Сообщения:877
YDemidenko:

Приведите пожалуйста другой РЕАЛЬНЫЙ пример СЛОЖНОГО (в т.ч. отчеты в пдф), быстро строящегося приложения, БЫСТРО работающего и на Андроиде (И сервер базы данных И сервер приложений должны работать на Андроиде).

JEE на Андроиде??? :D Давно так не смеялся
YDemidenko:

И оно должно быть МАКСИМАЛЬНО по ДЖЕЕ стандарту (например вар, веб.хмл...).

web.xml с версии JEE7 вообще не нужен.
 
 
Сообщения:9906
nazica:
Ок, чем ваше изобретение лучше Спринг Бута?
Хых, лучше Бута быть не сложно - можно просто ничего не создавать и это будет лучше спринг бута :)
YDemidenko:
Программирование это абсолютно ТОЧНАЯ наука.
Ну программирование - не наука. Да и в данном случае вопрос не "что быстрей - bubble sort или sleep sort", и не в том какой инструмент какие возможности поддерживает (это был бы просто перечень фактов), а как раз в том нравится ли инструмент кому-то или нет. Инновационные инструменты которые сложно повторить не обязательно должны нравиться потому что они позволяют делать что-то что невозможно достигнуть другими средствами. Но у тебя не инновационный инструмент, соответственно тебе в процессе твоей маркетинговой кампании должно быть важно нравится ли инструмент другим.

Кстати, даже в настоящих науках нравится/ненравится - это постоянный фактор. Как в выборе софта, так и в выборе хардварных инструментов.
nazica:
Кроме того, JSP/JSTL — это очень старо и неэффективно, так как не SPA.
SPA - не обязательно эффективней серверных страниц. Учитывая что при загрузке 1ой страницы приходится подгружать все UI приложение он может быть наоборот менее эффективен. А делает SPA то же самое что и обычное серверное приложение - формирует HTML по шаблонам.
YDemidenko:
работающего и на Андроиде (И сервер базы данных И сервер приложений должны работать на Андроиде).
Я никогда не разрабатывал под мобильник, может чего не понимаю.. Но зачем на Андроиде запускать веб сервер?
YDemidenko:
И большие системы работают с прямыми СКЛ запросами т.к. быстрее чем ДЖПА.
Большие системы работают как на "прямом" SQL, так и на Hibernate, и даже через JPA или Spring Data. Увы, сегодня технологии выбираются не по тому насколько они подходят, а по тому чем программисты умеют (или еще хуже - хотят научиться) пользоваться. Ну и "прямой" SQL не всегда быстрей ORMов.
YDemidenko:
Автоматические нтмл формы сделаны на ДЖСП и простых настройках из ДЖСЕ хмл пропертиес файлов (95% стандартного, 5% кустарная библиотека по извлечению настроек)
В современной разработке такой способ больше не котируется. Да, лет 5-10 назад когда BE разработчики не хотели/не умели UI то были популярны всякие автоматические формы (JSF, GWT/Vaadin, ZK), однако оказалось что хороший (красивый и удобный) продукт так не сделать. Плюс появилось много UI разработчиков. Так что это больше не актуально.
gidravlic:
web.xml с версии JEE7 вообще не нужен.
Без него можно, это не значит что без него нужно.
YDemidenko:
За счет JEE сервера А-Джетти
В Java когда говорят JEE апп сервер имеют в виду реализацию полного EE стека включая JPA ORM, JTA, JMS, EJB, и пр. Если скажешь просто application server или servlet container - тогда (почти) никто не обидится :)


Когда потратил много времени на что-то, а оно оказалось никому не нужно - это сложно принять. Но чем быстрей это понимание прийдет, тем меньше ты еще потратишь времени в никуда. Я тоже много бесполезных наработок сделал в своей жизни, но такие ошибки - это опыт, теперь этот опыт нужно использовать во благо человечеству.
Изменен:22 дек 2019 10:34
 
 
Сообщения:1550
Что. Вы. Курите.

Software and cathedrals are much the same — first we build them, then we pray.
 
 
Сообщения:1550
Староверъ:
SPA - не обязательней эффективней серверных страниц.

СПА часто эффективнее «серверных страниц» с точки зрения UX. Заставить пользователя ждать лишнюю секунду на загрузку всех компонентов — не проблема, а если заморочиться ленивой загрузкой, тогда проблемы кагбэ и не будет. Плюс растущая скорость сетевых каналов у пользователей.

Но, естественно, соглашусь с тем, что в некоторых случаях даже JSP будут достаточны для решения задачи.

Староверъ:
А делает SPA то же самое что и обычное серверное приложение - формирует HTML по шаблонам

Угу, без нетворк латенси с моментальным отображением компонентов интерфейса при переходе между логическими страницами и с кэшированием данных на стороне FE.

Староверъ:
Учитывая что при загрузке 1ой страницы приходится подгружать все UI приложение он может быть наоборот менее эффективен

Учитывая, что современная страница имеет мегабайты цсс и картинок с котиками, то рендерь ты ее хоть серверсайд, хоть на FE, пользователю придется грузить массу данных из сети.

Староверъ:
Увы, сегодня технологии выбираются не по тому насколько они подходят, а по тому чем программисты умеют

Да, потому что на Хибернейте разработчик решит задачу в разы быстрее и с меньшим количеством последующих ошибок, нежели решая её на каком-нибудь Spring JDBC template, не говоря уже про plain JDBC. А если кто-то озабочен производительностью ORM, то для таких случаев есть секретное слово — кэш второго уровня. Только никому не говорите.

Староверъ:
Если скажешь просто application server или servlet container - тогда (почти) никто не обидится

Я обижусь. Джетти — это сервлетный контейнер, а не application server.

Software and cathedrals are much the same — first we build them, then we pray.
 
 
Сообщения:9906
nazica:
СПА часто эффективнее «серверных страниц» с точки зрения UX. Заставить пользователя ждать лишнюю секунду на загрузку всех компонентов — не проблема, а если заморочиться ленивой загрузкой, тогда проблемы кагбэ и не будет. Плюс растущая скорость сетевых каналов у пользователей.
Не оч понимаю что такое эффективность с точки зрения UX... Медленное приложение - это медленное приложение. UX - это эргономика приложения, т.е. насколько фичи приложения способствуют удобной работе пользователя.

nazica:
Угу, без нетворк латенси с моментальным отображением компонентов интерфейса при переходе между логическими страницами и с кэшированием данных на стороне FE.
1. Ты с одной стороны говоришь что небольшая задержка при переходе между страницами - это критично и поэтому SPA - это круто, а с другой - что долгая задержка при изначальном открытии сайта - это ерунда и поэтому у server pages нет плюсов. Надо бы определиться :)
2. Моментальное отображение элементов и до SPA было (AJAX никто не отменял). Кеширование данных на стороне http server'ов и браузера тоже было. Современными браузерами можно даже prefetching делать. Если логически разбить страницы на общие данные для всех пользователей и что-то специфичное для каждого, то 1ую часть можно полностью кешировать (вместе со всем HTML'ем) на nginx'е, а вторую подгружать AJAX'ом.

Есть прекрасный пример серверных страниц - StackOverflow который не является SPA и обрабатывает огромное кол-во запросов очень быстро. Стал бы SO быстрей если его переписать на SPA? Может да. А может нет. Зато пришлось бы решать проблемы с индексированием поисковиками.

nazica:
Учитывая, что современная страница имеет мегабайты цсс и картинок с котиками, то рендерь ты ее хоть серверсайд, хоть на FE, пользователю придется грузить массу данных из сети.
Если писать через пень-колоду, то неважно это будет SPA или нет. У меня счас огромный SPA проект и там все равно мегабайт стилей не набирается. Не знаю что нужно делать чтоб были мегабайты CSS. А картинки грузятся лениво. Мы ж наверно в этой дискуссии обсуждаем все-таки два случая: хорошо написанный SPA и хорошо написанные серверные страницы?

У SPA есть другое преимущество - можно найти UI разработчиков которые хорошо разбираются в верстке и JS. К сожалению даже среди UI разработчиков таких мало, но наверно чуточку больше чем среди бекендчиков :)

nazica:
потому что на Хибернейте разработчик решит задачу в разы быстрее и с меньшим количеством последующих ошибок, нежели решая её на каком-нибудь Spring JDBC template, не говоря уже про plain JDBC.
Я решу задачу на Hibernate быстрее. Потому что я хорошо знаю Hibernate и практически не писал приложений c SpringJdbc. Тот кто писал на SpringJdbc и не изучал целенаправленно Hibernate наоборот - будет писать на нем медленней. И уж точно с большим кол-вом ошибок потому как Hibernate - это более высокоуровневый инструмент и чтоб на нем писать хорошо нужно знать SQL, общие ORM паттерны, непосредственно Hibernate и многочисленные проблемы которые с ним возникают. Буквально на прошлой неделе мне пришлось дебажить и искать проблему которая возникала из-за неправильной работы с односторонними связями, которую никто больше из моей команды не смог бы найти (хотя работают с Хибом уже несколько лет). Так что ошибок и сложностей которые возникают с Хибом много и их так просто не понять если не потратить на целенаправленное изучение Хиба годик-другой.

nazica:
А если кто-то озабочен производительностью ORM, то для таких случаев есть секретное слово — кэш второго уровня.
Еще есть пару секретных терминов - blue-green деплои и кластеры :) Об них кеш 2ого уровня разбивается потому как он stateful и чтоб его использовать прийдется также внедрить кеш "3его уровня" (распределенный кеш) с помощью JGroups и прочих. А это сложные звери со своими проблемами. В некоторых проектах кеш 2ого уровня наверняка поможет, однако нужно также понимать его проблемы. В современных условиях Continuous Delivery и zero-downtime'a он будет мешать.

Ну и нужно понимать что любой кеш будь то 2ого или 3его уровня - это key-value хранилище где key - это ID сущностей. Т.е. он срабатывает без SQL запросов только на session.get(), session.load(), а также для ленивых MTO/OTO связей (которых как правило мало). В остальных случаях все равно будет SQL запрос. А это большинство случаев. Если эти запросы медленные, то все приложение будет медленным.

nazica:
Я обижусь. Джетти — это сервлетный контейнер, а не application server.
Поэтому я написал "почти никто не обидится" :) Да, когда-то в Java сообществе были люди которые считали что есть взаимоисключающие понятия Application Server'ов и Servlet Container'ов. Но это конечно было неправильное использование терминов, в целом весь мир (на Java свет клином не сходится) использует такую терминологию:
- web server - софт который обрабатывает веб запросы. Представители: nginx, apache httpd. Также их называют http daemons, http servers.
- app server - это веб сервер который также позволяет внутри себя запускать приложения. Представители: Jetty, Tomcat, GlassFish, WebLogic, Netty, etc.

В Java апп сервера делят еще на:
- Servlet Containers: Tomcat, Jetty
- JEE App Servers: GlassFish, WildFly, TomEE, etc.
- Позволяющие писать веб приложения без сервлетов: Netty, Play! Framework

Так что да - Jetty является Servlet Container'ом, но само это понятие входит в superset Application Server'ов.
Изменен:22 дек 2019 12:40
 
 
Сообщения:1550
Староверъ:
Не оч понимаю что такое эффективность с точки зрения UX... Медленное приложение - это медленное приложение. UX - это эргономика приложения, т.е. насколько фичи приложения способствуют удобной работе пользователя.

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

Что не отменяет
Староверъ:
Моментальное отображение элементов и до SPA было

Я же написал: При переходе между логическими страницами. Аджакс тут поможет только если его использовать извращенно и в этом случае у тебя получится свой СПА-велосипед.

Староверъ:
Кеширование данных на стороне http server'ов и браузера тоже было

Конечно! Только вот браузер даже в случае использования HTTP кэша может отправлять запросы на сервер и получать 304 Not Modified.

Староверъ:
Если писать через пень-колоду, то неважно это будет SPA или нет.

Совершенно согласен!

Староверъ:
У меня счас огромный SPA проект и там все равно мегабайт стилей не набирается. Не знаю что нужно делать чтоб были мегабайты CSS

мегабайты цсс и картинок (и прочей статики типа шрифтов) ;)

Староверъ:
и кластеры

Ох, да, точно. Но если у нас sticky session, то кэш там будет отрабатывать нормально. В любом случае тебе нужно кэширование в высоконагруженном приложении, вопрос только в том, куда этот кэш впихнуть и будет ли оно OOTB или нет.

Староверъ:
Так что да - Jetty является Servlet Container'ом, но само это понятие входит в superset Application Server'ов.

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

------------------

Ту конклюд зе спич ибо что-то я перевел все в оффтопик (давно Станислава не видел): Я не про пропагандирую бежать и переписывать все на СПА, если у владельца простой интернет-магазин/форум, то бенефитов от СПА он может и не получить. Не забываем, что СПА вполне может быть реализован с помощью JSP/JSTL ибо html страничка с жквери и кучей аджаксов — это вполне себе СПА; мой поинт об устаревании JSP/JSTL связан с плохим разделением BE и FE, когда веб-дизайнеру нужно лезть в серверный код своими мохнатыми ручками.

Software and cathedrals are much the same — first we build them, then we pray.
Изменен:22 дек 2019 12:50
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет