Django frontend a gulp

[Václav Řehák]

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.?

Díky,

Vašek

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.

[Plovarna]

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 :)

[Václav Řehák]

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.

Jenom aby nedošlo k nedorozumění, i backendem myslím typické databázově centrické Django aplikaci, pak máme úplný infrastrukturní backend jako streamovací servery, storage videa apod., ale to beru bokem.

[Plovarna]

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.

[Robert Smol]

Ahoj,

prihodim par svych zkusenosti. Obecne bych se ridil tim, co umi vetsina lidi v tymu. Mnoho lidi z djanga travi prilis mnoho casu nadcasovymi optimalizacemi na mistech, kde to neni v dany moment nezbytne nutne.

- přináší gulp něco výrazně lepšího než klasické django nástroje?

Pro FE hlavne to, ze se nemusi ucit django veci. Django compressor dela svou vec, ale pokud jsi uz zvykly na nejaky workflow, tak se to prvni dny dost plete pod nohy. Navic je na webu mnoho hotovych receptu na inegraci LiveReload, SVG optimizeru, post css apod. Netvrdim, ze to v django-compressor nejde, ale rozhodne na tom stravis mnoho casu.

- 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)

Pokud vetsina zna gulp/grunt/node scripts zustante  u toho. Me se osvedila kombinace bower (pro intalaci fe knihoven)+gulp+node

- 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é)

Ja si vzdy vystacil s oddelenym adresarem pro fronted veci (typograficka stranka vcetne komponent), nasledna kompilace (dist ukazoval do struktury djanga) a pouzival jsem django static files "ManifestStaticFilesStorage" pro hashe v souborech.

Na vetsim projektu takovy adresaru bylo i vice(menili se FE developeri, psali se ruzne mini appky), podstatne byl vzdy vysledny CSS soubor.

Minusem jsou komity pro staticke buildy pro produkci, ale ja radeji to, nez abych se pak spolehal na "live" kompilaci na serveru.

Je taky pravda, ze node_modules mohou byt obrovske (kazdy modul si tahne svoje zavislosti), ale ja to mam pouze na dev stroji.

Robert

--
--
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.

Další možnosti najdete na https://groups.google.com/d/optout.

[Jachym Cepicky]

Zdravím,

považuju se spíš za back-enďáka, ale k djangu jsem zatím čuchnul spíš z dálky a posledních cca 10 let mě živí javascript, snad budou informce relevantní

čt 22. 9. 2016 v 17:52 odesílatel Václav Řehák <reha...@gmail.com> napsal:

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.

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

 

Konkrétní otázky:

- přináší gulp něco výrazně lepšího než klasické django nástroje?

nevím jestli lepšího, ale dává určitě možnost reagovat na současné trendy a rychle adoptovat nejnovější vývoj stran koprese, optimalizace, lintování atd

 

- 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)

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

 

- nerozbijou se třeba reusable appky, které bundlují statické soubory, media ve formech apod.?

o tomhle nic nevím - ale asi to vyřeší odělení front-endu a back-endu

J

[Radek Svarz]

Ahoj,

pokud FE od BE oddelis, budou se Ti lip shanet lidi pro FE.

Setkal jsem se uz s FE borcem, ktery mi na Django projekt reagoval, ze nema rad python. Pak do ruky dostal akorat API a bylo to v pohode.

Radek

[Václav Řehák]

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

Opravdu to neumím posoudit, každopádně jsme gulp nakonec použili.

Díky Dockeru se to dá jakž takž zkombinovat - instalaci Node.js, gulp apod. jsme dali do base image, čímž se zkrátila doba buildu i zmenišil opruz pro ty, co se v JavaScriptu hrabat nechtějí.

 

 

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

No právě, ta nestabilita ekosystému je šílená. Minulý týden nám build nefungoval, protože desetinkový update npm začal instalovat devDependencies nebo co a npm install spadl na knihovně fsevents.

Což v záplavě chyb jako

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.

které vygeneruje běžný npm install gulp docela zanikne. Nemluvě o prasárnách jako "curl -sL https://deb.nodesource.com/setup_6.x | bash -" pod rootem.

Btw, kolega upozornil na https://yarnpkg.com/ , takže možná i ta instalace se podaří zkrátit.

 

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

To oddělení  nakonec částečně proběhlo, frontend vývoj probíhá bokem a pro backendisty stačí pustit v dockeru "gulp" a někde ve static dirs vzniknou výsledné js a css. Při vývoji servírované přes runserver, na produkci přes WhiteNoise (a možná CloudFront, uvidíme).

V.