Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-26 Thread MirekZv 
https://dafoster.net/articles/2021/02/16/building-web-apps-with-vue-and-django-the-ultimate-guide/

Dne čtvrtek 25. února 2021 v 14:52:16 UTC+1 uživatel jan.be...@gmail.com 
napsal:

> Mám jeden projekt který má Django backend s GraphQL API. A je to super, 
> GraphQL je významný evoluční pokrok oproti REST. Idea byla, že frontend 
> vytvoří někdo jiný, proto taky GraphQL. Ale nakonec jsem ho dělal taky, a 
> abych nemusel přepínat mezi jazyky a technologiemi, tak je frontend taky v 
> Djangu. Nemá žádné modely, jen pracuje s tím GraphQL API a vykresluje z 
> toho web (využívám především views, templaty a formuláře). Ale pokud nevadí 
> vykreslování na serveru, tak je Django na frontend úplně v pohodě.
>
> To jen tak pro zpestření, že se to dá dělat všelijak :-)
>
> Honza
>
> st 24. 2. 2021 v 20:17 odesílatel MirekZv  napsal:
>
>> @Standa
>>
>>>
>> Nevím o tom zatím nic.
>> Tady je nějaké video, které bych si já chtěl zkouknout. 
>> https://www.youtube.com/watch?v=3eTtVY7duJk
>> A pak se samozřejmě proberu názory ostatních, co napsali sem.
>>
>> -- 
>>
> -- 
>> 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+...@googlegroups.com.
>>
> Chcete-li tuto diskusi zobrazit na webu, navštivte 
>> https://groups.google.com/d/msgid/django-cs/5b9f9231-fdda-4bbc-82c8-4c3f7efd36aen%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
-- 
E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/ff475ddf-26c1-4d42-98e0-c9b4cc233e2fn%40googlegroups.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-25 Thread Jan Bednařík 
Mám jeden projekt který má Django backend s GraphQL API. A je to super,
GraphQL je významný evoluční pokrok oproti REST. Idea byla, že frontend
vytvoří někdo jiný, proto taky GraphQL. Ale nakonec jsem ho dělal taky, a
abych nemusel přepínat mezi jazyky a technologiemi, tak je frontend taky v
Djangu. Nemá žádné modely, jen pracuje s tím GraphQL API a vykresluje z
toho web (využívám především views, templaty a formuláře). Ale pokud nevadí
vykreslování na serveru, tak je Django na frontend úplně v pohodě.

To jen tak pro zpestření, že se to dá dělat všelijak :-)

Honza

st 24. 2. 2021 v 20:17 odesílatel MirekZv  napsal:

> @Standa
>
>>
> Nevím o tom zatím nic.
> Tady je nějaké video, které bych si já chtěl zkouknout.
> https://www.youtube.com/watch?v=3eTtVY7duJk
> A pak se samozřejmě proberu názory ostatních, co napsali sem.
>
> --
> --
> E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/5b9f9231-fdda-4bbc-82c8-4c3f7efd36aen%40googlegroups.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAMmgUkMHWqrNNi9X5x%2BLoV%3DxWCJFo1YQzG_bGvnGciJSdgFhqg%40mail.gmail.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-24 Thread MirekZv 
@Standa

>
Nevím o tom zatím nic.
Tady je nějaké video, které bych si já chtěl zkouknout. 
https://www.youtube.com/watch?v=3eTtVY7duJk
A pak se samozřejmě proberu názory ostatních, co napsali sem.

-- 
-- 
E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/5b9f9231-fdda-4bbc-82c8-4c3f7efd36aen%40googlegroups.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-24 Thread Petr Messner 
st 24. 2. 2021 v 13:15 odesílatel Honza Javorek 
napsal:

>
> Jde o tooling a vlastnosti toho kterého přístupu. V RESTu slozis dotaz a
> zparsujes odpověď čímkoliv, to u GraphQL nebyla drive pravda. Pokud to je
> dnes OK, tak super. Vlastnosti RESTu nemusí být ideální pro BE a FE
> interplay, protože ta vyžaduje jiné, tak se GraphQL hodi víc. REST zase
> nabízí třeba kešovatelnost atd. Je na každém, aby zvážil, co potřebuje a co
> nevyužije. Je fajn, ze existuje vyber. Nejsem ale zastáncem silver bullets.
>


GraphQL odpověď je ale zase jen JSON? (Pokud se bavíme o typickém API, nic
mi nebrání dělat graphql přes grpc.) Kdybych chtěl, tak se můžu na
jednotlivé konkrétní graphql query (a klidně i mutace) dívat jako na
jednotlivé REST endpointy (s trochu nezvyklou URL, ale i to se dá řešit).
Včetně kešovatelnosti. I swagger si k tomu můžu napsat, nebo ještě lépe
vygenerovat.

Petr M.

-- 
-- 
E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK9Q5BRrU3tkGiB-5HgfsM43YNj79cmy76zf7jDO-GY3yZeQew%40mail.gmail.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-24 Thread Honza Javorek 
Pardon, psal jsem z mobilu a ze záhadných důvodů vidím prostřední část své
odpovědi Petrovi bílým fontem (???), tak jen pro úplnost. Pokud to vidíte
stejně jako já, s velkou bílou mezerou, tak do ní patří toto:

Oboje je technický i lidský rozměr. BE a FE jsou každá jedna strana nějaké
dohody (= API), jsou to lidi a zodpovídají za nějaké technické řešení.
Souboj REST a GraphQL mi přijde jako ode-zdi-ke-zdi-smus. Facebook se
trefil do frustrace FE, ale že vyhrálo zrovna jeho řešení je taky velkou
měrou síla jeho dev marketingu, tomu se nějaké komunitní projekty nebo
vágnější architektury nemůžou rovnat. Každopádně dnes si muže každý vybrat,
co se mu víc hodí a líbí.

HJ

On Wed, Feb 24, 2021 at 1:14 PM Honza Javorek  wrote:

