Autor Wątek: PHP+MySQL już w lamusie - co teraz?  (Przeczytany 19491 razy)

Offline bies

  • Użytkownik

  • +2
# Marzec 12, 2015, 00:44:38
Ponieważ właśnie piszę (tj. dokładnie w tej chwili) backend do aplikacji webowej to pozwolę sobie na kilka refleksji:

1. Co do C++ i chmury: nawet ciekawa perspektywa, C++14 (11 też) jest już tak wygodnym językiem, że właściwie backend nie powinien być problemem do efektywnego napisania. Ale wtedy cała chmura sprowadza się do skalowalnego zestawu wirtualek. Co, moim zdaniem, generuje za dużo roboty jak na prostą aplikację. Jak piszesz coś co ma działać maksymalnie wydajnie i skalować się na niewiadomo-ile-ale-bardzo-dużo klientów to może (lighttpd + fastcgi + jakoś sensownie rozwiązany load balancing).

2. Co do wyboru języka: osobiście JVM w postaci Xtend. Język prawie tak wygodny jak C++ czy Python ale kompilowany do Javy z natywnym dostępem do wszystkich bibliotek Javy. No i chyba wszyscy providerzy chmur wspierają Javę.

3. Co do generowania HTML: nie! Nie w backendzie. Backend zwraca tylko JSON-a i udostępnia REST-owe API. Jeśli założymy podział aplikacji w ten sposób nagle okazuje się, że testowanie backendu jest proste jak skrypt z wgetem i curlem. Oraz, że frontend można spokojnie pisać i testować równolegle używając statycznych plików JSON. A w czym frontend? JS lub coś co kompiluje się do JS (CoffeeScript). Można (trzeba) oczywiście używać czegoś do sensownego pisania aplikacji w JS (Angular?).

Inną zaletą tego podejścia jest to, że jeśli za moc obliczeniową backendu płacimy to dlaczego nie zrzucić niewdzięcznego generowania html na maszyny klienta? Ta moc obliczeniowa jest praktycznie za darmo. Z ciekawostek można spokojnie generować np. PDF-y po stronie JS.

4. Co do ORM-ów i ogólnie warstwy dostępu do bazy: tutaj chyba największa "herezja". Na drzewo! Żadnych "warstw dostępu" poza najprostszym interfejsem (w przypadku JVM mam na myśli JDBC). Dlaczego: "insert into a select 'XXX', a, b, c from b inner join c on (...)" -- to zapytanie przekopiuje zestaw danych pomiędzy złączeniem dwóch tabel a trzecią z tabel. Zrobi to po stronie bazy bez angażowania kodu aplikacyjnego. I zrobi to szybko. Odpowiednik w jakimś ORM-ie będzie się wlekł (znów, płacimy za czas procesora). Podobnie każde bardziej złożone raportowanie łatwiej napisać w postaci skomplikowanego selecta niż masy obiektów zwracanych przez ORM-a.

Oczywiście wszystkie te drobne przyjemności jak PreparedSteatement należy sobie zaserwować -- nikt nie będzie się bawił w ręczne escape'owanie.
« Ostatnia zmiana: Marzec 12, 2015, 00:46:17 wysłana przez bies »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline koirat

  • Użytkownik

# Marzec 12, 2015, 01:58:34
Chciałem walnąć wielkiego posta sławiącego ASP MVC napisze jednak tylko tyle "wszystko co powyżej a nawet więcej" ;).

Co do ORM, zawsze można użyć ORM-a do modyfikacji/dodawanie/usuwanie rekordów, a czystego SQL do czytania z bazy danych. Osobiście pierwsze moje zetknięcie z ORM było dość pozytywne. W ten czas był to NHibernate. Teraz chyba już sięgnął bym po Entity Framework.

Offline ArekBal

  • Użytkownik

  • +1
# Marzec 12, 2015, 05:35:13
“Xtend could be described as “Scala, the good parts“.” (Meinte Boersma)
Toż to jakiś żart.

Trzeba przyznać że lista language features jest porażająca... ale momentami składnia tego xtend to niezły odlot... czasami na siłę daleko od sprawdzonych wzorców.
val toUpperCaseFunction = [ String s | s.toUpperCase ] // inferred type is (String)=>String

