Aplikacje internetowe w Javie - czyli napisałem swój własny framework i co dalej?

Po wieloletniej przerwie, witam wszystkich forumowiczów :)

Koledzy, zbłądziłem, pomóżcie..

Jakiś czas temu uparłem się, że napiszę sobie portal internetowy. Niestety, z miłością do baz danych Oracle, z alergią na PHP, ze znajomością Oracle ADF i podstawami Javy wizja portalu była naprawdę mroczna.
ADF się nie nadaje, bo to ADF.
JSF się nie nadaje, bo to framework oparty na komponentach, a przecież portal to html, css, js, jquery, bootstrap itd.. Więcej walki niż korzyści.
Freemarker? RESTful API + Angular? Niby ok, ale nadal mi nie pasuje. Nie pasuje mi model w J2EE. Rozumiem, że logika aplikacji powinna być gdzieś pomiędzy Javą a bazą danych, ale skoro dane siedzą w bazie (Oracle), to najłatwiej na nich pracować z procedurami PL/SQL, a nie robić specjalnie dla nich Javowe obiekty/encje.
Po przejrzeniu kilku tutoriali Angular też nie wydaj się być banalny.

Postanowiłem załatwić to tak: wszelkie operacje na danych są w PL/SQL. Procedury składowane również wykonują zapytania i zwracają XMLa do Javy. Ta parsuje to na JSONa i wypluwa go servletem. JavaScript pobiera tego JSONa oraz partial html i renderuje wynik. Tak to w skrócie działa. Doszły do tego jeszcze templaty html, pliki językowe, security (Apache Shiro), walidacja oraz prerender dla Google bota.

Portal w tym frameworku: https://extrememap.com (póki co na domowym łączu).

Pytanie do programistów Java, najlepiej tych co znają bazy danych Oracle:

Czy interesuje Cię taki framework? Chciałbyś spróbować w nim napisać jakąś aplikację?
Czy warto udostępnić go na githubie? Opisać, udokumentować, otworzyć kod, rozwijać dalej?
Czy uważacie, że napisaną aplikację w takim rozwiązaniu mógłbym sprzedać klientowi? Tak, skoro napisana w Javie i działa to ok. Nie, nikt nie będzie chciał Twoich własnych rozwiązań, liczą się tylko znane frameworki.

Zapraszam do luźnej dyskusji :)
Wojtek.

1. Na pewno warto opublikować na git. Chętnie popatrzę na to coś :)
2. Stronka o rowerach to użyję rowerowej metamorfozy. Chciałeś pojechać w góry, ale najpierw postanowiłeś zbudować rower. Nauczyłeś się jak się spawa, wierci i dokręca śrubki. Ostatecznie wyszedł fajny składak jak z PRL i nawet udało się dojechać do Nowego Sącza :) Widocznie łatwiej Ci się myśli w modelu tabelek i tyle. Może po prostu jest to na razie jedyny model jaki znasz.
3. Co do sprzedaży to według mnie byłoby to nie moralne. Kiedyś jak miałem 17 lat zrobiłem babce stronkę - bloga w czystym PHP. Zapłaciła mi 200 zł, ale po miesiącu zamieniła na wordpress. Było mi głupio.
4. Dodatkowo to chyba nie jest framework do końca.

Framework to może faktycznie mocne określenie i wcale mi nie zależy na tym, by tak to nazywać. Jednak pisanie aplikacji w tej chwili sprowadza się do podania nazwy procedury składowej i listy jej parametrów. Otwieraniem i zamykaniem połączenia do bazy danych, obsługą błędów i logowaniem, parsowaniem do jsona, walidacją danych, wyświetleniem danych zajmuje się hmm framework. Albo po prostu to narzędzie, które napisałem. Jak zwał tak zwał :)

To prawda, że pisząc to wszystko czułem się jakbym wynajdował koło na nowo. Pewnie tak było. Szukałem różnych rozwiązań, ale nic sensownego i łatwego nie mogłem znaleźć. Więc jakie są alternatywy dla osoby chcącej napisać portal internetowy w Javie? Tylko Spring RESTful i Angular?

Jak będę miał chwilę to zrobię dokumentację i udostępnię kod :)