>
>
> On Wed 24. 2. 2021 at 12:45, Petr Messner  wrote:
>
>>
>>
>> út 23. 2. 2021 v 12:03 odesílatel Honza Javorek 
>> napsal:
>>
>>>
>>> Jinak je dnes trh zblaznen do SPA, takže jakmile chceš frontend zadat
>>> atd., budou na tebe s timhle koukat jak na blázna, protože přece standard
>>> je React nebo Vue a 3000 npm balíčku k tomu a bez toho “si spad z višně ne,
>>> dědku”? Nebo aspoň tak mi to přijde :D
>>>
>>
>> LOL :)
>>
>
>> Ono je to spíš tak, že dělat frontend v něčem jiném než React/Vue je pro
>> frontendistu asi jako by bylo pro spoustu pythonistů dělat backend v něčem
>> jiném, ne Django/Flask.
>>
>
>
> Podle mě nejsme v rozporu, jen já to podávám se specifickou emocí :)
>
>
>
>>
>>> S tím API, podle mě REST, tak jak ho provozovala většina, bylo “my
>>> backendisti ti tady dáváme co ti dáváme a ty frontendisto se s tím smiř” (v
>>> Apiary jsme se snažili, aby probíhal dialog, ale asi to bylo nemožné to po
>>> lidech chtít). Takže frontendisti si na truc přišli s GraphQL a řekli “my
>>> frontendisti chceme odpovědi tady na tyhle queries
>>>
>>
>> Ano, konečně lidský rozměr dostal prioritu před technickým :) Akorát to
>> zase musel udělat Facebook, protože teprve při jejich škále jim to
>> explodovalo natolik, že už to s REST náboženstvím (i přes pokusy o inovaci
>> v Apiary) fakt nešlo.
>>
>
> Oboje je technický i lidský rozměr. BE a FE jsou každá jedna strana nějaké
> dohody (= API), jsou to lidi a zodpovídají za nějaké technické řešení.
> Souboj REST a GraphQL mi přijde jako ode-zdi-ke-zdi-smus. Facebook se
> trefil do frustrace FE, ale že vyhrálo zrovna jeho řešení je taky velkou
> měrou síla jeho dev marketingu, tomu se nějaké komunitní projekty nebo
> vágnější architektury nemůžou rovnat. Každopádně dnes si muže každý vybrat,
> co se mu víc hodí a líbí.
>
>
>> Jestli je GraphQL vhodné i jako public API “pro stroje”
>>>
>>
>> Je. (Ano, vím, žes měl na Github graphql api problém s timeouty :) )
>>
>
>> jakmile chceš takové API konzumovat v Pythonu, už to hodně skripalo
>>>
>>
>> Vždyť GraphQL dotaz je obyčejný POST request?
>>
>>
>> co by na to řekli Javisti v bance
>>>
>>
>>
>> https://dagblog.cz/velvon-debriefieng-ii-organizace-v%C3%BDvoje-bbec1f5dcaa7
>>
>> Petr M.
>>
>
> O mých timeoutech to není. Jde o tooling a vlastnosti toho kterého
> přístupu. V RESTu slozis dotaz a zparsujes odpověď čímkoliv, to u GraphQL
> nebyla drive pravda. Pokud to je dnes OK, tak super. Vlastnosti RESTu
> nemusí být ideální pro BE a FE interplay, protože ta vyžaduje jiné, tak se
> GraphQL hodi víc. REST zase nabízí třeba kešovatelnost atd. Je na každém,
> aby zvážil, co potřebuje a co nevyužije. Je fajn, ze existuje vyber. Nejsem
> ale zastáncem silver bullets.
>
> Literatura:
>
> https://apisyouwonthate.com/blog/graphql-vs-rest-overview/
>
> https://goodapi.co/blog/rest-vs-graphql
>
>
> Honza
>
>>

-- 
-- 
E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAPAmg-drm-fw3%3DQ3Dzue3eEMzyj1mizGms2DdJZpi9mN9m3z3Q%40mail.gmail.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-24 Thread Honza Javorek 
On Wed 24. 2. 2021 at 12:45, Petr Messner  wrote:

>
>
> út 23. 2. 2021 v 12:03 odesílatel Honza Javorek 
> napsal:
>
>>
>> Jinak je dnes trh zblaznen do SPA, takže jakmile chceš frontend zadat
>> atd., budou na tebe s timhle koukat jak na blázna, protože přece standard
>> je React nebo Vue a 3000 npm balíčku k tomu a bez toho “si spad z višně ne,
>> dědku”? Nebo aspoň tak mi to přijde :D
>>
>
> LOL :)
>

> Ono je to spíš tak, že dělat frontend v něčem jiném než React/Vue je pro
> frontendistu asi jako by bylo pro spoustu pythonistů dělat backend v něčem
> jiném, ne Django/Flask.
>


Podle mě nejsme v rozporu, jen já to podávám se specifickou emocí :)



>
>> S tím API, podle mě REST, tak jak ho provozovala většina, bylo “my
>> backendisti ti tady dáváme co ti dáváme a ty frontendisto se s tím smiř” (v
>> Apiary jsme se snažili, aby probíhal dialog, ale asi to bylo nemožné to po
>> lidech chtít). Takže frontendisti si na truc přišli s GraphQL a řekli “my
>> frontendisti chceme odpovědi tady na tyhle queries
>>
>
> Ano, konečně lidský rozměr dostal prioritu před technickým :) Akorát to
> zase musel udělat Facebook, protože teprve při jejich škále jim to
> explodovalo natolik, že už to s REST náboženstvím (i přes pokusy o inovaci
> v Apiary) fakt nešlo.
>

Oboje je technický i lidský rozměr. BE a FE jsou každá jedna strana nějaké
dohody (= API), jsou to lidi a zodpovídají za nějaké technické řešení.
Souboj REST a GraphQL mi přijde jako ode-zdi-ke-zdi-smus. Facebook se
trefil do frustrace FE, ale že vyhrálo zrovna jeho řešení je taky velkou
měrou síla jeho dev marketingu, tomu se nějaké komunitní projekty nebo
vágnější architektury nemůžou rovnat. Každopádně dnes si muže každý vybrat,
co se mu víc hodí a líbí.


> Jestli je GraphQL vhodné i jako public API “pro stroje”
>>
>
> Je. (Ano, vím, žes měl na Github graphql api problém s timeouty :) )
>

> jakmile chceš takové API konzumovat v Pythonu, už to hodně skripalo
>>
>
> Vždyť GraphQL dotaz je obyčejný POST request?
>
>
> co by na to řekli Javisti v bance
>>
>
>
> https://dagblog.cz/velvon-debriefieng-ii-organizace-v%C3%BDvoje-bbec1f5dcaa7
>
> Petr M.
>

O mých timeoutech to není. Jde o tooling a vlastnosti toho kterého
přístupu. V RESTu slozis dotaz a zparsujes odpověď čímkoliv, to u GraphQL
nebyla drive pravda. Pokud to je dnes OK, tak super. Vlastnosti RESTu
nemusí být ideální pro BE a FE interplay, protože ta vyžaduje jiné, tak se
GraphQL hodi víc. REST zase nabízí třeba kešovatelnost atd. Je na každém,
aby zvážil, co potřebuje a co nevyužije. Je fajn, ze existuje vyber. Nejsem
ale zastáncem silver bullets.

Literatura:

https://apisyouwonthate.com/blog/graphql-vs-rest-overview/

https://goodapi.co/blog/rest-vs-graphql