No i trochę brak pomocniczych mechanizmów do opakowania wielobieżności(w końcu to Java "godamit").

Ale i tak mam do poczytania kilka wieczorków.

Cytuj
3. Co do generowania HTML: nie! Nie w backendzie. Backend zwraca tylko JSON-a i udostępnia REST-owe API.
a) Snapshoty do SEO i tak musisz czymś generować.
b) Jeśli zwracasz same templatey/partiale i dane osobno to masz opóźnienie o kilka roundtripów na wejściu.
Poza tym, jak już masz jakiś język templateów po stronie serwera to masz kilka zalet:
- możesz np. wstawiać małe obrazki jako base64(przed css i przed js w jednym roundtripie),
- lepsze, elastyczniejsze zarządzanie ścieżkami(abstrakcja na) do static i partialami,
- możesz całe partiale generować i podmieniać - szybkie i tanie dla konkretnych przypadków.

 I żadne tam generowanie html ci serwera nie zajedzie bo używasz cache zazwyczaj.

Ad 4. To ty jakieś herezje głosisz... Nie jestem zwolennikiem mnożenia warstw. Ale pisanie dzikich sql w jakimkolwiek projekcie powyżej 200 roboczogodzin to szaleństwo. Bez mierzenia możesz na drzewo się z tą wydajnością schować. O braku podstawowych "featurów" nie wspominając:
- powodzenia w "bezpiecznym" parametryzowaniu kilkupoziomowych zapytań(filtry, grupowanie, sortowanie, stronicowanie, wybieranie kolumn)...
- batchowanie
- wiele zapytań/rezultatów w jednym roundtripie
- transakcje
- ZARZĄDZANIE KODEM
- no i weź napisz chociaż na tyle dobrego sqla co ORM...

raporty w SQL... hmm...

Takim wariantem po środku(po który można sięgnąć gdy ORM zawodzi(znamy sztuczkę której on niezna)) jest wywołanie zapytania na dziko poprzez ORM. (jakieś ExecuteSqlQuery z generycznym rezultatem)
« Ostatnia zmiana: Marzec 12, 2015, 06:20:27 wysłana przez ArekBal »

Offline Xion

  • Moderator
    • xion.log

  • +2
# Marzec 12, 2015, 09:45:30
Cytuj
C++14 (11 też) jest już tak wygodnym językiem, że właściwie backend nie powinien być problemem do efektywnego napisania
Ekosystem C++ jest wciąż o wiele gorszy niż innych języków (zarządzanie paczkami? jakimi paczkami? :-)). Podejrzewam też, że większość bibliotek z których trzeba by korzystać (sterowników do RDMBS, Redisów, memcache'y, kolejek AMQP, itp. itd.) nijak ma się do fajnych ficzerów z C++, bo zostały napisane w C ze względów historycznych bądź przenośności, i nikt nie napisał do nich wrapperów w C++.

Cytuj
Ale wtedy cała chmura sprowadza się do skalowalnego zestawu wirtualek. Co, moim zdaniem, generuje za dużo roboty jak na prostą aplikację.
Nie tyle wirtualek, co linuksowych kontenerów. Co zresztą stosuje się już z powodzeniem do "śmiesznych" języków, które typowo są wykorzystywane w webdevie.

Cytuj
2. Co do wyboru języka: osobiście JVM w postaci Xtend. Język prawie tak wygodny jak C++ czy Python ale kompilowany do Javy z natywnym dostępem do wszystkich bibliotek Javy. No i chyba wszyscy providerzy chmur wspierają Javę.
Ogólnie języki działające na JVM to dobry wybór. Xtend, Scala, Kotlin, Clojure, co kto lubi.

Cytuj
3. Co do generowania HTML: nie! (...)
Ten punkt dość dobrze zbalansował ArekBal. To niezupełnie prawda, że single page apps > wszystko inne. Backend wystawiający samo API jest fajny, jeśli projekt jest tego warty, np. ma więcej niż jednego klienta -- typowo web frontend + natywne apki mobilne.
Testowanie to też kiepski argument, bo wspomniane 'testy wgetem/curlem' mają wartość ~unittestów odpowiednich fragmentów "tradycyjnego" backendu, i wciąż nie zwalniają z konieczności posiadania testów integracyjnych (frontend + backend łącznie).
Wreszcie, przerzucanie roboty do klienta jest OK do momentu gdy userzy zaczną ci narzekać, że otwarcie twojej strony potraja im zużycie baterii w telefonie :)

