Połączenie się z bazą danych z poziomu javascript Opcje

[batman]

Natrafiłem na taki artykuł http://www.alphaworks.ibm.com/tech/dbcjs. W telegraficznym skrócie chodzi o to, że aplikacja kliencka (napisana w javascript) może bezpośrednio połączyć się z bazą danych na serwerze. Innymi słowy - taki ajax, tylko że na nowo. Co o tym sądzicie?

[webdice]

Może dla programistów JavaScript jest to jakieś ułatwienie. Rzuciłem tylko okiem na to i domyślam się ze wszelkie zapytania będą w JS (oczywiście połączenie z bazą w PHP) i czy takie coś będzie bezpieczne? Nie. Po co ktoś ma widzieć z jakiej tabeli pobieram dane? Po co ktoś ma wiedzieć jakie mam kolumny w tabeli? Jak dla mnie bezsensowna praca, bo to się nie przyjmie.

[LBO]

Wszelkie interakcje z bazą powinny być transparentne dla end-usera, moim zdaniem chybiony pomysł.

[batman]

Dla mnie jest to idealne rozwiązanie. Mam wątpliwości odnośnie bezpieczeństwa, jednak możliwości takiego rozwiązania są ogromne. Przy wykorzystaniu jakiejś biblioteki javascript (jquery, prototype.js, itp) oraz ODC-JS będzie można tworzyć aplikacje praktycznie niezalężne od serwera. Klient raz wpisuje adres, a całą resztą zajmuje się javascript.

[sztosz]

Ale korzystając pośrednio z serwera aplikacji (PHP, Tomcat etc...), czyli cały ten AJAX, to też raz się wpisuje adres a resztą zajmuje się JS. Ale mamy większe bezpieczeństwo, nieprzeładowane strony milionem linii kodu w JS (choć korzystając z "AJAX" i tak tego JS jest sporo), nikt nie patrzy jaki burdel mamy w naszym kodzie na serwerze mamy prosty dostęp do statystyk etc. A hosting i tak trzeba mieć do hostowania bazy danych, więc to "praktycznie niezalężne od serwera" to jakaś mrzonka

[grzesiek_g]

Jednym słowem - jedno z głupszych rozwiązań, kolejne proponuję stworzyć możliwość przeglądania zasobów komputera klienckiego z poziomu javascript.

[batman]

Ciekawe czy w ogóle przeczytaliście ten dokument. Jedno ze zdań odnośnie bezpieczeństwa:

Clients can be prevented from even seeing the sql statement with an indi-
rection technique in which clients use “named SQL” statements. The client
provides the name of the SQL statement, and the server maps the name onto
the actual SQL. This allows the server to withhold information about the
database design from the clients.

Cała komunikacja odbywa się przy pomocy XML poprzez bezpieczne połączenie SSL.

Odnośnie niezależności od serwera. Chodziło mi o to, że tworzeniem strony zajmie się JS a nie PHP, ASP, Ruby (itd.). Całe obciążenie zostaje przeniesione na maszynę klienta. A że nie jest to aż tak duże obciążenie, można przyjąć, że większość komputerów poradzi sobie z tym zadaniem. Inną zaletą takiego rozwiązania jest to, że będzie można zapisać stronę na dysku, uruchomić i nadal się cieszyć tym, że mamy aktualne dane. Daje to bardzo duże możliwości w tworzeniu aplikacji, również pseudo-desktopowych, obsługiwanych z poziomu przeglądarki.

[sztosz]

Zgodzę się z tobą że może to znaleźć zastosowanie w aplikacjach pisanych dla konkretnych departamentów jakiejś sporej firmy, np sprawdzanie czy też wklepywanie umów takie plusa, albo obróbka listów przewozowych w firmir kurierskiej.

Pytanie: Po co? JS nie jest ani super wydajny ani super prosty, ani super rozbudowany. To samo można napisać w innych językach i do tego nie trzeba będzie odpalać przeglądarki żeby ta się z JS babrała.

[batman]

JS sam w sobie nie jest prosty, jednak, przy zastosowaniu odpowiedniej biblioteki, można zrobić praktycznie wszystko. Rozwiązanie to jest na tyle ciekawe, że będzie dawało możliwość tworzenia aplikacji www, które będą niezależne od języka po stronie serwera. Wystarczy napisać sam HTML i JS, który będzie wykonywał większość czynności, które teraz trzeba robić po stronie serwera. Nie twierdzę, że jest to alternatywa do języków skryptowych działających po stronie serwera, lecz uzupełnienie, które pozwoli na jeszcze większą interakcję z użytkownikiem.