Honza

>

-- 
-- 
E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAPAmg-fG36j%3DHYaCAWQbBw1mnjvU7tioQu_A4LyX5LVa6qhu4A%40mail.gmail.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Jan Walter 
Mrkni https://github.com/jnwltr/swagger-angular-generator. Obdobnych
knihoven najdes urcite vic. Lisit se budou estetikou a funkcnosti (vc.
cilovyho frameworku), co z toho leze.

Nejde jen o to, ze to setri, jak rikas, nudnou praci, ale hlavne to vytvari
pevnou vazbu mezi FE a BE, cili to vychytava mozny chyby typicky pri
zmenach BE (nepasujici FE ani nebuildnes).

On Tue, 23 Feb 2021, 18:03 mk,  wrote:

> Kdysi jsem delal nejaky demo projekt s https://intercoolerjs.org/ a byla
> to docela pohoda. Intercooler, se zda, mezitim zmutoval do
> https://htmx.org/
>
> Dne úterý 23. února 2021 v 12:03:19 UTC+1 uživatel Honza Javorek napsal:
>
>> Podle mě ten hotwire muže fungovat dobře, pokud mas tým na jedne lodi a
>> chcete to tak dělat, nebo si to děláš sám pro sebe. A pokud nechceš silně
>> oddělovat ty role do sila “frontendist” a “backendisti”, ale mas lidi,
>> kteří rozumí víc celé věci. Ale přímou zkušenost nemám.
>>
>> Jinak je dnes trh zblaznen do SPA, takže jakmile chceš frontend zadat
>> atd., budou na tebe s timhle koukat jak na blázna, protože přece standard
>> je React nebo Vue a 3000 npm balíčku k tomu a bez toho “si spad z višně ne,
>> dědku”? Nebo aspoň tak mi to přijde :D
>>
>> S tím API, podle mě REST, tak jak ho provozovala většina, bylo “my
>> backendisti ti tady dáváme co ti dáváme a ty frontendisto se s tím smiř” (v
>> Apiary jsme se snažili, aby probíhal dialog, ale asi to bylo nemožné to po
>> lidech chtít). Takže frontendisti si na truc přišli s GraphQL a řekli “my
>> frontendisti chceme odpovědi tady na tyhle queries a ty backendisto se s
>> tím smiř”. Tedy ten trend je teď takový, že na backendu vystavis GraphQL a
>> frontendista si na tom už pak zvládne postavit co potřebuje, nemusíš se
>> trápit s REST API na míru. Jestli je GraphQL vhodné i jako public API “pro
>> stroje” (tedy ono je to VŽDY pro lidi, na to je dobré myslet, ale v tomto
>> případě jsou to asi backenďáci skrze nějakou integraci), o tom jsem se
>> zatím úplně nerozhodl. Podle mě to rozhoduje především tooling - většina
>> toho je v JS a jakmile chceš takové API konzumovat v Pythonu, už to hodně
>> skripalo (dnes lepší, jsem nedávno zjistil, vyvíjí se to) a nechci vědět,
>> co by na to řekli Javisti v bance (ale třeba se mýlím a Java support pro
>> konzumaci GraphQL - ne tvorbu backendu, pozor - je v pohodě). Takže někdy
>> lidi udělají GraphQL pro frontenďáky a pak vedle toho ještě nutné minimum
>> REST API pro externí integraci.
>>
>> Tož tolik mých 5 haléřů.
>>
>> HJ
>>
>>
>> On Tue 23. 2. 2021 at 11:22, Vladimír Macek  wrote:
>>
>>> Hotwire vypadá pro nás staromilce zajímavě. Ale nezruší se tím Martinem
>>> popisované výhody? Hranice působnosti rolí v týmu, dané a dokumentované
>>> rozhraní světů, rozdělení BE do komponent...
>>>
>>> Když by tu byl datově orientovaný projekt, u kterýho se člověk zaměřuje
>>> na
>>> komplikovanější backend, frontend by rád někomu zadal a zároveň by
>>> chtěl,
>>> aby k datům backendu mohly i stroje, služby...
>>>
>>> Jsem v té situaci a zajímalo by mě, zda skutečně máte někdo hlubší
>>> zkušenost s tím, že vyrábíte API pro stroje i FE zároveň. Chápu, že
>>> stroj i
>>> FE budou mít nějaké extra buřtíky, které ten druhý nevyužije. Zůstává
>>> ale
>>> BE API jednotné?
>>>
>>> Pozitivní náznaky v diskusi jsou, ale vyzkoušel někdo skutečně tento
>>> princip hlouběji? Pokud ano, co jste na to použili a jste s tou volbou
>>> spokojení? (Honzovu reakci jsem zachytil a chápu ji jako pozitivní hlas.)
>>>
>>> Jak vypadá třeba po 6 nebo 12 život s tím, že FEčkaři mají nějaké
>>> požadavky, strojové API si vyžaduje možná něco trošku jiného...?
>>>
>>> Netvrdím, že nemám představu o cestě a že nemám žádné API za sebou. :-)
>>> Ale
>>> stejně jako Standa nechci, aby mi unikla zajímavá volba na základě
>>> zkušeností.
>>>
>>> Díky,
>>>
>>> Vláďa Macek | +420 608 978 164 <+420%20608%20978%20164>
>>>
>>>
>>> On 23. 02. 21 10:08, Honza Javorek wrote:
>>> > Uvažoval nebo použil někdo
>>> > https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga
>>> > generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad
>>> > tím? Existuje to dlouho a Basecamp (37signals) to používá odjakživa,
>>> teď
>>> > tomu dali akorát webovku a název, protože je štval nedostatek
>>> protiváhy k
>>> > termínům jako SPA a Jamstack.
>>> >
>>> > Honza
>>> >
>>> >
>>> > On Tue 23. 2. 2021 at 10:02, Jan Walter >> > > wrote:
>>> >
>>> > My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django
>>> > REST Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj
>>> > naším (opensource) generátorem vygenerujeme celou komunikační
>>> vrstvu
>>> > na FE, čili tímhle netrávíme ani minutu času, v běžných scénářích
>>> je
>>> > vše krásné a otypované (jeden model).
>>> >
>>> > Určitě takovou věc lze najít/mít i pro react/vue.
>>> >
>>> > On Tue, 23 Feb 2021, 09:41 Stanislav Vasko,
>>> > mailto:stanisl...@gmail.com>> wrote:
>>> >
>>> >

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread mk 
Kdysi jsem delal nejaky demo projekt s https://intercoolerjs.org/ a byla to 
docela pohoda. Intercooler, se zda, mezitim zmutoval do  https://htmx.org/

Dne úterý 23. února 2021 v 12:03:19 UTC+1 uživatel Honza Javorek napsal:

