Ciekawe czy jako początkujący web developerzy zastanawialiście się głębiej nad tym kiedy stosować skrypty po stronie klienta Client-Side Scripting a kiedy te wykonywane po stronie serwera Server-Side Scripting. Nie mam tutaj na myśli oczywistych przypadków, np. formatowanie oraz obsługę zdarzeń w przeglądarce powinniśmy wykonywać po stronie klienta. Mam na myśli przypadki, co do których moglibyśmy mieć pewne wątpliwości.
W tym krótkim wpisie wytłumaczę dlaczego jest to bardzo ważna sprawa z punktu widzenia optymalizacji i bezpieczeństwa witryn oraz aplikacji internetowych.
Technologie typu Client-Side
Najczęściej stosowanymi „dodatkami” do czystego HTML’a są skrypty działające po stronie klienta czyli JavaScript. Wsparcie dla tych technologii realizują przeglądarki internetowe. Fakt ten kreuje pewne zalety płynące ze stosowania tych technologii, które jednocześnie są wadami w szczególnych przypadkach.
Zaprogramowane przez nas funkcjonalności zależą od przeglądarki osoby korzystającej z naszej aplikacji. Różnice w interpretacji występują już nawet w różnych wersjach przeglądarki tej samej marki. Niektórzy zaś na przykład wyłączają obsługę JavaScript ze względów bezpieczeństwa. Od tej chwili każda linijka napisana w JavaScript jest dla naszego odbiorcy poza zasięgiem. Wada która mnie kiedyś trapiła to fakt, że JavaScript jest interpretowana w locie przez przeglądarki a nasz kod jest publicznie dostępny – i możliwy do skopiowania przez użytkowników.
Ogromną zaletą skryptów JavaScript jest ich szybkość działania. Opóźnienie związane z łączem internetowym nie ma nań żadnego wpływu. Jest to tak wielka zaleta, że równoważy wady które wcześniej wymieniłem i osobiście stosuję JavaScript kiedy się da.
Programowanie Server-Side
Skrypty PHP lub node.js są interpretowane przez serwer. Cała magia dzieje się po stronie serwera a klient dostaje gotowe dane. Jak można się domyślić to też ma swoje dobre i złe strony.
Wadą jest opóźnienie, które tutaj już jest mocno odczuwalne. Sam odstęp czasu pomiędzy zapytaniem a otrzymaniem odpowiedzi od serwera jest tak duży, że da się go odczuć nawet w bardzo prostych aplikacjach. Drugą wadą, która daje się we znaki web developerom jest fakt, że każde wykonanie skryptu obciąża jednostkę obliczeniową serwera. Już przy kilkudziesięciu użytkownikach, których użytkowanie aplikacji wymusza częste zapytania SQL lub operacje w systemie plików staje się dla nas problemem.
Jako zaletę można zaliczyć to, że kod PHP jest niewidoczny dla użytkownika. Wykonywane po stronie serwera instrukcje powodują identyczną funkcjonalność niezależnie od oprogramowania klienckiego. To niebywała zaleta pod kątem bezpieczeństwa naszego kodu. Nikt nie skopiuje sobie np. naszego programu, który tworzyliśmy przez parę nocy.
Czy jest coś pomiędzy?
Tak, zawsze jest coś pomiędzy. Najlepiej łączyć te technologie w każdy możliwy sposób. Wyobraźmy sobie aplikację, która pobiera dane od użytkownika dokonuje na nich obliczenia i wysyła gotowy wynik.
Prostą walidację wpisywanych danych wykonajmy po stronie klienta za pomocą HTML5. Sprawdzenie czy można je wykorzystać wykonajmy już po stronie serwera. Prześlijmy dane w obie strony za pomocą AJAX’a – bo przecież nie chcemy odświeżać strony. W czasie oczekiwania na wynik pokażmy animowany loader. Wynik obliczajmy za pomocą skryptu PHP a preferencje użytkownika zapisujmy po jego stronie w cookies albo za pomocą Local Storage.
Połączenie tych technologii jest czasem trudne ale w zamian otrzymamy bezpieczną aplikację, która krytyczne funkcje realizuje po stronie serwera, zapewnia poprawne wyświetlanie się po stronie klienta i jednocześnie działa szybko nie zdradzając użytkownikowi istotnych szczegółów mających wpływ na bezpieczeństwo.
Już wkrótce:
Wymiana danych PHP -> JavaScript
Wymiana danych JavaScript – PHP
Podsumowanie
Wbrew pozorom, jest wiele przypadków, w których można oprogramować daną funkcją stosując zarówno JavaScript jak i PHP. Aby podjąć trafną decyzję poznaj potrzeby swoich użytkowników, i dla każdego odpowiedz sobie na pytania: Czy szybkość działania tej aplikacji jest ważniejsza od ryzyka, że nie będzie on działała w starszych przeglądarkach? Czy grupa odbiorców aplikacji często aktualizuje swoje systemy? Czy zastosowane w programie funkcje i algorytmy mogą być przeglądane przez użytkowników? Odpowiedź na te pytania pozwoli wybrać złoty środek i stworzyć aplikację zarówno bezpieczną, funkcjonalną i wygodną w obsłudze.
