mam pomysl na startup i zastanawiam sie jaki stack wybrac, aktualnie zastanawiam sie miedzy django + htmx a phoenix/liveview; plusem django jest to ze ogarniam pythona na poziomie umiarkowanym a elixira wcale, plusem phoenix/liveview to ze podobno duzo szybsze (co moze byc decydujace, serwis bedzie mial bardzo duzy traffic - w koncu będzie to klon strimoida)
@strimsVEVO: nieee bierz django. tzn jak to maly projekcik to wyjebane, bo masz tam w sumie wszystko zrobione, ale duzo jakichs zjebanych antypatternow tam jest (nwm jakich bo powtarzam to co slyszalem xD ale chyba zle MVC jest tam ogarniety bo cala logika ląduje w modelach zazwyczaj i pozniej masz patologie typu pliki po 20k linii (wlasnie taki plik dzisiaj edytowalem szubienica.jpg)).
duzo osob decyduje sie teraz na fastapi, bo w przeciwienstwie do django nie masz calego zajebanego loadu niepotrzebnych rzeczy (kto w 2022 bedzie uzywal templatek...), gdzie rzeczy potrzebne (rest framework) i tak musisz doinstalowac z boku xD a fastapi logowanie i rejestracje ma i cale API ogarniete, wiec jesli planujesz zroibc rzecz w stylu front w jakims reactcie, ktory sie komunikuje po API no to fastapi jest sensowne. chociaz chyba w takiim wypadku wiecej ludzi sie na jakiegos node.js decyduje, ale to juz ja sie na tym nie znam
@ajdajzler: ja tam w DRF klepię już drugi projekt, zresztą w robocie też używamy do backendu i jest spoko
plik po 20k linii to nie jest wada django tylko zjeba, który nie potrafi podzielić god objectu na mniejsze jednostki XD
fastapi logowanie i rejestracje ma i cale API ogarniete
tak jak django + w django masz ofc ten słynny panel admina ootb, nie bd się wypowiadał nt fastapi bo nie używałem
god objectu
nwm ja tam jestem juniorkiem dopiero w django, ale troche srednio jestem w stanie sobie wyobrazic oddzielenie np modelu faktury na inne mniejsze w kodzie firmy dla ktorej robie. ostatnio bylismy na konferencji django i generalnei to jest bardzo popularny problem, na ktory ciezko znalezc rozwiazanie. typ polecal nie wrzucac logiki do modelu tylko zrobic sobie plik w stylu use_case.py (albo inne dodatkowe pliki do helperow) i tam wrzucac logike, ale idk idk, nie potrafie tak ocenic
a probowales pisac w fastapi? ja nie xD ale kazdy z kim gadam o django mowi mi od razu ze nie zaczynalby teraz projektu w django tylko w fastapi, bo to bez sensu w dobie kiedy frony pisze sie konsumując jakieś api (i guess dawniej ten rozwiniety system templatow mial na pewno duze zalety, ale teraz to lepiej wystawic endpoint po API i najbeac na to react, przy okazji nikt sobie w stope nie strzeli przy tych templatkach zajebancyh, ile ja reopenow zroiblem ze sie gdzies None printuje to nie zlicze Xd)
@ajdajzler: nie wiem, musiałbym zobaczyć, co w tym modelu jest, ale u mnie model faktury ma jakieś ~30 linii łącznie z generowaniem pdfa xD
co do templatek to przecież już nikt nie pisze w ten sposób. Wiadomo, DRF na twarz i pchasz dżejsony do dżawaskryptów. Spojrzę sobie w wolnym czasie na to fast api i wyrobię sobie zdanie
~30 linii łącznie z generowaniem pdfa xD
no to u nas jeszcze generowanie pdfów jest na pythonie 2 na awsowej lambdzie sprzed 8 lat bo kazdy sie boi dotykac XD ale to tak nawiasem mowie, generalnie mamy np z conajmniej 30 różnych partnerow zewnetrznych i dla kazdego jest jakas osobna logika (ten chce fakture w xml, ten chce zeby mu inne maile wysylac, ten chce zeby wysylac faktury placone credit carda na jeden mail, a te placone faktura na inny xd, jeszcze w chuj logiki ze wzgledu na rozne cost center, rozne vaty, różne typy faktur (za anulowanie, za modyfikacje, jakies dodatkowe fee), mysle ze nawet 5% featurow ci nie wymienilem) no burdel straszny i jak masz 10-cio letni kod to juz nikomu sie tego nie chce tak rewolucyjnie sprzatac, tylko po troche metoda po metodzie (a to i tak rzadko). no w kadym razie legacy mocne, ale to tez nie jest wina samych programistow - taki jest po prostu design django, ze ludzie intuicyjnie wpierdalaja logike do modelu czy cos i te pliki rosną, jeśli ktoś specjalnie o to nie zadba żeby tego pilnować (sama architektura django do tego zachęca)
w sumie nawet bylbym w stanie ci na priv jakis jeden plik kodu wyslac, bo i tak jest bezwartosciowy i gowno z niego zrozumiesz xd
@ajdajzler: co do logiki w Django - ten post moim zdaniem proponuje sporo baardzo dobrych rozwiazan https://alexkrupp.typepad.com/sensemaking/2021/06/django-for-startup-founders-a-better-software-architecture-for-saas-startups-and-consumer-apps.html#footnote-1
@ajdajzler: a no to widzisz, legacy, dług techniczny najebany lepiej niż publiczny xd
Racja, że klasycznie w Django wszystko się wpierdalalo w model, ale obecnie jak masz jeszcze warstwę REST powyżej z serializerami viewsetami i walidatorami i delegujesz zadania do asynchronicznych taskow w jakimś DjangoQ czy innym kurwa celery to rodzi to szerokie pole do sensownego poukładania kodu
A wyślij, chętnie popatrzę xd
@strimsVEVO: jak masz pomysl to imo im szybciej wypuscisz tym lepiej, więc używaj tego, co już trochę umiesz. Testy na produkcji dają szybki i cenny feedback od userow. Jak zażre to dopiero potem się będziesz martwił o szybkość. Dostaniesz hajs od inwestorów to będziesz mógł zatrudnić zespół kuców którzy ci to przekucuja na jakąś Javę czy inne coś.
Potem się czyta w necie historie jak to ktoś zwlekał z wypuszczeniem i w końcu ktoś go ubiegł. Takie jest moje zdanie skromne
Racja, że klasycznie w Django wszystko się wpierdalalo w model, ale obecnie jak masz jeszcze warstwę REST powyżej z serializerami viewsetami i walidatorami i delegujesz zadania do asynchronicznych taskow w jakimś DjangoQ czy innym kurwa celery to rodzi to szerokie pole do sensownego poukładania kodu
ale to wszystko u nas jest. co prawda kod jest mocno legacy, ale jest duzo mnuej lub bardziej nowoczesnych praktyk, tylko imo przy takiej skali i historii to nie da sie* tego sensownie ogarnac, za duzo jest wszystkiego
*nie da sie, ze wzgledu na to ze nie ma uzasadnienia biznesowego, w sensie to sie nie oplaca finansowo