> Podle mě ten hotwire muže fungovat dobře, pokud mas tým na jedne lodi a 
> chcete to tak dělat, nebo si to děláš sám pro sebe. A pokud nechceš silně 
> oddělovat ty role do sila “frontendist” a “backendisti”, ale mas lidi, 
> kteří rozumí víc celé věci. Ale přímou zkušenost nemám.
>
> Jinak je dnes trh zblaznen do SPA, takže jakmile chceš frontend zadat 
> atd., budou na tebe s timhle koukat jak na blázna, protože přece standard 
> je React nebo Vue a 3000 npm balíčku k tomu a bez toho “si spad z višně ne, 
> dědku”? Nebo aspoň tak mi to přijde :D
>
> S tím API, podle mě REST, tak jak ho provozovala většina, bylo “my 
> backendisti ti tady dáváme co ti dáváme a ty frontendisto se s tím smiř” (v 
> Apiary jsme se snažili, aby probíhal dialog, ale asi to bylo nemožné to po 
> lidech chtít). Takže frontendisti si na truc přišli s GraphQL a řekli “my 
> frontendisti chceme odpovědi tady na tyhle queries a ty backendisto se s 
> tím smiř”. Tedy ten trend je teď takový, že na backendu vystavis GraphQL a 
> frontendista si na tom už pak zvládne postavit co potřebuje, nemusíš se 
> trápit s REST API na míru. Jestli je GraphQL vhodné i jako public API “pro 
> stroje” (tedy ono je to VŽDY pro lidi, na to je dobré myslet, ale v tomto 
> případě jsou to asi backenďáci skrze nějakou integraci), o tom jsem se 
> zatím úplně nerozhodl. Podle mě to rozhoduje především tooling - většina 
> toho je v JS a jakmile chceš takové API konzumovat v Pythonu, už to hodně 
> skripalo (dnes lepší, jsem nedávno zjistil, vyvíjí se to) a nechci vědět, 
> co by na to řekli Javisti v bance (ale třeba se mýlím a Java support pro 
> konzumaci GraphQL - ne tvorbu backendu, pozor - je v pohodě). Takže někdy 
> lidi udělají GraphQL pro frontenďáky a pak vedle toho ještě nutné minimum 
> REST API pro externí integraci.
>
> Tož tolik mých 5 haléřů.
>
> HJ
>
>
> On Tue 23. 2. 2021 at 11:22, Vladimír Macek  wrote:
>
>> Hotwire vypadá pro nás staromilce zajímavě. Ale nezruší se tím Martinem 
>> popisované výhody? Hranice působnosti rolí v týmu, dané a dokumentované 
>> rozhraní světů, rozdělení BE do komponent...
>>
>> Když by tu byl datově orientovaný projekt, u kterýho se člověk zaměřuje 
>> na 
>> komplikovanější backend, frontend by rád někomu zadal a zároveň by chtěl, 
>> aby k datům backendu mohly i stroje, služby...
>>
>> Jsem v té situaci a zajímalo by mě, zda skutečně máte někdo hlubší 
>> zkušenost s tím, že vyrábíte API pro stroje i FE zároveň. Chápu, že stroj 
>> i 
>> FE budou mít nějaké extra buřtíky, které ten druhý nevyužije. Zůstává ale 
>> BE API jednotné?
>>
>> Pozitivní náznaky v diskusi jsou, ale vyzkoušel někdo skutečně tento 
>> princip hlouběji? Pokud ano, co jste na to použili a jste s tou volbou 
>> spokojení? (Honzovu reakci jsem zachytil a chápu ji jako pozitivní hlas.)
>>
>> Jak vypadá třeba po 6 nebo 12 život s tím, že FEčkaři mají nějaké 
>> požadavky, strojové API si vyžaduje možná něco trošku jiného...?
>>
>> Netvrdím, že nemám představu o cestě a že nemám žádné API za sebou. :-) 
>> Ale 
>> stejně jako Standa nechci, aby mi unikla zajímavá volba na základě 
>> zkušeností.
>>
>> Díky,
>>
>> Vláďa Macek | +420 608 978 164 <+420%20608%20978%20164>
>>
>>
>> On 23. 02. 21 10:08, Honza Javorek wrote:
>> > Uvažoval nebo použil někdo
>> > https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga 
>> > generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad 
>> > tím? Existuje to dlouho a Basecamp (37signals) to používá odjakživa, 
>> teď 
>> > tomu dali akorát webovku a název, protože je štval nedostatek protiváhy 
>> k 
>> > termínům jako SPA a Jamstack.
>> >
>> > Honza
>> >
>> >
>> > On Tue 23. 2. 2021 at 10:02, Jan Walter > > > wrote:
>> >
>> > My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django
>> > REST Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj
>> > naším (opensource) generátorem vygenerujeme celou komunikační vrstvu
>> > na FE, čili tímhle netrávíme ani minutu času, v běžných scénářích je
>> > vše krásné a otypované (jeden model).
>> >
>> > Určitě takovou věc lze najít/mít i pro react/vue.
>> >
>> > On Tue, 23 Feb 2021, 09:41 Stanislav Vasko,
>> > mailto:stanisl...@gmail.com>> wrote:
>> >
>> > Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API
>> > je v Django sranda. Ale má-li mít API každý model, má-li API 
>> umět
>> > doposlat kontextové informace, pak nějaké přepínače, atd. začne
>> > se to nabalovat. Proto tam “remcám”, že sice to běhá a běhá to
>> > skvěle, ale všemu napsat API, vše ve Vue rozbalit a nandat do
>> > správný proměnný a pak teprve psát šablonu je proti Django
>> > response/request

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Honza Javorek 
Podle mě ten hotwire muže fungovat dobře, pokud mas tým na jedne lodi a
chcete to tak dělat, nebo si to děláš sám pro sebe. A pokud nechceš silně
oddělovat ty role do sila “frontendist” a “backendisti”, ale mas lidi,
kteří rozumí víc celé věci. Ale přímou zkušenost nemám.

Jinak je dnes trh zblaznen do SPA, takže jakmile chceš frontend zadat atd.,
budou na tebe s timhle koukat jak na blázna, protože přece standard je
React nebo Vue a 3000 npm balíčku k tomu a bez toho “si spad z višně ne,
dědku”? Nebo aspoň tak mi to přijde :D