Kwestię ORM vs. SQL pozwolę sobie pominąć, bo przedmówcy rozprawili się z nią w miarę dobrze. Od siebie polecę dokładne przyjrzenie się SQLAlchemy, żeby skorygować złudzenie, że dzisiejsze ORM-y to nic innego jak kiepska nakładka na `SELECT * FROM foo`.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 12, 2015, 14:13:12
OK, fajnie że sprzedajecie tutaj różne armaty.


Teraz dla odmiany prosiłbym o zasugerowanie czegoś odpowiedniego na komary. ;)

Przykładowo: chcę napisać prywatną webową appkę która ma być listą ToDo - dodaj wpis, edytuj wpis, usuń wpis, zaznacz zrobione/niezrobione i NIC więcej (appka nie będzie dalej rozwijana). Za to co ważne - chcę żeby to było bezpieczne i zrobione SZYBKO i PROSTO. Czekam na sugestie. :)

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

# Marzec 12, 2015, 14:29:43
Załóż sobie konto na githubie i używaj issues :D

Zrobione niezrobione -> zamykasz issue albo dodajesz odpowiednią etykietę.
Usuwać raczej nie można, ale też możesz zamknąć i dodać etykietę, że nie trzeba było nic robić.

Dodatkowo możesz prowadzić wersjonowanie swojego projektu i odwoływać się do wpisanych issues.
« Ostatnia zmiana: Marzec 12, 2015, 14:34:10 wysłana przez JasonVoorhees »

Offline 10log

  • Użytkownik

# Marzec 12, 2015, 14:35:29
To może użyj jakiegoś prostego bugtrackera np. https://www.mantisbt.org/

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 12, 2015, 15:26:30
Cytuj
Załóż sobie konto na githubie i używaj issues :D
Po pierwsze - kolejna armata na komara.
Po drugie - raz próbowałem założyć konto i mi się nie udało - odpuściłem.

Po trzecie - last, but not least - to jest przykład poziomu złożoności. Chodzi mi o sugestię prostego sposobu robienia takich rzeczy, a nie używania gotowców.


Cytuj
To może użyj jakiegoś prostego bugtrackera np. https://www.mantisbt.org/
Jak właśnie napisałem - to jest przykład poziomu złożoności rzeczy, które chciałbym ogarniać. Ale konkretnie zawsze przecież będzie to bugtracker. Ot, chociażby moja stronka jest wcale niewiele bardziej złożona (to też tylko przykład - nie podrzucajcie mi CMSów teraz).

A proste rzeczy powinno się robić prosto - stąd pytanie.

Offline Dab

  • Redaktor
    • blog

  • +1
# Marzec 12, 2015, 15:35:14
Cytuj
Przykładowo: chcę napisać prywatną webową appkę która ma być listą ToDo - dodaj wpis, edytuj wpis, usuń wpis, zaznacz zrobione/niezrobione i NIC więcej (appka nie będzie dalej rozwijana). Za to co ważne - chcę żeby to było bezpieczne i zrobione SZYBKO i PROSTO. Czekam na sugestie. :)

rails new TodoList
cd TodoList
rails generate scaffold Entry title:string done:boolean
rake db:migrate
rails server

i gotowe. Pod http://localhost:3000/entries masz aplikację z jednym modelem + widoki do przeglądania i zarządzania danymi + REST API do tego. Co może być prostsze? :)


Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 12, 2015, 15:41:33
Cytuj
i gotowe.
Pytałem jak zrobić. Nie jak zainstalować gotowca z command line. ;)

Offline 10log

  • Użytkownik

