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

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

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

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

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

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

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

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

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

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

[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