S tím API, podle mě REST, tak jak ho provozovala většina, bylo “my
backendisti ti tady dáváme co ti dáváme a ty frontendisto se s tím smiř” (v
Apiary jsme se snažili, aby probíhal dialog, ale asi to bylo nemožné to po
lidech chtít). Takže frontendisti si na truc přišli s GraphQL a řekli “my
frontendisti chceme odpovědi tady na tyhle queries a ty backendisto se s
tím smiř”. Tedy ten trend je teď takový, že na backendu vystavis GraphQL a
frontendista si na tom už pak zvládne postavit co potřebuje, nemusíš se
trápit s REST API na míru. Jestli je GraphQL vhodné i jako public API “pro
stroje” (tedy ono je to VŽDY pro lidi, na to je dobré myslet, ale v tomto
případě jsou to asi backenďáci skrze nějakou integraci), o tom jsem se
zatím úplně nerozhodl. Podle mě to rozhoduje především tooling - většina
toho je v JS a jakmile chceš takové API konzumovat v Pythonu, už to hodně
skripalo (dnes lepší, jsem nedávno zjistil, vyvíjí se to) a nechci vědět,
co by na to řekli Javisti v bance (ale třeba se mýlím a Java support pro
konzumaci GraphQL - ne tvorbu backendu, pozor - je v pohodě). Takže někdy
lidi udělají GraphQL pro frontenďáky a pak vedle toho ještě nutné minimum
REST API pro externí integraci.

Tož tolik mých 5 haléřů.

HJ


On Tue 23. 2. 2021 at 11:22, Vladimír Macek  wrote:

> Hotwire vypadá pro nás staromilce zajímavě. Ale nezruší se tím Martinem
> popisované výhody? Hranice působnosti rolí v týmu, dané a dokumentované
> rozhraní světů, rozdělení BE do komponent...
>
> Když by tu byl datově orientovaný projekt, u kterýho se člověk zaměřuje na
> komplikovanější backend, frontend by rád někomu zadal a zároveň by chtěl,
> aby k datům backendu mohly i stroje, služby...
>
> Jsem v té situaci a zajímalo by mě, zda skutečně máte někdo hlubší
> zkušenost s tím, že vyrábíte API pro stroje i FE zároveň. Chápu, že stroj
> i
> FE budou mít nějaké extra buřtíky, které ten druhý nevyužije. Zůstává ale
> BE API jednotné?
>
> Pozitivní náznaky v diskusi jsou, ale vyzkoušel někdo skutečně tento
> princip hlouběji? Pokud ano, co jste na to použili a jste s tou volbou
> spokojení? (Honzovu reakci jsem zachytil a chápu ji jako pozitivní hlas.)
>
> Jak vypadá třeba po 6 nebo 12 život s tím, že FEčkaři mají nějaké
> požadavky, strojové API si vyžaduje možná něco trošku jiného...?
>
> Netvrdím, že nemám představu o cestě a že nemám žádné API za sebou. :-)
> Ale
> stejně jako Standa nechci, aby mi unikla zajímavá volba na základě
> zkušeností.
>
> Díky,
>
> Vláďa Macek | +420 608 978 164
>
>
> On 23. 02. 21 10:08, Honza Javorek wrote:
> > Uvažoval nebo použil někdo
> > https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga
> > generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad
> > tím? Existuje to dlouho a Basecamp (37signals) to používá odjakživa, teď
> > tomu dali akorát webovku a název, protože je štval nedostatek protiváhy
> k
> > termínům jako SPA a Jamstack.
> >
> > Honza
> >
> >
> > On Tue 23. 2. 2021 at 10:02, Jan Walter  > > wrote:
> >
> > My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django
> > REST Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj
> > naším (opensource) generátorem vygenerujeme celou komunikační vrstvu
> > na FE, čili tímhle netrávíme ani minutu času, v běžných scénářích je
> > vše krásné a otypované (jeden model).
> >
> > Určitě takovou věc lze najít/mít i pro react/vue.
> >
> > On Tue, 23 Feb 2021, 09:41 Stanislav Vasko,
> > mailto:stanislav.va...@gmail.com>>
> wrote:
> >
> > Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API
> > je v Django sranda. Ale má-li mít API každý model, má-li API umět
> > doposlat kontextové informace, pak nějaké přepínače, atd. začne
> > se to nabalovat. Proto tam “remcám”, že sice to běhá a běhá to
> > skvěle, ale všemu napsat API, vše ve Vue rozbalit a nandat do
> > správný proměnný a pak teprve psát šablonu je proti Django
> > response/request časově úplně jinde a u menších aplikací se mi
> > zdá, že budu více pracovat na API než aplikaci. Snad to píši
> > srozumitelně :)
> >
> > SV
> >
> >
> > On 23 February 2021 at 9:37:15, Jirka Vejrazka
> > (jirka.vejra...@gmail.com )
> wrote:
> >
> >> Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v
> >> dobe bronzove delal

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Vladimír Macek 
Hotwire vypadá pro nás staromilce zajímavě. Ale nezruší se tím Martinem 
popisované výhody? Hranice působnosti rolí v týmu, dané a dokumentované 
rozhraní světů, rozdělení BE do komponent...


Když by tu byl datově orientovaný projekt, u kterýho se člověk zaměřuje na 
komplikovanější backend, frontend by rád někomu zadal a zároveň by chtěl, 
aby k datům backendu mohly i stroje, služby...


Jsem v té situaci a zajímalo by mě, zda skutečně máte někdo hlubší 
zkušenost s tím, že vyrábíte API pro stroje i FE zároveň. Chápu, že stroj i 
FE budou mít nějaké extra buřtíky, které ten druhý nevyužije. Zůstává ale 
BE API jednotné?


Pozitivní náznaky v diskusi jsou, ale vyzkoušel někdo skutečně tento 
princip hlouběji? Pokud ano, co jste na to použili a jste s tou volbou 
spokojení? (Honzovu reakci jsem zachytil a chápu ji jako pozitivní hlas.)


Jak vypadá třeba po 6 nebo 12 život s tím, že FEčkaři mají nějaké 
požadavky, strojové API si vyžaduje možná něco trošku jiného...?


Netvrdím, že nemám představu o cestě a že nemám žádné API za sebou. :-) Ale 
stejně jako Standa nechci, aby mi unikla zajímavá volba na základě zkušeností.


Díky,

Vláďa Macek | +420 608 978 164


On 23. 02. 21 10:08, Honza Javorek wrote:

Uvažoval nebo použil někdo
https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga 
generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad 
tím? Existuje to dlouho a Basecamp (37signals) to používá odjakživa, teď 
tomu dali akorát webovku a název, protože je štval nedostatek protiváhy k 
termínům jako SPA a Jamstack.


Honza


On Tue 23. 2. 2021 at 10:02, Jan Walter > wrote:


My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django
REST Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj
naším (opensource) generátorem vygenerujeme celou komunikační vrstvu
na FE, čili tímhle netrávíme ani minutu času, v běžných scénářích je
vše krásné a otypované (jeden model).

