Czego używa się do serwowania małego projektu front-end lokalnie?
Czyli np. mam projekt i muszę go pokazać innej osobie, tak, żeby ona go sobie mogła odpalić i nie mieć problemu z źródłami?
Webpack to przesada w takim wypadku?
Czego używa się do serwowania małego projektu front-end lokalnie?
Czyli np. mam projekt i muszę go pokazać innej osobie, tak, żeby ona go sobie mogła odpalić i nie mieć problemu z źródłami?
Webpack to przesada w takim wypadku?
Dla "małego projektu front-end" lokalnie wystarczy pendrive i dowolna przglądarka.
4w0rX4t4X napisał(a):
Dla "małego projektu front-end" lokalnie wystarczy pendrive i dowolna przglądarka.
jak z samą przeglądarką i masz chociażby jeden zewnętrzny plik, to CORSy wchodzę w grę chyba nie?
drugie najlepsze rozwiązanie?
Dałem Ci odpowiedź adekwatną do zadanego pytania. Gdybyć napisał cokolwiek więcej to mozliwe byłoby napisać coś więcej. Teraz to nawet nie wiadomo czy ten front end to aplikacji Webowej czy może interfejs gry na Amigę.
front-end do aplikacij Webowej. składa się z Tailwinda i jednej zewnętrznej biblioteki którą obecnie importuje przez CDNa, jednego mojego pliku .js i jednego pliku HTML
Zwykle do takich rzeczy wklepuję python -m http.server
Skoro to jest apka webowa to po prostu skopiuj źródła i wrzuć za darmo na github pages.
Tak jak mówi Riddle. Ewentualnie jak to sam frontend to możesz hostnac np. na Netlify za frajerinho.
@B.Eng: Jak lokalnie to spakuj source'y, napisz Dockerfile i po sprawie.
Eldorad O. napisał(a):
@B.Eng: Jak lokalnie to spakuj source'y, napisz Dockerfile i po sprawie.
właśnie nie chciałem się Dockera bawić. Nie mogę założyć, że osoba do które to idzie (klient) ma Dockera, albo chce się w niego bawić.
myślałem o Webpacku, albo Browsersync.
chciałem jakoś w miarę profesjonalnie to zrobić w sensie, wiadomo, że Browsersync zadziała albo Webpack, ale chciałem w miarę możliwości iść konwencjami, myslałem, że jest może jakiś utarty sposób w jaki takie rzeczy się zazwyczaj robi. Webpack do takiego małego projektu trochę overkill mi się wydał
Riddle napisał(a):
Skoro to jest apka webowa to po prostu skopiuj źródła i wrzuć za darmo na github pages.
klient chce mieć możliwość odpalenia lokalnie
B.Eng napisał(a):
Riddle napisał(a):
Skoro to jest apka webowa to po prostu skopiuj źródła i wrzuć za darmo na github pages.
klient chce mieć możliwość odpalenia lokalnie
Github Pages opiera się na Jekyllu i tez można uruchomić to lokalnie
https://jekyllrb.com/
Sorki za tamten post, nie ogarnąłem. Zakładamy że "klient" jest nietechniczny i potrzebuje to odpalić u siebie na komputerze PC/Mac? Bo w takim przypadku, to chyba zostaje jakieś .exe z electronem (albo odpowiednik .exe na Mac/Lin).
B.Eng napisał(a):
jak z samą przeglądarką i masz chociażby jeden zewnętrzny plik, to CORSy wchodzę w grę chyba nie?
B.Eng napisał(a):
front-end do aplikacij Webowej. składa się z Tailwinda i jednej zewnętrznej biblioteki którą obecnie importuje przez CDNa, jednego mojego pliku .js i jednego pliku HTML
no to normalnie możesz odpalić z pendrive'a, cssy i js możesz ładować z zewnętrznych źródeł przecież.
Chodzi ci zapewne o same origin policy, CORS to mechanizm luzowania zabezpieczeń ale nie jest potrzebny do wykonywania, wyświetlania i wysyłania treści z/na zewnętrzne źródła. Zabroniony jest jedynie odczyt danych
B.Eng napisał(a):
jak z samą przeglądarką i masz chociażby jeden zewnętrzny plik, to CORSy wchodzę w grę chyba nie?
CORS nie zależy od przegldarki tylko od serwera jakie Access-Control-Allow-Origin: *
jeśli gwiazdka to każdy może mieć dostęp, jak nie to tylko podane adresy URL.
I to uniemożliwia ze złośliwej strony wysyłanie fetch do serwera, gdzie np. http only cookie czy inne dane może przeglądarka automatycznie dołączyć.
Przeglądarka wysyła preflight request, który zwraca ten header i jeśli nie ma zezwolenia to blokuje możliwość komunikacji skryptom w javascript.
Drugie to formularzem post można trochę oszukać i ominąć to więc i csrf token dobrze mieć zaimplementowany, bo post formularz pozwala wysłać nawet jak CORS jest ustawiony.
Aplikacje poza przeglądarką to w ogóle gdzieś mają te headery i nie respektują tego co tam jest więc tam nic ich nie blokuje, chyba że ktoś taki feature zaimplementuje.
B.Eng napisał(a):
właśnie nie chciałem się Dockera bawić. Nie mogę założyć, że osoba do które to idzie (klient) ma Dockera, albo chce się w niego bawić.
myślałem o Webpacku, albo Browsersync.
Jak bardzo techniczny jest klient?
Bo zakładam, że to jest ktoś, kto coś programuje i umie zrobić npm install (i upewnić się, że ma Node.js zainstalowany)? Podobnie z Pythonem. To jest banalne, jak się wie, co to jest konsola i umie się wejść na katalogu i odpalić http.server, ale jeśli to ktoś totalnie nietechniczny, to i tego nie będzie umiał.
Najłatwiejszą dla normalnego człowieka opcją byłoby to umieścić w necie i żeby przez neta sobie wchodził. Albo jakąś apkę, co się tylko ściąga i odpala (np. Electron). Albo żeby to było w takim stanie, że wystarczy tylko otworzyć w przeglądarce plik *.html, ale to może czasem się nie udać z powodu zabezpieczeń przeglądarek (zależy, co będziesz dokładnie robić na stronie).
LukeJL napisał(a):
B.Eng napisał(a):
właśnie nie chciałem się Dockera bawić. Nie mogę założyć, że osoba do które to idzie (klient) ma Dockera, albo chce się w niego bawić.
Jak bardzo techniczny jest klient?
takiej informacji nie mam. zakładam, że coś tam umie skoro chce lokalnie odpalić
chce po prostu zrobić to w miarę możliwości "schludnie" czyli nie walnąć takiego babola, jak np zrobienie małego API stawiając cały Django projekt
moze przesadzam z tym problemem, ale chciałbym dać po prostu możliwie proste i przystępne rozwiązanie, ale też na drugim miejscu, nie używać czegoś totalnie randomowego
obecenie się zastanawiam nad Parcel i Browsersync najbardziej chyba
takiej informacji nie mam. zakładam, że coś tam umie skoro chce lokalnie odpalić
Aha, no to teraz nareszcie wiemy o co biega, trochę to zajęło xD Jeśli to tylko frontend, to zrób po prostu tak, żeby npm install && npm start
odpalało co chcesz. Z tego co pamiętam to jest standard. Potem będziesz mógł zmieniać w package.json
co ma się odpalać, a klient nie zobaczy różnicy.
Najprostsze opcje już padły - pendrive (czy jakikolwiek inny drive łęcznie z mailem ), netlify, github pages - to dla pełności dodam serwowanie z local
Możesz odpalić aplikację lokalnie i np użyć ngrok żeby tunelować port 80, ngrok da ci adres który możesz podac klientowi.
O ile jednak są to tylko pliki HTML, CSS, JS to zostałbym przy przesłaniu mailem z krótką instrukcją:
szatkus1 napisał(a):
Zwykle do takich rzeczy wklepuję
python -m http.server
padło na powyższe.
nie spodziewałem się, ze Python tak prosto ma możliwość serwowania lokalnych plików. właściwie 0 konfiguracji, jeśli ktoś czyta temat i tego szuka, to polecam w sumie