# Marzec 12, 2015, 15:48:01
No to wracamy do początku :). Może PHP+MySQL+jakiś framework.
Z tego co opisałeś powinno się zamknąć w jednym kontrolerze z kilkoma widokami + parę zapytań do bazy.
Nawet systemu szablonów nie opłaca się zaprzęgać do pracy.
Co do bazy danych i różnych ORMów to chyba najprostrzy w użyciu jest http://redbeanphp.com/.
Jeden require i działa.

Offline maro

  • Użytkownik

# Marzec 12, 2015, 16:08:35
Utwórz tabelę w mysql z odpowiednimi polami, wrzuć Adminera, i masz prosto, szybko, webowo i bezpiecznie. ;)

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

# Marzec 12, 2015, 17:16:01
@up: Chyba Krzysiek ma wenę by zrobić coś własnego, dlatego się upiera :D

Po pierwsze - kolejna armata na komara.
I bardzo dobrze. Nie będę używał notatnika do pisania programów tylko dlatego, że się da. Armaty (np. Eclipse, Geany) mają szereg opcji, które umilają proces powstawania aplikacji ;) Ty wiesz, że przy pisaniu aplikacji, poradzisz sobie nawet w PHP z SQLite'm, albo zrobisz bazę na zwykłych plikach tekstowych (mój kolega tak robił, bo nie mógł się przekonać do używania baz danych :D ).

Po drugie - raz próbowałem założyć konto i mi się nie udało - odpuściłem.
Jaja sobie robisz? Co mogło pójść nie tak? Hmmm, u mnie działa :P

Po trzecie - last, but not least - to jest przykład poziomu złożoności. Chodzi mi o sugestię prostego sposobu robienia takich rzeczy, a nie używania gotowców.
Spoko, myślałem, że chodzi Ci o to, żeby mieć taką aplikację, jakoś u siebie postawioną i chcesz to zrobić jak najłatwiej...
« Ostatnia zmiana: Marzec 12, 2015, 17:24:58 wysłana przez JasonVoorhees »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 12, 2015, 17:26:16
Cytuj
Chyba Krzysiek ma wenę by zrobić coś własnego, dlatego się upiera :D
Wenę żeby czegoś się nauczyć nowego - a ściąganie i instalowanie gotowców mam już opanowane. ;)

Cytuj
Jaja sobie robisz? Co mogło pójść nie tak?
Standardowy problem dużych portali.

Cytuj
Spoko, myślałem, że chodzi Ci o to, żeby mieć taką aplikację, jakoś u siebie postawioną i chcesz to zrobić jak najłatwiej...
Jakby nie chodziło o naukę, to bym inaczej do tematu podchodził. :) Samego bug/whatever trackera też mam kiedyś zamiar tam napisać, ale to z uwagi na bardzo nietypowy zestaw wymagań (tak, przeglądałem już tony gotowców - tą drogą nie idzie). Więc przy okazji przyszła mi myśl, że od surowego PHP jakieś nowsze, a przy tym proste rozwiązania już mogą w dzisiejszych czasach być.

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

# Marzec 12, 2015, 17:33:39
od surowego PHP jakieś nowsze, a przy tym proste rozwiązania już mogą w dzisiejszych czasach być.
Te "prostsze rozwiązania w dzisiejszych czasach" opierają się na biznesie. Łatwiej pracować ze zespole i panować nad dużą aplikacją, mając wyznaczone standardy kodowania (jak w Django). Jeśli chcesz zrobić coś szybko, bez uczenia się nowych technik, bez potrzeby maintainowania tego w przyszłości, to surowy PHP rzeczywiście będzie dla Ciebie najlepszym wyborem. Inne proste, współczesne rozwiązanie to skorzystanie z jakiegoś CMS (Joomla, Wordpress) i jego dodatków

Jeśli nie chcesz surowego PHP, to podobno Kohana jest lekkim frameworkiem. Ale też trzeba się czegoś nauczyć, pewnej ścieżki tworzenia aplikacji, by jej używać ;) Możesz też iść w inne frameworki. No, w takim kierunku poszła technika. Albo masz coś z automatu, albo półautomatu, albo klepiesz samemu.
« Ostatnia zmiana: Marzec 12, 2015, 17:36:32 wysłana przez JasonVoorhees »