Určitě takovou věc lze najít/mít i pro react/vue.

On Tue, 23 Feb 2021, 09:41 Stanislav Vasko,
mailto:stanislav.va...@gmail.com>> wrote:

Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API
je v Django sranda. Ale má-li mít API každý model, má-li API umět
doposlat kontextové informace, pak nějaké přepínače, atd. začne
se to nabalovat. Proto tam “remcám”, že sice to běhá a běhá to
skvěle, ale všemu napsat API, vše ve Vue rozbalit a nandat do
správný proměnný a pak teprve psát šablonu je proti Django
response/request časově úplně jinde a u menších aplikací se mi
zdá, že budu více pracovat na API než aplikaci. Snad to píši
srozumitelně :)

SV


On 23 February 2021 at 9:37:15, Jirka Vejrazka
(jirka.vejra...@gmail.com ) wrote:


Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v
dobe bronzove delal pomoci
https://www.django-rest-framework.org/ - znas?

  Jirka

On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko
mailto:stanislav.va...@gmail.com>>
wrote:

Díky za přehledné shrnutí. Pere se to ve mě, varianta B je
asi ideál, a díky tomu, že Vue uvažuji jen jako FE aplikací,
nevýhody se SEO mi nevadí.

Co mi žene krev do očí je to API. Ano, REST API v Django je
sranda, zvláště pak v tutoriálech. Ale reálně… svět je
jinde. V contextu či def serve() si udělám s daty cokoliv,
hlavně pak snadno pořídím kontextové informace a ještě v
šabloně se dá případně leccos, když je člověk pohodlný. Ale
co s Vue, pro všechno psát API? Nebo vše neustále balit do
JSON a na druhé straně rozbalovat? Na velkých projektech s
oddělením na BE a FE pohoda a dokonce i výhoda, ale u malých
projektů zcela mimo, protože s programováním komunikace
Django <-> Vue bych strávil více času než s aplikací samotnou.

Uvidím na té mé aplikaci, buď jsem něco významného přehlédl
a lze si celou integraci zjednodušit nebo prostě budu muset
zůstat u Django + AJAX a Vue řešit až po přechodu na zcela
jiný BE.

SV


On 23 February 2021 at 8:31:43, Martin Kubát
(mar.ku...@gmail.com ) wrote:


Zdravím,
ano, volba b) je v poslední době běžná. Je tam mnoho a
mnoho problémů, ale také to má své výhody:

  * čistě FE (vue, angular, react,. ...) je špatně čitelný
pro roboty (některé), je třeba řešit
server-side-rendering (firebase, ...)
  * ano, je třeba objevovat kolo hlavně z pohledu routování
url adres
  * většinou je třeba dva lidi/týmy - BE/FE.
  * nutnost udržování dokumentace API
  * FE

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Stanislav Vasko 
@jnwltr nějaký přímý odkaz na nějaké demo, ať se inspiruji? Zní mi to totiž
přesně jako řešení na tu “nudnou práci uprostřed”.

@Honza to nevypadá zle, kéž by to mělo už masovější použití

btw: možná to nic neřeší, ale není krokem “do mezi” to async řešení v
Django 3.1, už to někdo někde nasadil a podařilo se tím ušetřit nějaký ten
čas? Nebo je to jen lepší AJAX?

SV


On 23 February 2021 at 10:09:06, Honza Javorek (m...@honzajavorek.cz) wrote:

Uvažoval nebo použil někdo
https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga
generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad tím?
Existuje to dlouho a Basecamp (37signals) to používá odjakživa, teď tomu
dali akorát webovku a název, protože je štval nedostatek protiváhy k
termínům jako SPA a Jamstack.

Honza


On Tue 23. 2. 2021 at 10:02, Jan Walter  wrote:

> My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django REST
> Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj naším
> (opensource) generátorem vygenerujeme celou komunikační vrstvu na FE, čili
> tímhle netrávíme ani minutu času, v běžných scénářích je vše krásné a
> otypované (jeden model).
>
> Určitě takovou věc lze najít/mít i pro react/vue.
>
> On Tue, 23 Feb 2021, 09:41 Stanislav Vasko, 
> wrote:
>
>> Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API je v
>> Django sranda. Ale má-li mít API každý model, má-li API umět doposlat
>> kontextové informace, pak nějaké přepínače, atd. začne se to nabalovat.
>> Proto tam “remcám”, že sice to běhá a běhá to skvěle, ale všemu napsat API,
>> vše ve Vue rozbalit a nandat do správný proměnný a pak teprve psát šablonu
>> je proti Django response/request časově úplně jinde a u menších aplikací se
>> mi zdá, že budu více pracovat na API než aplikaci. Snad to píši
>> srozumitelně :)
>>
>> SV
>>
>>
>> On 23 February 2021 at 9:37:15, Jirka Vejrazka (jirka.vejra...@gmail.com)
>> wrote:
>>
>> Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe
>> bronzove delal pomoci https://www.django-rest-framework.org/ - znas?
>>
>>   Jirka
>>
>> On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
>> wrote:
>>
>>> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
>>> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>>>
>>> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
>>> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
>>> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
>>> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
>>> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
>>> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
>>> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
>>> programováním komunikace Django <-> Vue bych strávil více času než s
>>> aplikací samotnou.
>>>
>>> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si
>>> celou integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a
>>> Vue řešit až po přechodu na zcela jiný BE.
>>>
>>> SV
>>>
>>>
>>> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com)
>>> wrote:
>>>
>>> Zdravím,
>>> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů,
>>> ale také to má své výhody:
>>>
>>>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>>>(některé), je třeba řešit server-side-rendering (firebase, ...)
>>>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>>>- většinou je třeba dva lidi/týmy - BE/FE.
>>>- nutnost udržování dokumentace API
>>>- FE frameworky mají životnost jepice - od začátku psaní tohoto
>>>mailu do konce bylo určitě vydáno několik main verzí reactu, angularu, 
>>> npm
>>>a javascriptu...
>>>
>>>
>>>
>>>- znovupoužitelnost BE api je super v tom, že se může připojit jak
>>>web frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>>>strany.
>>>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>>>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>>>- na tvorbu microservis je to velmi výhodný koncept.
>>>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>>>nevěřím)
>>>- front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
>>>dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
>>>prohlížeči.
>>>
>>>
>>> Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.
>>>
>>> MK
>>>
>>> po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko <
>>> stanislav.va...@gmail.com> napsal:
>>>
 Zdravím,

 stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
 poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
 ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
 nějak k němu inklinuji, tak snad to není

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Honza Javorek 
Uvažoval nebo použil někdo
https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga
generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad tím?
Existuje to dlouho a Basecamp (37signals) to používá odjakživa, teď tomu
dali akorát webovku a název, protože je štval nedostatek protiváhy k
termínům jako SPA a Jamstack.

