Django + Vue = VL? Nebo je to úplně jinak?

[Stanislav Vasko]

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

[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 <stanisl...@gmail.com> napsal:

--
--
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/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com.

[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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2BL8erbVf-bcvHT6m3fuFN073bL%2Bd_yFLFGCEXHxJYxaWGSAGg%40mail.gmail.com.

[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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMD1ck98xeFwf74EQqTjXNG9gJ9zmZJMBZDazMsh85AmpjyWZw%40mail.gmail.com.

[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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAFhEBECoVPmVyYX8b%3D2QxO3Gw7_ee_-y6nu7OiCbW%2B9Pw-jz1A%40mail.gmail.com.

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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMD1ck-PqaSB6vmEmcVTA8WOvfeYgMFaY0r8BhQqEOGY6iRGyw%40mail.gmail.com.

[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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAK-vJU%3DYbBULaHzREQ%2BBa-a1MLcUK%2BOsNYRP-K4gp8RA2fWEQQ%40mail.gmail.com.

[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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAPAmg-f%2Bv%3DYWsziS%2ByxsFs2zXc4LrkeVL0j_AKWr3AnhF7A1gQ%40mail.gmail.com.

[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 <jnw...@gmail.com

> <mailto:jnw...@gmail.com>> 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,
> <stanisl...@gmail.com <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 č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.v...@gmail.com <mailto:jirka.v...@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

>> <stanisl...@gmail.com <mailto:stanisl...@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....@gmail.com <mailto:mar....@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
>>> <stanisl...@gmail.com

>>> <mailto:stanisl...@gmail.com>> napsal:

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

>>> <mailto:django-cs+...@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

>>> <https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>>
>>> --
>>> --
>>> E-mailová skupina djan...@googlegroups.com

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

>>> <mailto:django-cs+...@googlegroups.com>.

>>> Chcete-li tuto diskusi zobrazit na webu, navštivte

>>> https://groups.google.com/d/msgid/django-cs/CA%2BL8erbVf-bcvHT6m3fuFN073bL%2Bd_yFLFGCEXHxJYxaWGSAGg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-cs/CA%2BL8erbVf-bcvHT6m3fuFN073bL%2Bd_yFLFGCEXHxJYxaWGSAGg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>> --
>> --
>> E-mailová skupina djan...@googlegroups.com

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

>> <mailto:django-cs+...@googlegroups.com>.

>> Chcete-li tuto diskusi zobrazit na webu, navštivte

>> https://groups.google.com/d/msgid/django-cs/CAMD1ck98xeFwf74EQqTjXNG9gJ9zmZJMBZDazMsh85AmpjyWZw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-cs/CAMD1ck98xeFwf74EQqTjXNG9gJ9zmZJMBZDazMsh85AmpjyWZw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> --
>> E-mailová skupina djan...@googlegroups.com

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

>> <mailto:django-cs+...@googlegroups.com>.

>> Chcete-li tuto diskusi zobrazit na webu, navštivte

>> https://groups.google.com/d/msgid/django-cs/CAFhEBECoVPmVyYX8b%3D2QxO3Gw7_ee_-y6nu7OiCbW%2B9Pw-jz1A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-cs/CAFhEBECoVPmVyYX8b%3D2QxO3Gw7_ee_-y6nu7OiCbW%2B9Pw-jz1A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> --
> --
> E-mailová skupina djan...@googlegroups.com

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

> <mailto:django-cs+...@googlegroups.com>.

> Chcete-li tuto diskusi zobrazit na webu, navštivte

> https://groups.google.com/d/msgid/django-cs/CAMD1ck-PqaSB6vmEmcVTA8WOvfeYgMFaY0r8BhQqEOGY6iRGyw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-cs/CAMD1ck-PqaSB6vmEmcVTA8WOvfeYgMFaY0r8BhQqEOGY6iRGyw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> --
> E-mailová skupina djan...@googlegroups.com

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

> <mailto:django-cs+...@googlegroups.com>.

> Chcete-li tuto diskusi zobrazit na webu, navštivte

> https://groups.google.com/d/msgid/django-cs/CAK-vJU%3DYbBULaHzREQ%2BBa-a1MLcUK%2BOsNYRP-K4gp8RA2fWEQQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-cs/CAK-vJU%3DYbBULaHzREQ%2BBa-a1MLcUK%2BOsNYRP-K4gp8RA2fWEQQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

> <mailto:django-cs+...@googlegroups.com>.

> Chcete-li tuto diskusi zobrazit na webu, navštivte

> https://groups.google.com/d/msgid/django-cs/CAPAmg-f%2Bv%3DYWsziS%2ByxsFs2zXc4LrkeVL0j_AKWr3AnhF7A1gQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-cs/CAPAmg-f%2Bv%3DYWsziS%2ByxsFs2zXc4LrkeVL0j_AKWr3AnhF7A1gQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[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

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 zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/79cbfeb3-c639-5286-536d-9d04d4418261%40sandbox.cz.

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

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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/84afbade-b76a-406e-874d-3b6399a3c7a2n%40googlegroups.com.

[Petr Messner]

út 23. 2. 2021 v 12:03 odesílatel Honza Javorek <ma...@honzajavorek.cz> 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. 

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. 

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. 

[Honza Javorek]

On Wed 24. 2. 2021 at 12:45, Petr Messner <petr.m...@gmail.com> wrote:

út 23. 2. 2021 v 12:03 odesílatel Honza Javorek <ma...@honzajavorek.cz> 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

[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

[Petr Messner]

st 24. 2. 2021 v 13:15 odesílatel Honza Javorek <ma...@honzajavorek.cz> 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.

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

[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 <mirek....@gmail.com> napsal:

--

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

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