Jak dla mnie dla typowego portalu z dużą liczą tabel JSF + PrimeFaces jest dość ok. Szczęśliwie ominęła mnie praca z ADF, ale kiedyś próbowałem i to się nie nadaje do niczego. Wiadomo, jak chcesz to skalować dowolnie to prościej użyć REST API (kosztem wolniejszego developmentu, coś za coś: mniej klastrowania sesji, mniej się może sypnąć). Nie rozumiem dlaczego logika miałaby być implementowana po stronie bazy: dla mnie to ostateczność, gdy wydajniej się nie da. Strasznie ciężko się to testuje. Komponenty są więcej jak ok dla typowego korpo portalu. gdy nie ma kasy na tworzenie własnych (często nie potrzeba nic wyrafinowanego, więc jest to ok): dużo tabel i raportów. Ok jest też tworzenie własnych jak masz na to $$$ (np. React odpowiada tylko za to po stronie frontendu).

Chętnie rzucę okiem na ten wynalazek z ciekawości. Ale nie jestem przekonany co do umieszczania logiki po stronie bazy.

Jeśli Java służy jedynie do konwertowania XML-a na JSON-a to po co ta Java?
Nie lepiej zastosować coś lekkiego? node.js lub PHP?

Może nie tyle logika, co operacje na danych po stronie bazy. To właśnie był fundament tego całego przedsięwzięcia.

Przykład. Chcemy zrobić insert z formularza do 5 tabel, w tym sprawdzić wartości w dwóch innych. Możemy biegać po encjach w javie, które w tle pewnie wykonają zapytanie żeby aktualizować swój stan, przez co nie jest to ani łatwe ani wydajne. Dużo lepiej jest przekazać dane w parametrach do procedury składowanej i załatwić to wszystko jednym requestem do bazy. Oczywiście są to moje preferencje budowania aplikacji, jednak javowe frameworki prowadzą zupełnie inną politykę. Model siedzi w javie, a to jak aktualizowane są w niej dane to już nie Twoja sprawa. Z jednej strony daje to elastyczność podmiany bazy danych, z drugiej pozbawia wielu dobrodziejstw, jakie oferuje np. Oracle.

Rozmawianie o wyborze technologii jest o tyle ciężkie, że żeby obiektywnie określić wybór, musiałbym bardzo dobrze znać wiele z nich. Nie znam. Przyznaję, że zanim zacząłem uczyć się javy, pisałem trochę w plsql, stąd moje preferencje. Z drugiej strony strony gdybym zaczynał od javy, to możliwe, że nie walczyłbym o procedury składowane :)

Faktycznie rozmowa o tym ile warty jest ten framework na chwilę obecną jest dość trudna. Po udostępnieniu kodu, zrobienia dokumentacji i tutoriali byłoby dużo łatwiej. Jak skończę prace nad portalem to się tym zajmę.

vpiotr napisał(a):

Jeśli Java służy jedynie do konwertowania XML-a na JSON-a to po co ta Java?
Nie lepiej zastosować coś lekkiego? node.js lub PHP?

Java służy do security (Apache Shiro), obsługi maili, komunikacji z bazą danych, zapisywanie błędów do logu, uploadem plików i robieniem thumbnaili, prerenderem i wszystkim innym co tylko będzie potrzebne, albo o czym zapomniałem tu napisać.

Jasne, że można to ogarnąć w PHP i node.js. PHP nie chciałem, bo nie lubię. Javę znam, node nie :)

Co jeszcze wzbudza mają obawę: całość zostaje zaszyta do Oracle (komu będzie się chciało instalować Oracle, a wersje Express to porażka). A to droga baza. Poza tym tak naprawdę często zaczyna się projekt nie do końca wiedząc jaka baza będzie używana (wychodzi w praniu).

Jak ktoś chce używać Oracle i pisać w tym aplikacje to są do tego dedykowane narzędzia dla PL/SQL np. Oracle Forms, chyba że się myle?

@kkojot: tylko ogarnięcie logiki w aplikacji jest o wiele łatwiejsze niż w bazie danych ;)