Honza


On Tue 23. 2. 2021 at 10:02, Jan Walter  wrote:

> My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django REST
> Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj naším
> (opensource) generátorem vygenerujeme celou komunikační vrstvu na FE, čili
> tímhle netrávíme ani minutu času, v běžných scénářích je vše krásné a
> otypované (jeden model).
>
> Určitě takovou věc lze najít/mít i pro react/vue.
>
> On Tue, 23 Feb 2021, 09:41 Stanislav Vasko, 
> wrote:
>
>> Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API je v
>> Django sranda. Ale má-li mít API každý model, má-li API umět doposlat
>> kontextové informace, pak nějaké přepínače, atd. začne se to nabalovat.
>> Proto tam “remcám”, že sice to běhá a běhá to skvěle, ale všemu napsat API,
>> vše ve Vue rozbalit a nandat do správný proměnný a pak teprve psát šablonu
>> je proti Django response/request časově úplně jinde a u menších aplikací se
>> mi zdá, že budu více pracovat na API než aplikaci. Snad to píši
>> srozumitelně :)
>>
>> SV
>>
>>
>> On 23 February 2021 at 9:37:15, Jirka Vejrazka (jirka.vejra...@gmail.com)
>> wrote:
>>
>> Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe
>> bronzove delal pomoci https://www.django-rest-framework.org/ - znas?
>>
>>   Jirka
>>
>> On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
>> wrote:
>>
>>> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
>>> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>>>
>>> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
>>> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
>>> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
>>> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
>>> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
>>> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
>>> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
>>> programováním komunikace Django <-> Vue bych strávil více času než s
>>> aplikací samotnou.
>>>
>>> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si
>>> celou integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a
>>> Vue řešit až po přechodu na zcela jiný BE.
>>>
>>> SV
>>>
>>>
>>> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com)
>>> wrote:
>>>
>>> Zdravím,
>>> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů,
>>> ale také to má své výhody:
>>>
>>>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>>>(některé), je třeba řešit server-side-rendering (firebase, ...)
>>>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>>>- většinou je třeba dva lidi/týmy - BE/FE.
>>>- nutnost udržování dokumentace API
>>>- FE frameworky mají životnost jepice - od začátku psaní tohoto
>>>mailu do konce bylo určitě vydáno několik main verzí reactu, angularu, 
>>> npm
>>>a javascriptu...
>>>
>>>
>>>
>>>- znovupoužitelnost BE api je super v tom, že se může připojit jak
>>>web frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>>>strany.
>>>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>>>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>>>- na tvorbu microservis je to velmi výhodný koncept.
>>>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>>>nevěřím)
>>>- front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
>>>dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
>>>prohlížeči.
>>>
>>>
>>> Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.
>>>
>>> MK
>>>
>>> po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko <
>>> stanislav.va...@gmail.com> napsal:
>>>
 Zdravím,

 stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
 poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
 ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
 nějak k němu inklinuji, tak snad to není špatná volba.

 Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou
 tu knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace:
 1. vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
 celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
 správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
 naopak všechno “to krásné” z Django

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Jan Walter 
My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django REST
Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj naším
(opensource) generátorem vygenerujeme celou komunikační vrstvu na FE, čili
tímhle netrávíme ani minutu času, v běžných scénářích je vše krásné a
otypované (jeden model).


Určitě takovou věc lze najít/mít i pro react/vue.

On Tue, 23 Feb 2021, 09:41 Stanislav Vasko, 
wrote:

> Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API je v
> Django sranda. Ale má-li mít API každý model, má-li API umět doposlat
> kontextové informace, pak nějaké přepínače, atd. začne se to nabalovat.
> Proto tam “remcám”, že sice to běhá a běhá to skvěle, ale všemu napsat API,
> vše ve Vue rozbalit a nandat do správný proměnný a pak teprve psát šablonu
> je proti Django response/request časově úplně jinde a u menších aplikací se
> mi zdá, že budu více pracovat na API než aplikaci. Snad to píši
> srozumitelně :)
>
> SV
>
>
> On 23 February 2021 at 9:37:15, Jirka Vejrazka (jirka.vejra...@gmail.com)
> wrote:
>
> Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe bronzove
> delal pomoci https://www.django-rest-framework.org/ - znas?
>
>   Jirka
>
> On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
> wrote:
>
>> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
>> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>>
>> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
>> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
>> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
>> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
>> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
>> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
>> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
>> programováním komunikace Django <-> Vue bych strávil více času než s
>> aplikací samotnou.
>>
>> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si
>> celou integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a
>> Vue řešit až po přechodu na zcela jiný BE.
>>
>> SV
>>
>>
>> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com) wrote:
>>
>> Zdravím,
>> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů,
>> ale také to má své výhody:
>>
>>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>>(některé), je třeba řešit server-side-rendering (firebase, ...)
>>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>>- většinou je třeba dva lidi/týmy - BE/FE.
>>- nutnost udržování dokumentace API
>>- FE frameworky mají životnost jepice - od začátku psaní tohoto mailu
>>do konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
>>javascriptu...
>>
>>
>>
>>- znovupoužitelnost BE api je super v tom, že se může připojit jak
>>web frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>>strany.
>>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>>- na tvorbu microservis je to velmi výhodný koncept.
>>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>>nevěřím)
>>- front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
>>dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
>>prohlížeči.
>>
>>
>> Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.
>>
>> MK
>>
>> po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko <
>> stanislav.va...@gmail.com> napsal:
>>
>>> Zdravím,
>>>
>>> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
>>> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
>>> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
>>> nějak k němu inklinuji, tak snad to není špatná volba.
>>>
>>> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou
>>> tu knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace:
>>> 1. vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
>>> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
>>> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
>>> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
>>> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
>>> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>>>
>>> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
>>> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
>>> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
>>> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
>>> vytvářím REST API konektory a ve Vue je

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Stanislav Vasko 
Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API je v
Django sranda. Ale má-li mít API každý model, má-li API umět doposlat
kontextové informace, pak nějaké přepínače, atd. začne se to nabalovat.
Proto tam “remcám”, že sice to běhá a běhá to skvěle, ale všemu napsat API,
vše ve Vue rozbalit a nandat do správný proměnný a pak teprve psát šablonu
je proti Django response/request časově úplně jinde a u menších aplikací se
mi zdá, že budu více pracovat na API než aplikaci. Snad to píši
srozumitelně :)

SV


On 23 February 2021 at 9:37:15, Jirka Vejrazka (jirka.vejra...@gmail.com)
wrote:

Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe bronzove
delal pomoci https://www.django-rest-framework.org/ - znas?

  Jirka

