Použití Python Flask v komerční sféře

[alexfa]

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

[Reklama]

[gill]

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

vykon aplikace je omezen databazi. je jedno jestli cekani na vysledek dotazu blokuje aplikacni proces, protoze databaze by stejne vic nezvladla.

[Idris]

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

vykon aplikace je omezen databazi. je jedno jestli cekani na vysledek dotazu blokuje aplikacni proces, protoze databaze by stejne vic nezvladla.

Alexfa má pravdu, zřejmě absolutně nechápeš async IO, potažmo korutiny. Už se tu neztrapňuj

[nula]

Ako napisal gill, taky hello world do prehliadaca je tusim na 3 riadky kodu. Zaklad Flask-u sa da pochopit za jeden den, mozno potom este chvilku trva, kym clovek dobre pochopi kontexty a pracu s nimi (Application context, Request context), ale je to naozaj jednoduche. Sqlalchemy sa s Flaskom moze, ale nemusi pouzivat, ale stoji za to s nim vediet pracovat. Dnes si uz neviem predstavit zlozitejsiu databazovu aplikaciu bez tohoto ORM.

Naopak orm se hodi na nejake primitivni weby, nedokazu si predstavit slozitejsi databazovou aplikaci s orm. To proste nikdy nefunguje. Par takovych zoufalych firem znam co to zkusilo, pak jsou radi, ze jsou schopni zaplatit nekoho, kdo je z toho bordelu vyseka.

[Wavelet]

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

vykon aplikace je omezen databazi. je jedno jestli cekani na vysledek dotazu blokuje aplikacni proces, protoze databaze by stejne vic nezvladla.

Já se async v Pythonu zatím vyhýbám, kde můžu, ale proč by pak někdo dělal asynchronní knihovnu jako tato:
https://github.com/MagicStack/asyncpg ?

[Reklama]

[Wavelet]

Ako napisal gill, taky hello world do prehliadaca je tusim na 3 riadky kodu. Zaklad Flask-u sa da pochopit za jeden den, mozno potom este chvilku trva, kym clovek dobre pochopi kontexty a pracu s nimi (Application context, Request context), ale je to naozaj jednoduche. Sqlalchemy sa s Flaskom moze, ale nemusi pouzivat, ale stoji za to s nim vediet pracovat. Dnes si uz neviem predstavit zlozitejsiu databazovu aplikaciu bez tohoto ORM.

Naopak orm se hodi na nejake primitivni weby, nedokazu si predstavit slozitejsi databazovou aplikaci s orm. To proste nikdy nefunguje. Par takovych zoufalych firem znam co to zkusilo, pak jsou radi, ze jsou schopni zaplatit nekoho, kdo je z toho bordelu vyseka.

Moje řeč.

[gill]

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

vykon aplikace je omezen databazi. je jedno jestli cekani na vysledek dotazu blokuje aplikacni proces, protoze databaze by stejne vic nezvladla.

Já se async v Pythonu zatím vyhýbám, kde můžu, ale proč by pak někdo dělal asynchronní knihovnu jako tato:
https://github.com/MagicStack/asyncpg ?

pro přístup do databáze z asynchronních aplikací, u kterých by čekání na výsledek zablokovalo smyčku událostí, které jsou ale asynchronní z jiného důvodu, většinou kvůli socketové komunikaci. Ta knihovna stejně používá connection pool s defaultní velikostí 10.

[alexfa]

Ako napisal gill, taky hello world do prehliadaca je tusim na 3 riadky kodu. Zaklad Flask-u sa da pochopit za jeden den, mozno potom este chvilku trva, kym clovek dobre pochopi kontexty a pracu s nimi (Application context, Request context), ale je to naozaj jednoduche. Sqlalchemy sa s Flaskom moze, ale nemusi pouzivat, ale stoji za to s nim vediet pracovat. Dnes si uz neviem predstavit zlozitejsiu databazovu aplikaciu bez tohoto ORM.

Naopak orm se hodi na nejake primitivni weby, nedokazu si predstavit slozitejsi databazovou aplikaci s orm. To proste nikdy nefunguje. Par takovych zoufalych firem znam co to zkusilo, pak jsou radi, ze jsou schopni zaplatit nekoho, kdo je z toho bordelu vyseka.

No, uz jsem tady byl za kacire v jednom tematu, tak budu i v tomhle: ORM je iluze, ktera na zacatku vypada, jako dobry napad a na konci je to katastrofa ... bez vyjimky - a pisu to z vlastni zkusenosti, psal jsem vlastni ORM 2 roky.
Duvod, ktery to zpusobuje, je fakt, ze objektovy a relacni model nemaji 1:1 preklad. Je to jako preklad mezi anglictinou a cinstinou. Kdyz se to vezme slovo od slova, tak to "tak nejak" bude fungovat, ale drive ci pozdeji narazite na to, ze to nejde automaticky a musite mit nejakeho prekladatele, ktery chape vyssi vyznam (tj. sikovneho programatora).

Hodne lidi/firem nerozumi tomu, ze vetsina uloh, ktere resi ve svem software NENI relacni problem.
A presto si jako svoji databazi zvoli SQL ... protoze se to tak dela. Misto racionalni uvahy, jaka databaze je vhodna pro reseni konkretniho problemu, se automaticky saha po SQL. Kdysi jsem cetl zajimavou uvahu o tom, ze volba SQL do aplikace je necastejsi architektonicka chyba dnesni doby (single biggest mistake of software architecture).
Aby se tomu nasadila koruna, tak se obratem saha po ORM (object-to-relation mapper), coz je vlastne narovnavak na ohybak chybne vybraneho storage schematu.
Vyvijena aplikace nakoupi zeleznou kouli hned prvni den a vyvojari jsou zpomalovani prelezanim objektovo/relacni linie uprostred aplikace (aka prekladanim svych konceptu z anglictiny do cinstiny a zpet).

Volte takove databaze, ktere jsou vhodne pro vase problemy.
Pokud to nedokazete odhadnout, tak vezte, ze vas problem je objektovy, takze potrebujete objektovou databazi.
A ne, nedaji se v ni delat joiny, stejne tak, jako nedelate joiny se svymi objekty :-)

[alexfa]

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

vykon aplikace je omezen databazi. je jedno jestli cekani na vysledek dotazu blokuje aplikacni proces, protoze databaze by stejne vic nezvladla.

Já se async v Pythonu zatím vyhýbám, kde můžu, ale proč by pak někdo dělal asynchronní knihovnu jako tato:
https://github.com/MagicStack/asyncpg ?

https://github.com/aio-libs ... tohle je soubor relativne dobre vyzralych asyncio knihoven (vcetne postgres).

[Ink]

Volte takove databaze, ktere jsou vhodne pro vase problemy.
Pokud to nedokazete odhadnout, tak vezte, ze vas problem je objektovy, takze potrebujete objektovou databazi.
A ne, nedaji se v ni delat joiny, stejne tak, jako nedelate joiny se svymi objekty :-)

No já bych spíš řekl, že OOP je v mnoha případech ten hlavní problém a ne řešení.