To prawda, że ograniczyłem się tylko do bazy Oracle. Być może zamiast bazy można by użyć czegokolwiek, co zwróci określonego XMLa lub JSONa, ale to się mija z celem.
Oracle Forms to prehistoria, APEX też jest mocno ograniczoną technologią. Java jest lepsza :)

Tak jak pisałem wyżej, może nie tyle logika co operacje na danych po stronie bazy. I uważam, że w PL/SQL jest to dużo łatwiejsze, przyjemniejsze i wydajniejsze, szczególnie jeśli wchodzą w grę bardziej złożone przypadki. Ciekawi mnie opinia osób, które znają PL/SQL, a piszą w Javie :)

Obawiam się że będzie mało Javowców którzy byliby skłonni przenieść logikę z Javy na bazę.
No i jak wspomniano wyżej Oracle to jeden z droższych, jeśli nie najdroższy DBMS, do tego niełatwy w instalacji nawet z gotową i darmową VM-ką (jakieś >20GB), w związku z tym mało będzie ludzi chętnych do eksperymentowania z tym softem.
Ogólnie cel jest słuszny (krzewienie wiedzy o PL/SQL), ale

Tak jak pisałem wyżej, może nie tyle logika co operacje na danych po stronie bazy. I uważam, że w PL/SQL jest to dużo łatwiejsze, przyjemniejsze i wydajniejsze, szczególnie jeśli wchodzą w grę bardziej złożone przypadki. Ciekawi mnie opinia osób, które znają PL/SQL, a piszą w Javie

@kkojot: przybywasz do nas z roku 1990? Bo wtedy to sie moze takie aplikacje pisało z backendem w bazie danych... Pomagam teraz w utrzymaniu takiego projektu, który ma logikę zaszytą w bazie i nie polecam. Jak trzeba coś debugować to równie dobrze można od razu skoczyć z okna, a i tak nie jest źle, bo jest cała masa logowania z każdego miejsca, więc przynajmniej mamy "trace" co się wykonuje. I jeszcze ktoś postanowił zrobić to "generycznie", dzięki czemu niby nie trzeba modyfikować procedur kiedy dodajesz nowe parametry, ale efekt jest taki że trzeba wtedy zmodyfikować 10 tabel i kilka widoków zamiast tego :D

Trywialna logika w stylu "walidacja parametrów", którą w javie można by ogarnąć bardzo prostym kodem wymaga jakichś chorych operacji w pl/SQL. Jak dla mnie to jest tragedia i nie dziwi mnie że każdy się z tego wycofuje.

Też mamy system w Delphi z logiką db w procedurach....co w efekcie po 20 latach przyniosło, że cześć logiki jest w Delphi (webservice call, file call, image procesing, inne których nie da się robić w PL/SQL) a część w bazie. Debugowanie to porażka, wszędzie trigery wołające procedury, i procedury robiące zmiany w tabelach i znów trigery i tak w koło...niestety testów też brak, autorzy tłumaczą się ze nie ma JUnita w PL/SQL'u.....

Ogólnie w nowszych systemach logika w bazie tylko tam gdzie wymaga tego wydajność, mielimy ogromnie ilości danych

Nie popadajmy w skrajność, nigdzie nie piszę, że całą logikę zaszywam w bazie. Walidację robię również na poziomie Javy, bo jest łatwiej no i po co robić request do bazy.

Debugowanie PL/SQL krok po kroku jest możliwe, choć pisząc swój portal użyłem go co najwyżej kilka razy. Bo procedury są proste, sprowadzają się głównie do kilku selectów/insertów i ifów na jedną procedurę.

Triggerów używam tylko do klucza głównego z sekwencji. Każde inne zastosowanie rodzi więcej problemów niż korzyści.

Testy.. oczywiście, że kod w Javie mam oklepany JUnitem, ale operacje na bazie danych już nie. Nie zgłębiałem jeszcze tego tematu. Wy na wszelkie insert/updaty macie testy jednostkwe? Jak to wygląda?

Uważam, że jak mam insert do wielu tabel to dużo łatwiej jest wywołać jedną procedurę składowaną z wieloma parametrami, niż kilka zapytań sql z poziomu javy lub latanie po encjach, które zrobią to za mnie. Stąd napisałem takie rozwiązanie.