On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
wrote:

> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>
> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
> programováním komunikace Django <-> Vue bych strávil více času než s
> aplikací samotnou.
>
> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si celou
> integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a Vue
> řešit až po přechodu na zcela jiný BE.
>
> SV
>
>
> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com) wrote:
>
> Zdravím,
> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů, ale
> také to má své výhody:
>
>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>(některé), je třeba řešit server-side-rendering (firebase, ...)
>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>- většinou je třeba dva lidi/týmy - BE/FE.
>- nutnost udržování dokumentace API
>- FE frameworky mají životnost jepice - od začátku psaní tohoto mailu
>do konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
>javascriptu...
>
>
>
>- znovupoužitelnost BE api je super v tom, že se může připojit jak web
>frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>strany.
>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>- na tvorbu microservis je to velmi výhodný koncept.
>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>nevěřím)
>- front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
>dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
>prohlížeči.
>
>
> Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.
>
> MK
>
> po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko <
> stanislav.va...@gmail.com> napsal:
>
>> Zdravím,
>>
>> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
>> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
>> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
>> nějak k němu inklinuji, tak snad to není špatná volba.
>>
>> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
>> knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
>> vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
>> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
>> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
>> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
>> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
>> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>>
>> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
>> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
>> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
>> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
>> vytvářím REST API konektory a ve Vue je napojuji.
>>
>> Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
>> napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
>> nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
>> že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.
>>
>> Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
>> Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
>> nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Jirka Vejrazka 
Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe bronzove
delal pomoci https://www.django-rest-framework.org/ - znas?

  Jirka

On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
wrote:

> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>
> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
> programováním komunikace Django <-> Vue bych strávil více času než s
> aplikací samotnou.
>
> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si celou
> integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a Vue
> řešit až po přechodu na zcela jiný BE.
>
> SV
>
>
> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com) wrote:
>
> Zdravím,
> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů, ale
> také to má své výhody:
>
>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>(některé), je třeba řešit server-side-rendering (firebase, ...)
>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>- většinou je třeba dva lidi/týmy - BE/FE.
>- nutnost udržování dokumentace API
>- FE frameworky mají životnost jepice - od začátku psaní tohoto mailu
>do konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
>javascriptu...
>
>
>
>- znovupoužitelnost BE api je super v tom, že se může připojit jak web
>frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>strany.
>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>- na tvorbu microservis je to velmi výhodný koncept.
>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>nevěřím)
>- front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
>dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
>prohlížeči.
>
>
> Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.
>
> MK
>
> po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko <
> stanislav.va...@gmail.com> napsal:
>
>> Zdravím,
>>
>> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
>> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
>> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
>> nějak k němu inklinuji, tak snad to není špatná volba.
>>
>> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
>> knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
>> vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
>> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
>> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
>> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
>> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
>> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>>
>> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
>> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
>> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
>> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
>> vytvářím REST API konektory a ve Vue je napojuji.
>>
>> Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
>> napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
>> nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
>> že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.
>>
>> Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
>> Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
>> nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak když
>> už, tak pořádně.
>>
>> Hezký večer, Standa
>>
>> --
>> --
>> E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
>> Chcete-li tuto diskusi zobrazit na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com
>>

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-23 Thread Stanislav Vasko 
Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.

Co mi žene krev do očí je to API. Ano, REST API v Django je sranda, zvláště
pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def serve() si
udělám s daty cokoliv, hlavně pak snadno pořídím kontextové informace a
ještě v šabloně se dá případně leccos, když je člověk pohodlný. Ale co s
Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na druhé
straně rozbalovat? Na velkých projektech s oddělením na BE a FE pohoda a
dokonce i výhoda, ale u malých projektů zcela mimo, protože s programováním
komunikace Django <-> Vue bych strávil více času než s aplikací samotnou.

Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si celou
integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a Vue
řešit až po přechodu na zcela jiný BE.

SV


On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com) wrote:

Zdravím,
ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů, ale
také to má své výhody:

   - čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
   (některé), je třeba řešit server-side-rendering (firebase, ...)
   - ano, je třeba objevovat kolo hlavně z pohledu routování url adres
   - většinou je třeba dva lidi/týmy - BE/FE.
   - nutnost udržování dokumentace API
   - FE frameworky mají životnost jepice - od začátku psaní tohoto mailu do
   konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
   javascriptu...



   - znovupoužitelnost BE api je super v tom, že se může připojit jak web
   frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
   strany.
   - člověk se na BE nemusí starat o html/css a řeší jen databázi,
   performance, rest/graphql ... (vyhovuje teda alespoň mě)
   - na tvorbu microservis je to velmi výhodný koncept.
   - ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
   nevěřím)
   - front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
   dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
   prohlížeči.


Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.

MK

po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko 
napsal:

> Zdravím,
>
> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
> nějak k němu inklinuji, tak snad to není špatná volba.
>
> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
> knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
> vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>
> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
> vytvářím REST API konektory a ve Vue je napojuji.
>
> Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
> napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
> nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
> že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.
>
> Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
> Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
> nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak když
> už, tak pořádně.
>
> Hezký večer, Standa
>
> --
> --
> E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com
> 
> .
>
-- 
-- 
E-mailová skupina django-cs@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

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

2021-02-22 Thread Martin Kubát 
Zdravím,
ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů, ale
také to má své výhody:

   - čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
   (některé), je třeba řešit server-side-rendering (firebase, ...)
   - ano, je třeba objevovat kolo hlavně z pohledu routování url adres
   - většinou je třeba dva lidi/týmy - BE/FE.
   - nutnost udržování dokumentace API
   - FE frameworky mají životnost jepice - od začátku psaní tohoto mailu do
   konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
   javascriptu...



   - znovupoužitelnost BE api je super v tom, že se může připojit jak web
   frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
   strany.
   - člověk se na BE nemusí starat o html/css a řeší jen databázi,
   performance, rest/graphql ... (vyhovuje teda alespoň mě)
   - na tvorbu microservis je to velmi výhodný koncept.
   - ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
   nevěřím)
   - front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
   dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
   prohlížeči.


Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.

MK

po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko 
napsal:

> Zdravím,
>
> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
> nějak k němu inklinuji, tak snad to není špatná volba.
>
> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
> knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
> vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>
> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
> vytvářím REST API konektory a ve Vue je napojuji.
>
> Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
> napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
> nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
> že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.
>
> Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
> Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
> nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak když
> už, tak pořádně.
>
> Hezký večer, Standa
>
> --
> --
> E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@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+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CA%2BL8erbVf-bcvHT6m3fuFN073bL%2Bd_yFLFGCEXHxJYxaWGSAGg%40mail.gmail.com.