[Khaine]

#programowanie #csharp #webdev

Żeby położyć dobry fundament pod uniwersalne i skalowalne API potrzeba tyle roboty, że ja #!$%@?ę ( ͡° ʖ̯ ͡°) Mówię bez kontrolerów jeszcze nawet, same meta-flaki które będą te kontrolery potem odpowiednio we wszystkim wspomagać, odpowiednie rozdzielenie architektury, zaprojektowanie podstawowej struktury bazy danych, logowania, autoryzacji, autentykacji, obsługi błędów itd.

Pod tym względem chyba wolę desktopy, bo dużo mniej gnojowicy trzeba odgarnąć zanim zrobi się cokolwiek xD Aczkolwiek zwykle pewnie robi to kilka osób a nie jedna jak teraz w sumie ¯\_(ツ)_/¯

[pitu120]

@Khaine: nie piszę w csharp ale na pewno nie mają czegoś gotowego pod API? Np. to: https://docs.microsoft.com/pl-pl/aspnet/web-api/overview/older-versions/build-restful-apis-with-aspnet-web-api ?

[C.....y]

@Khaine: jak wymyślasz koło na nowo to tak, może masz rację, ale to o czym piszesz jest robione od dwucyfrowej liczby lat i jest tyle gotowców że po prostu robisz sobie pod górkę, możesz sobie wybierać do woli i na pewno ktoś już zaimplementował w sposób wystarczający to czego szukasz

Pułapka perfekcjonizmu "zawsze może być lepiej" to prosta droga do overengineeringu i zapętlenia się we własnej głupocie, trust me

[Khaine]

@pitu120: Mają, ale nie wszystkie mechaniki mi odpowiadały i musiałem rzeźbić swoje. Przykładowo aby defaultowo zwracało taki a nie inny error z serwera z taką a nie inną wiadomością. Autoryzacja była zrobiona ok, natomiast dodanie dwóch warstw customowej autoryzacji już też wymagało sporo zabawy.

Przykładowo .NET Core ci zapewnia albo autoryzację opartą o role, albo autoryzację opartą o claimy czyli permissiony poszczególne i o ile role są wygodne gdy wiesz,

[Khaine]

jak wymyślasz koło na nowo to tak

@Czarzy: No właśnie nie wymyślam koła na nowo patrząc po tym co znajduję w internetach. Robię coś czego framework mi nie zapewnia out-of-the-box, a chciałbym to mieć, bo nadmiernie uproszczone defaulty w przyszłości mogą odbić się czkawką jak właśnie sranie milionem ról - przykład oczywiście z życia, bo sztywne role już się odbiły czkawką w poprzednim projekcie i śmierdzą do tej pory -

[C.....y]

@Khaine: claimy w core są przedmiotem kontrowersji od dawna i to jest w sumie wyjątek od reguły którego nie ująłeś we wpisie a dopiero w komentarzu ( ͡° ͜ʖ ͡°) Wielu tęskni za prostym mechanizmem sesji znanym z choćby zwyklakowego .NETowego MVC, wystarczy poczytać stacka albo inne artykuły które zresztą mierząc się z problemem na pewno znasz

Ale errory można sobie ustawić choćby na poziomie walidacji,

[Khaine]

@Czarzy: No właśnie claimy mi śmierdziały, role były za sztywne, więc zrobiłem po swojemu. Same claimy są spoko, tylko są nadmiernie sprymityzowane w chwili obecnej a ich walidacja poprzez te policies (co, milion polityk autoryzacji?) to są jakieś jaja jeśli nie zastosujemy myku z DefaultAuthorizationPolicyProvider. Nawet zresztą nie ładuję ich w token poza podstawowymi jak userId czy userName, tylko sprawdzam je po stronie backendu z możliwością odesłania przez API całej

[Yahoo_]

@Khaine stary, ale tak czytam Twoje wpisy to Wy tam znajdujecie powód, żeby przepisać dosłownie każdy middleware jakiego normalnie się używa :p. W tym tempie za dwa lata kompilator będziecie przepisywać, bo coś Wam nie będzie pasować :p

[Khaine]

żeby przepisać dosłownie każdy middleware jakiego normalnie się używa

@Yahoo_: A skąd, masa rzeczy chodzi na defaultach (z biegiem czasu raczej znakomita większość będzie) z ewentualnie drobnym tweakiem. Ale nie powiesz mi chyba, że autoryzacja bazowana TYLKO na rolach albo TYLKO na claimach dobrze się sprawi w przypadku gdy chcielibyśmy mieć maksymalnie uniwersalną podstawkę na której można budować kolejne rzeczy, które potencjalnie mogą być bardzo duże? Ja już byłem, widziałem

[Koliat]

@Khaine: czy mi się wydaje czy probujecie zbudować własne api management? Nie łatwiej zainwestować w coś w rodzaju apigee?

[Khaine]

@Koliat: To jest jak próba rozgniecenia muchy walcem. Potrzebujemy po prostu bazy do EWENTUALNEGO budowania różnych API na niej później.

Poprzednio było tak, że robiło się forka starego produkcyjnego trupa, do niego dosrywało się trochę kodu a resztę zostawiało "bo nie wiadomo czy się nie #!$%@?" i powstawał taki gównozlep. I takich gównozlepów w tej chwili jest już 4 z czego nie każdy jest już nawet forkiem tego pierwszego, więc

[Yahoo_]

@Khaine nie wiem, nie znam wymagań, generalnie jako developer chcesz się skupiać się na tym co przyniesie biznesowi wartość. Ostatnio chciałeś pisać własny logger, teraz autoryzacja. Z mojego doświadczenia wynika, że jeśli czegoś nie mogę zrobić w frameworku to albo robię to źle, albo twórcy z premedytacją nie pozwalają na takie rozwiązanie, bo uważają je za złe. Dużo rzadziej trafiają się dziury, których ktoś nie przewidział i mają one sens. Zwykle

[Khaine]

YAGNI

@Yahoo_: YAGNI już robili chłopaki nie myśląc na krok do przodu aby nie tyle zrobić coś "na kiedyś", a zostawić miejsce na zrobienie czegoś później (co de facto chcę osiągnąć - nie pisać rzeczy których może ktoś kiedyś użyje, ale tak zrobić aby mógł je w przyszłości dodać i nie pocić się przy tym jak saper). Nie zrobili YAGNI tylko jakieś JTKBSM -> #!$%@?ć To Kiedyś Będziemy Się Martwić. I oni się już nie martwią bo jak zobaczyli co #!$%@? to uciekli z firmy a ja teraz muszę ten paździerz oglądać.

Efektem było obchodzenie naokoło starych, zalanych betonem rozwiązań aby mogły działać nowe a na pisanie nowego systemu oczywiście nikt czasu nie dał, więc aby chociaż trochę sobie tego czasu przyoszczędzić robili forki tych truposzy aby przynajmniej część rzeczy mieć już zrobionych - np. właśnie logowanie i

[Goglez]

autentykacji

@Khaine: Nie ma takiego słowa (nawet przeglądarka podkreśla błąd!). Jest "uwierzytelnianie".