Na inserty nie ma testów jednostkowych, są testy integracyjne na endpointy
https://www.petrikainulainen.net/programming/spring-framework/integration-testing-of-spring-mvc-applications-controllers/

kkojot napisał(a):

Przykład. Chcemy zrobić insert z formularza do 5 tabel, w tym sprawdzić wartości w dwóch innych. Możemy biegać po encjach w javie, które w tle pewnie wykonają zapytanie żeby aktualizować swój stan, przez co nie jest to ani łatwe ani wydajne. Dużo lepiej jest przekazać dane w parametrach do procedury składowanej i załatwić

Tu leży pies pogrzebany. Jak pisze aplikację nigdy moim celem nie jest zrobienie inserta do bazy danych. Ani selecta ani, ani bieganie po encjach.
Przez to czasem nie mam żadnej bazy w projekcie.

Ale dużo programistów w ten SQLowy sposób myśli - wtedy takie frameworki im sie przydają.
Tyle, że uzyteczność frameworka to dokumenctacja, testy, przykłady, support. Raczej Springa nie przebijesz :-)

Poza tym generycznym frameworkom śmierć - jest 2017 do cholery.

Przy okazji pracowałem z dwoma dużymi systemami opartymi o procedury składowane - tragedia w utrzymaniu i performance.

@jarekr000000: Dzięki bardzo za odpowiedź. Trochę się rozjaśnia :)

Wiadomo, że Springa nie przebiję :D Właściwie walka o to żeby mój "framework" zaistniał na świecie mija się z celem, kupę roboty, brak korzyści finansowych. Zostawmy to. Powiedzmy, że mam produkt na własne potrzeby, bo piszę mi się w nim naprawdę świetnie :)

Ale ten SQLowy sposób myślenie jak to określiłeś to właśnie to. Skupmy się na aplikacji opartej o bazę danych, w moim przypadku Oracle. Skoro mam bazę, skoro znam SQL i PL/SQL, to czemu frameworki tak bardzo mi utrudniają korzystanie z tego?

Na początku budowałem ten portal w oparciu o RESTful API - na bazie ADFa, przyznaję, ale tylko model. Wyglądało to tak: mam tabelkę w bazie danych, tworzę encję w javie opartą na tej tabelce, dodaję widok oparty na tej encji, generuję RESTful API i koniec. Mam RESTa, który pozwala mi wykonywać wszelkie operacje CRUD na tej tabeli, bez napisania jakiekolwiek kodu, sqla, wszystko wyklikałem myszką w ciągu pół minuty. Naprawdę mi się to podoba. Działa dobrze.
Potem podczas developowania przyszedł czas na widok złożony z wielu encji + trochę pól agregujących. Żadnych indeksów w bazie, zapytanie wykonuje się 200 ms. REST - 500ms. Jeśli zapytanie SQL ograniczę do jednego rekordu (z rownum) to wykonuje się 30 ms. REST - 350ms, bo java pobiera wszystkie rekordy, dopiero potem limituje, zamiast zmienić where clause już w pierwszym zapytaniu.

Naprawdę nie wiem jak procedury składowane mogą ograniczać performance. PL/SQL jest kompilowany do C, a skoro dane siedzą w bazie to jak operacje na nich możemy wykonywać szybciej w javie?

Pewnie niedługo złapię Springa, spróbuję zrobić właśnie przytoczony przykład, czyli insert z jednego formularza do kilku tabel, będę miał porównanie z podejściem javowym oraz przez procedury składowane :) Bardzo mocny sprzeciw tutaj procedurom plsql mówi, że albo ja jestem w ogromnym błędzie, albo idea niezależności aplikacji od bazy danych sprawia, że developerzy nie dopuszczają do myśli innych rozwiązań.

@kkojot wyobraź sobie, że potrzebujesz przepchnąć jakiś dodatkowy parametr przez te swoje procedury. W Javie możesz dodać pole do klasy i voila. Nawet jeśli z jakiegoś powodu byłeś głupi i nie zrobiłeś klasy tylko przesyłałeś parametry "osobno" to masz dobre narzędzia jak IntelliJ które ogarną sytuacje i raz dwa pozmieniasz wszystkie sygnatury. Spróbuj taką samą operacje przeprowadzić z procedurami w bazie. Cały dzień będziesz tropił gdzie te funkcje którym zmieniasz sygnatury są wołane.