[mike]

Beznadziejny pomysł.

Całe obciążenie zostaje przeniesione na maszynę klienta. A że nie jest to aż tak duże obciążenie, można przyjąć, że większość komputerów poradzi sobie z tym zadaniem.

Odpal GMaila na godzinę w FF to będziesz miał przedsmak tego co określasz małym obciążeniem.

Piszesz w kółko że to uniezależni aplikację od języka server-side. Ale powiedz najpierw co rozumiesz pod pojęciem "zależna". Przecież to, że stronę generuje dany język to nie jest żadna zależność. Możesz go podmienić.

Kolejna sprawa, co daje przeniesienie ciężaru na klienta? Poza jego niezadowoleniem że przeglądarka działa wolniej. nic to nie daje.
No w sumie daje, mniej pracy programisty po stronie serwera.

No i ta "możliwość większej interakcji". Co to znaczy? Dla mnie pusty slogan.

Ogólnie pomysł to jakaś dziwna ciekawostka, w mojej opinii nie mająca przyszłości.

I na sam koniec:

The server-side IBM Database Connectivity for JavaScript gateway is executed in a PHP container. The XML messages are translated into corresponding PDO method invocations and the method results are sent back to the client as XML messages. The client-side library interprets the message and returns the result to the user.

To jak? Uniezależniłeś sie od PHP?

[batman]

Odpal GMaila na godzinę w FF to będziesz miał przedsmak tego co określasz małym obciążeniem.

Kolejna sprawa, co daje przeniesienie ciężaru na klienta? Poza jego niezadowoleniem że przeglądarka działa wolniej. nic to nie daje.

Przy obecnych możliwościach obliczeniowych maszyn klienckich nie będzie to problemem. Sam pomysł jest jak na razie w fazie alfa, więc nim ujrzy światło dzienne, komputery zwiększą swoją moc.

No i ta "możliwość większej interakcji". Co to znaczy? Dla mnie pusty slogan.

Znaczy to między innymi tyle, że nie będziesz potrzebował wchodzić na daną stronę za każdym razem, gdy będziesz potrzebował jakichś informacji. Uruchomisz zapisaną na dysku stronę, a resztą zajmie się JS.

To jak? Uniezależniłeś sie od PHP?

Nie pisałem, że dzięki temu uniezależnię się całkowicie od PHP. Jednak dzięki takiemu rozwiązaniu, po stronie serwera będzie działał jeden skrypt, a nie kilkanaście/kilkadziesiąt, do obsługi ajaxa.
Moim zdaniem rozwiązanie to zasługuje na uwagę tak samo jak ajax, któremu na początku nikt nie wróżył przyszłości.

[webdice]

Znaczy to między innymi tyle, że nie będziesz potrzebował wchodzić na daną stronę za każdym razem, gdy będziesz potrzebował jakichś informacji. Uruchomisz zapisaną na dysku stronę, a resztą zajmie się JS.

No ok, ale przecież AJAX łączy się tylko z localhostem, więc jak będą pobierane dane z innych serwerów?

[batman]

No ok, ale przecież AJAX łączy się tylko z localhostem, więc jak będą pobierane dane z innych serwerów?

Jeśli przeczytałbyś to, co zmieszczone jest na stronie, wiedziałbyś jak to działa. JS łączy się nie ze skryptem, który ajaxem pobiera dane, lecz z bazą danych (poprzez brankę napisaną w PHP lub JAVIE). Samą prezentacją danych zajmuje się JS.

Przypomnę, że pomysł jest w fazie alfa, więc sporo może się zmienić.

[sztosz]

Znaczy to między innymi tyle, że nie będziesz potrzebował wchodzić na daną stronę za każdym razem, gdy będziesz potrzebował jakichś informacji.

Ale i tak będziesz musiał mieć połączenie z internetem/intranetem, więc co za różnica dla klienta czy będzie miał stronę zapisaną na dysku, czy ściągnie przez sieć?

Poza tym nie od dziś wiadomo, że najwydajniejszą formą (także cost effective) aplikacji sieciowej/firmowej/corporacyjnej jest mainfreme+terminale. A ty oddalasz się bardzo od tego modelu.

[batman]

Ale i tak będziesz musiał mieć połączenie z internetem/intranetem, więc co za różnica dla klienta czy będzie miał stronę zapisaną na dysku, czy ściągnie przez sieć?

