Frontend czy backend do generowania CSV?
Ostatnio stanęłam przed klasycznym dylematem: wygoda JavaScriptu kontra odpowiedzialność backendu w PHP - z dużymi plikami, strumieniowaniem, pamięcią i realnymi konsekwencjami dla użytkownika.
Jeśli interesują Cię techniczne decyzje, trade-offy i rozwój (nie tylko w kodzie), to zapraszam do lektury całego wpisu
#programowanie #naukaprogramowania #javascript #php #frontend #backend
Dziwna sprawa ale na chromie na komurze stronka się wywala. Na brave działa normalnie
@roadie dziękuję za info, faktycznie dziwne!
@roadie bo właśnie generuje CSV na backendzie i całe zasoby serwera się teraz tym zajmują
y no pythong
@eloyard rzyg.jpg
@NiebieskiSzpadelNihilizmu tak, dokładnie! To właśnie było moje doświadczenie z PHP ze starych czasów, kiedy okazało się, że trzeba coś zrobić z UTF-8 w wielu językach i alfabetach ( ͡~ ͜ʖ ͡°)
Oczywscie że backend. Koniec
@TheCommitLine Przeczytałem - brakuje rozważenia, czy komu na pliku bardziej zależy :D. Z zasady, jeśli da się coś offload na klienta, to lepiej, niż płacić za czas swojego serwera. Po to są workery, idleframe i tym podobne, by nie zjadało to wiele.
Można też bardziej nieszablonowo i chyba najszybciej - stored procedure w bazie i tylko download obsłużony z PHP.
Co do samego PHP - nie dotknę tego już nigdy, bo mam uraz, choć słyszałem, że to już nie jest jak strzelanie sobie w stopę. Do takiego tasku wybrałbym Rust lub Python.
@TheCommitLine Szczerze, fajne ale nie rób więcej. Poza oczywistymi oczywistościami nic innego nie wnosi.
@groman43 Wer kam?
@TheCommitLine
Na backendzie.
Wyjątkiem byłoby, jeżeli masz pewność, że zawsze danych będzie niewiele i masz je już pobrane na frontend.
Pewnie warto wziąć jeszcze pod uwagę jak w aplikacji już jest zrobione to w innych miejscach. Jak jest wszystko na frontendzie, to autora, który to zapoczątkował trzeba opierdolić, zrobić refactor i robić poprawnie na backendzie xd
@HmmJakiWybracNick taaaa... nie
No- a potem ten sam autor stwierdził, że "czas na rozszerzenie feature setu", ludzie potrzebują czasem szerszego zakresu danych i trzeba zrobić nowy endpoint w api, który robi swoiste "select * from tabela" i wpadł na pomysł, żeby udostępnić możliwość robienia większego dumpu danych z tej bazy. Bez. Żadnych. Ograniczeń. Jak większego? Ano minimum kilkaset mega "większego". W czystym tekście. Efekt? Użytkownik klikał na stronie odpowiedni guzik, przeglądarka zaczynała krzyczeć, komputer zaczynał krzyczeć, elektrownia zaczynała krzyczeć... i w końcu użytkownik zaczynał krzyczeć, bo wszystko przestawało działać i przeglądarka (a czasem i system) zaliczał spektakularną wypierdolkę z rowerka. Autor tego cudownego pomysłu nie mógł zrozumieć, że czemu to nie działało, skoro poprzednie rzeczy działały. Nie rozumiał również pojęcia przeniesienia tego na backend, żeby to nie było rozpierdolone wszędzie bez ładu i składu.
Jestem laikiem programowania, aczkolwiek swego czasu popełniłem kilka CMSów, apek (obługa AD) etc. I powiem tak: dla mnie złotym środkiem był AJAX, ale zawsze tam gdzie zachodziła potrzeba generowania czegokolwiek wolałem PHP. Mało tego, od samego początku system plików dla mnie nie istniał - zawsze jakaś DB.
A więc wyplułbym to po stronie "serwera" i pobrał do lokala
Tak w temacie – my akurat na swoim przykładzie wyszukiwarki RSSów w BIPach korzystamy z Go (po stronie backendu), jeżeli chodzi o generowanie plików CSV prezentujących zestawienie danych aktualnych na dany dzień. Sam w sobie takiego typu proces nie powinien za bardzo obciążać serwera.
Frontend jest tylko odpowiedzialny za „ładne opakowanie” przekazanych przez backend danych.
Musiałem
@30ohm still relatable
Oczywiście że frątęd. Jeszcze jakąś kopareczkę krypto klientowi odpalić, jakieś ciasteczka i robaki śledzące, reklamy kasyn online i scam linki. Wtedy backend sam się sfinansuje.
Chryste Panie, wyobraziłem sobie generowanie pliku na dużej ilości danych na froncie i chyba nie zasnę O.o Dobrze, że chociaż nie w CSS.
Zaloguj się aby komentować