A twoje porównanie performance jest bez sensu. Nikt ci nie broni zrobić bardziej złożonego query w jakimś JPQL albo użyć jakiegoś JOOQ. Tylko ze realistycznie taka potrzeba zachodzi kiedy zrobiłeś wszystko bazo-centrycznie. W aplikacji która traktuje bazę jako persistent storage w ogóle nie ma takiego czegoś jak widok złożony z wielu encji + trochę pól agregujących bo to jest już część logiki aplikacji, a ta jest w backendzie. Baza tylko dostarcza dane.

Bardzo mocny sprzeciw tutaj procedurom plsql mówi, że albo ja jestem w ogromnym błędzie, albo idea niezależności aplikacji od bazy danych sprawia, że developerzy nie dopuszczają do myśli innych rozwiązań.

Zwyczajnie "to juz było" i okazało sie ze nie da się tego utrzymać. Jasne, jak masz swojego prostego CRUDa to wydaje się ok, ale jak urośnie to maintainability spada do 0.

@Shalom: rzeczywiście, w Javie jak tylko stwierdzę, że mam lepszą nazwę dla metody/klasy to ją zmieniam. Refactoringiem zajmuje się IDE, a skoro projekt się kompiluje i wszystkie unit testy przechodzą, to mogę spać spokojnie. Ten sam manewr w bazie danych? Pozostaje tylko kompilowanie wszystkich paczek PL/SQL i poprawianie na piechotę :D Tak mi się wydaje, bo nigdy z tym problemem się nie zetknąłem.

Nie bardzo rozumiem

W aplikacji która traktuje bazę jako persistent storage

jak to wygląda w przypadku aplikacji internetowej, ot takiego portalu jak podałem w pierwszym poście?

kkojot napisał(a):

@jarekr000000: Dzięki bardzo za odpowiedź. Trochę się rozjaśnia :)

Naprawdę nie wiem jak procedury składowane mogą ograniczać performance. PL/SQL jest kompilowany do C, a skoro dane siedzą w bazie to jak operacje na nich możemy wykonywać szybciej w javie?

Nawet jeśli masz tak głupi przypadek, że dane siedzą w bazie to nadal możesz całkiem inteligentnie stosowac róznego rodzaju cache i minimalizować prawie do 0 odwołania do tej bazy.
To nie jest tak, że procedur składwanych nie da sie zoptymalizować, bazy tez dużo cache używają, jednak w Javie (czy czymkolwiek) daje się to IMO w miarę łatwo / łopatologicznie kontrolować i można szybko uzyskać poprawę wydajności tam gdzie trzeba.

W przypadko procedur składowanych i rozproszonych baz danych widziałem, że ludzie, którzy w teorii się powinni na tym znać - kompletnie sobie nie radzili. (ale może byli kiepscy, wszyscy...).

jarekr000000 napisał(a):

Nawet jeśli masz tak głupi przypadek, że dane siedzą w bazie...

Chyba faktycznie żyję średniowieczem :) bez bazy nie wyobrażam sobie portalu internetowego.

... to nadal możesz całkiem inteligentnie stosowac róznego rodzaju cache i minimalizować prawie do 0 odwołania do tej bazy.

Jasne, że mogę. Mogę trzymać w pamięci, otworzyć sobie socket do bazy danych i aktualizować cache jak tylko dostanę informację z bazy, że wynik zapytania się zmienił. Do tego nie potrzebuję żadnego frameworka. Ale to już skrajne rozwiązania dla przypadków, gdzie liczba zapytań jest ogromna, a zmiany stosunkowo rzadkie.

No nic, w wolnym czasie spróbuję pyknąć prostą aplikacyjkę w Spring Boot z RESTful API, porównam sobie z moimi rozwiązaniami i może łatwiej będzie mi zrozumieć większość wypowiedzi w tym temacie.

bo java pobiera wszystkie rekordy, dopiero potem limituje, zamiast zmienić where clause już w pierwszym zapytaniu.

Nie no, nie żartuj. Nikt by wtedy Javy nie używał.