Rożnica jest taka, że nie zawsze na jednym serwerze znajduje się i aplikacja i baza danych. Jak padnie serwer z aplikacją, cały czas masz połączenie z bazą.

Poza tym nie od dziś wiadomo, że najwydajniejszą formą (także cost effective) aplikacji sieciowej/firmowej/corporacyjnej jest mainfreme+terminale. A ty oddalasz się bardzo od tego modelu.

Najlepszym przykładem jest tutaj nasza klasa

Poza tym coraz częściej się mówi o przeniesieniu dysku twardego do sieci i pracy na aplikacjach sieciowych (np. google docs), więc to rozwiązanie ma szansę na rozwój.

[mike]

Rożnica jest taka, że nie zawsze na jednym serwerze znajduje się i aplikacja i baza danych. Jak padnie serwer z aplikacją, cały czas masz połączenie z bazą.

Jeśli padnie serwer to padnie też Twoja bramka, notabene będąca odpowiednikiem aplikacji. Gdzie jest różnica. Ja nie widzę sensownej.

Zamieniasz aplikację, generującą prezentację lekką dla klienta (wygodniejszą dla klienta) na bramkę która dostarcza dane a całość mieli JS, ciężki dla klienta.
Co zyskujesz? Nic poza frustracją klienta.

No chyba że może chodzi o łącze i transfer?

[batman]

Jeśli padnie serwer to padnie też Twoja bramka, notabene będąca odpowiednikiem aplikacji. Gdzie jest różnica. Ja nie widzę sensownej.

Różnica jest taka, że bramka będzie znajdować się na serwerze bazodanowym, a nie na serwerze aplikacji.

Zamieniasz aplikację, generującą prezentację lekką dla klienta (wygodniejszą dla klienta) na bramkę która dostarcza dane a całość mieli JS, ciężki dla klienta.
Co zyskujesz? Nic poza frustracją klienta.

Przecież nie będzie wyciągane kilka tysięcy wierszy, a jedynie określona ich ilość. Nie powiesz mi, że tworząc stronę, na której znajduje się jakaś tabela z danymi, wyciągasz wszystko z bazy, a dopiero potem ograniczasz ilość wierszy, stosujesz sortowanie, itd?

[sztosz]

Poza tym coraz częściej się mówi o przeniesieniu dysku twardego do sieci i pracy na aplikacjach sieciowych (np. google docs), więc to rozwiązanie ma szansę na rozwój.

Ale to jest właśnie architektura mainframe + terminale. Przeglądarka jest tym terminalem. Aplikacja jest, na przykładzie google, po stronie serwera, natomiast klient dostaje tylko to co musi zobaczyć + mechanizmy interakcji. Na stronach na których nie jest to potrzebne, choć zupełnie nie mam pojęcia gdzie widzisz zastosowanie dla rozwiązań o których mówisz, nie ma sensu pakować tonę niewydajnego JS klientowi.

Nie mam nic przeciwko temu żeby projekt się rozwijał, nigdy rozwojowi nie będę przeciwny. Ale na razie nie ma dla mnie żadnego uzasadnienia stosowania takiej architektury w środowisku "produkcyjnym".

Ten post edytował sztosz 28.01.2008, 11:48:02

[batman]

Nie mam nic przeciwko temu żeby projekt się rozwijał, nigdy rozwojowi nie będę przeciwny. Ale na razie nie ma dla mnie żadnego uzasadnienia stosowania takiej architektury w środowisku "produkcyjnym".

Tak samo mówiono o ajax-ie. A dzięki niemu sieć przeszła marketingową rewolucję pod nazwą "łep 2.0".
Nie zrozumcie mnie źle, ale należy zachować otwarte umysły na nowe rozwiązania i szukać sposobów ich zastosowania.

[sztosz]

Wydaje mi się że źle do tego podchodzisz. Nie należy na silę szukać pola dla zastosowania konkretnej technologii, ale dla konkretnego "problemu" znaleźć odpowiednią technologię.

Dlatego nie należy na siłę wdrażać technologii o której piszesz w przypadku gdy jej użycie jest wysoce dyskusyjne. Chciałbyś na hop-siup zrewolucjonizować sieć, a nie tędy droga. Dla mnie coś takiego ma sens, gdy np. wyświetlasz ogromne ilości danych tabelarycznych, gdzie tak naprawdę wystarczyłby ci konsolowy klient bazy *sql, ale żeby wyglądało to przejrzyściej. Ale takie przykładowe forum php.pl napisane w JS+*SQL to była by wydajnościowa porażka.