Zahájili jsme velký přepis Angelcam.com z kombinace Nette na frontendu a několik Node.js microservice na backendu do jednoho Django monolitu a řeším situaci, kdy jako jediný se bohatými zkušenostmi v Djangu zavádím best-practices pro nový projekt. Moc toho ale nevím o moderním frontendu a kolegové mě přesvědčují, že tradiční Django nástroje, které znám (django-compressor apod.) jsou zastaralé a správná ceste je gulp.
A maji pravdu. Nevim jestli s gulpem (nejnovejsi trendy ve frontendu nesleduju) ale pokud to jde tak oddel backend a frontend co nejdriv.
Jako backendově orientovaný člověk bych nerad bránil použití moderního frontend řešení, ale když vidím, že zprovoznění gulpu a laravel-elixir protáhlo build docker kontejneru z původních 30s na 2m20s, v repu přibyl npm-shrikwrap.json o 4.000 řádcích a node_modules má 240 MB, nemám z toho úplně dobrý pocit.
Oddel to uplne od sebe. Frontend budou driv nebo pozdeji delat jini lidi nez backed a bude na nich, jak build FE zrealizuji. Ty budes jen linkovat finalni soubory.
P.S.: Je to docela zajímavý projekt a sháníme na něj kolegy jak na trvalou spolupráci, tak externisty/freelancery na dočasnou spolupráci. Zatím je naplánováno cca do konce roku přepis stávajícího a pokládání základů, po Novém roce pak přidávání fíčur, nové byznys logiky a vylepšování backendu.
Jj, pulrok pryc a lidi zase nejsou :)
Jako backendově orientovaný člověk bych nerad bránil použití moderního frontend řešení, ale když vidím, že zprovoznění gulpu a laravel-elixir protáhlo build docker kontejneru z původních 30s na 2m20s, v repu přibyl npm-shrikwrap.json o 4.000 řádcích a node_modules má 240 MB, nemám z toho úplně dobrý pocit.Oddel to uplne od sebe. Frontend budou driv nebo pozdeji delat jini lidi nez backed a bude na nich, jak build FE zrealizuji. Ty budes jen linkovat finalni soubory.
Jako backendově orientovaný člověk bych nerad bránil použití moderního frontend řešení, ale když vidím, že zprovoznění gulpu a laravel-elixir protáhlo build docker kontejneru z původních 30s na 2m20s, v repu přibyl npm-shrikwrap.json o 4.000 řádcích a node_modules má 240 MB, nemám z toho úplně dobrý pocit.Oddel to uplne od sebe. Frontend budou driv nebo pozdeji delat jini lidi nez backed a bude na nich, jak build FE zrealizuji. Ty budes jen linkovat finalni soubory.
No to právě nechci. Možná v nějaké pozdější fázi, ale v současném týmu (6 programátorů) mi přijde jako luxus, aby byly jednotliví lidi specialisti na něco. Jeden z hlavních důvodů, proč nám nefungovala architektura microservice byla tendence, kdy někdo měl pocit, že vlastní danou komponentu, ostatní se nezajímali, jak je to udělané a s opravami chyb nebo novými fíčurami se čekalo na daného specialistu.Samozřejmě, že každý má oblast, ve které se vyzná nejvíc, ale myslím, že i backenďák, který, když to přeženu, přidá DateTimeField by měl být schopný udělat i formulář s DateSelect widgetem (t.j. i nějaké css a js) a dát to vývojový server, kde se na to podívá zadavatel a ověří, že to reálně řeší problém, který to řešit mělo - a to všechno bez toho, aby čekali než jim frontend team přikompiluje ten js do nějakého min.js.
Jasne, nevnucuju, jen sdilim vlastni zkusenost.
Podle me si ty dve veci (backend/fronted kod) zaslouzi oddelene zpracovani. FE nezajima jakou DB mas za sebou, jake predpoklady musi splnit aby jim neco fungovalo. To same plati i z pohledu BE — jestli nekdo udela funkcni FE na reactu nebo jQuery, je mi to jedno. Je to jasna hranice, kazda z tech stran ma sve nastroje a navyklosti, kterych se nemusi vzdavat. Staci si dohodnout rozhrani, pres ktere budou komunikovat (a to muze byt klasicke API na BE, a zkompilovane JS/CSS od FE).
My jsme to delali dlouhou dobu klasicky, jako asi vetsina Djangistu (staticke soubory u projektu, nedej boze rozdelene podle appek do nekolika samostatnych static/ adresaru). ./manage.py staticfiles pak trval minuty, semtam cely proces spadl protoze v Bootstrap CSS se objevil nejaky pokazeny UTF-8 znak, a podobne dobroty. FE team s nama dokola resil co a kam maji nakopirovat, zavolat, aby se to v Djangu objevilo. Tohle vsechno ve mne nechalo pachut, ke ktere bych se nerad vracel.
S malym tymem bych to asi zasel mastil vsechno na jedne hromadce. S tymem sesti lidi bych to ale uz asi resil jinak.
Toz at se dari!
M.
--
--
E-mailová skupina djan...@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
---
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu django-cs+unsubscribe@googlegroups.com.
Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/etPan.57e415aa.63702aaf.16739%40plovarna.cz.
Ahoj,máte někdo zkušenosti s kombinací Django + gulp pro správu frontendu (Sass, minifikace, instalace externích balíčků jako je Foundation)?Zahájili jsme velký přepis Angelcam.com z kombinace Nette na frontendu a několik Node.js microservice na backendu do jednoho Django monolitu a řeším situaci, kdy jako jediný se bohatými zkušenostmi v Djangu zavádím best-practices pro nový projekt. Moc toho ale nevím o moderním frontendu a kolegové mě přesvědčují, že tradiční Django nástroje, které znám (django-compressor apod.) jsou zastaralé a správná ceste je gulp.
Jako backendově orientovaný člověk bych nerad bránil použití moderního frontend řešení, ale když vidím, že zprovoznění gulpu a laravel-elixir protáhlo build docker kontejneru z původních 30s na 2m20s, v repu přibyl npm-shrikwrap.json o 4.000 řádcích a node_modules má 240 MB, nemám z toho úplně dobrý pocit.
Konkrétní otázky:- přináší gulp něco výrazně lepšího než klasické django nástroje?
- jaký nástroj byste použili místo gulp (jde hlavně o to, aby frotenďák/koder mohl ve Foundation vytvářet komponenty použitelné ostatními)
- dá se rozumně zkombinovat s běžným vývojovým django workflow (django-gulp na první vyzkoušení funguje s runserver, podle dokumentace i collectstatic, ale praktické zkušenosti jsou nenahraditelné)
- nerozbijou se třeba reusable appky, které bundlují statické soubory, media ve formech apod.?
Zahájili jsme velký přepis Angelcam.com z kombinace Nette na frontendu a několik Node.js microservice na backendu do jednoho Django monolitu a řeším situaci, kdy jako jediný se bohatými zkušenostmi v Djangu zavádím best-practices pro nový projekt. Moc toho ale nevím o moderním frontendu a kolegové mě přesvědčují, že tradiční Django nástroje, které znám (django-compressor apod.) jsou zastaralé a správná ceste je gulp.podle toho, co vidím všude kolem mají pravdu
Jako backendově orientovaný člověk bych nerad bránil použití moderního frontend řešení, ale když vidím, že zprovoznění gulpu a laravel-elixir protáhlo build docker kontejneru z původních 30s na 2m20s, v repu přibyl npm-shrikwrap.json o 4.000 řádcích a node_modules má 240 MB, nemám z toho úplně dobrý pocit.javascript je poslední dobou dost pohyblivý písek. vzniká hodně projektů, má vlastní balíčkovací systém (npm - javascript ekvivalent k pip), doba buildu je opravdu dlouhá, závislostí jak máku, co měsíc se to mění pod rukama, ale když se to podaří nějak seskládat dohromady tak to dává smysl
mini...@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible.
gulp je nástroj, který se doporučuje místo "těch druhých", je to *momentální* best practice. ale počet MB v node_modules to nezmenší- dá se rozumně zkombinovat s běžným vývojovým django workflow (django-gulp na první vyzkoušení funguje s runserver, podle dokumentace i collectstatic, ale praktické zkušenosti jsou nenahraditelné)imho jo, ale doporučil bych oddělit front-end od back-endu a nechat je žít vlastním životem