7.6 KiB
logging: absolutnie żadnego kurwa slf4j, logging robimy przez scribe z bindingiem scribe dla slf4j, absolutnie wykurwisty performance, konfigurowalność w kodzie zamiast w gównoxmlu, brak chorych reguł resolve'owania konfiguracji, just works
caching ok
config: hocon, owszem, ale przez moją bibliotekę do konfiguracji: https://github.com/lbialy/jig główny argument jest taki, że obsługuje reading & writing, łącznie z komentarzami, zdecydowanie poprawi nam temat discoverability i zrozumienia konfiguracji dla llmów, mam nad tym 100% kontroli też co jest winem bo możemy dodawać ficzury jakie potrzebujemy
json: wyłącznie jsoniter-scala, jedyna libka która nie jest niedojebana, możliwe że będziemy musieli zrobić swój wrapper na nią, pracowałem nad nim i dotarłem do jakichś 75% done, autor jest WYBITNYM akustykiem, to najszybsza libka do jsonów na JVMie bo gość chodzi i sprawdza jakie instrukcje dla cpu wypluł jvm i odcina od tego
hashing: tu sytuacja jest względnie prosta, to co jest w jdk jest z reguły good enough, jak performance jest konieczny to bouncy castle przez jni
email: tu z kolei sytuacja jest trudna, dla emaili najważniejsze to jest mieć dobry interfejs i wiele bindingów, w tym najważniejsze pewnie to AWSowy sender itp, jakarta email to trochę legacy shitlib, nie wiem czy jest sens się bić z nią, to javowy soft i ma javowe failure modes, emaile są zbyt istotne żeby się martwić dziwnymi nullpointerexception z gównokodu
admin frontend to nie moja działka natomiast w pełni się zgadzam z generowaniem bindingów do TSa z tapirowych definicji endpointów, co więcej robiłem to już i mam do tego szablon
możemy mieć 1:1 do api i wykrywanie dryfu, projekt rnd który aktualnie wciąż prowadzę (Yaga latająca na Besom) to dosłownie to - statyczna weryfikacja że usługi się ze sobą zepną poprawnie po deploymencie, mam know how jak to zrobić zarówno w fast dev loop jak i w gwarantowanych deploymentach)
template engine to jak faktycznie chcesz zachować Twiga to pebble nie jest zły, do Scalate bym się nie zbliżał bo to japoński abandonware, ile razy wchodzę w interakcje z tamtą stroną community, jest to dziwne, to jak rozmowy z peonami w fel hordzie, robią rzeczy ale no jak bici niewolnicy
japońska scala to ogólnie strasznie dziwny świat, ludzie tam są dosłownie zerg drones w korpo
pebble by zachował Ci to co znasz plus potencjalnie możliwość reloadowania bez rebuildów aplikacji ale to jest do zbadania, pebble jako wtyczka do springa ma swoje java enterprise idiosynkrazje - np szuka szablonów na classpath resources path
jak już wspominałem to nie jest optymalne bo classpath jest statyczny bez osgi więc musiałbyś restartować usługę, kosztowne w devloop, można iść pogadać z perplexity albo nawet https://deepwiki.com/PebbleTemplates/pebble
i zapytać czy możemy go używać jako file-based templating system i czy jak ładuje z plików to może robić hot reloady
jak nie może to możemy my zrobić autoreloading na watcherze plików i przeładowywać cały system szablonów na zmianie w plikach
cli: absolutnie i w żadnym wypadku nie ładujemy się ani w scopta (śmietnik, dużo głupich założeń, daleko od best practices) ani w decline (bardzo złożone, ekstremalnie elastyczne funkcyjne gówno, fajne, bardzo je lubię i jakbym miał robić naprawdę pogięte CLI to pewnie best choice ale LLMy się pojebią w tym jak używać tej mocy), użyjemy case-app od alexa archambault, alex jest ziomkiem, to francuski akustyk, dogadalibyście się Kuba (pomijając to że nie da się zrozumieć co mówi przez ciężki francuski akcent) bo to typ od getting shit done HOWEVER, oryginalny autor scala-cli, najebał tak dużo ficzurów że Piotrek, który to maintainuje ma trochę lipton
case-app generuje automatycznie helpa, dostajesz parsowane case classy
bardzo bardzo ładne narzędzie, z czasem pokochałem je całym serduszkiem
co do testów - munit, żadnego scalatest, scalatest jest wiecznym generatorem migren dla nas, jego autorzy to leśne dziadki robiące absolutnie koszmarne rzeczy w buildzie, nie ufam tej bibliotece już w ogóle, rugpullowali nas regularnie
ostatni rugpull to to że wydanie tej samej wersji dla scali-jvm i scali-native zawiera inne symbole w paczce bo mają jakieś kurwa build macros wykluczajace subpaczki które się im nie kompilują
ffs zamiast naprawić wyjebują chirurgicznie części libki i na jednej platformie coś działa, a na innej dostajesz linkage errors
dzbany
co do testów to tu jest trochę otwartej przestrzeni żeby zrobić rzeczy naprawdę dobrze, ja jestem zdecydowanym zwolennikiem testowania integracyjnie z LLMami
do tego używa się dużo testcontainers-scala
przykładowo testy na postgresa to absolutnie must
co do jeszcze http
on tam kombinuje z jakims summer-surf pod temat http
ale my mamy temat http ogarnięty fantastycznie w stacku vl/sml
tapir jest biblioteką do endpointów zbudowaną na wspólnym DSLu do http libki klienckiej http która się nazywa sttp
sttp będzie naszym klientem http na 200% bo to najlepsza rzecz na naszym rynku
sttp i tapir ogarniają sesje, cookies, streaming, http auth
ale nie ogarniają jwt, jwt to osobny temat, w ostatnim projekcie komercyjnym (kotlin) pisałem jwt, nie ma w scali aktualnie dobrego rozwiązania do jwt ale to co używaliśmy w springu było good enough, myślę że możemy to bezpiecznie wpieprzyć
11:17
co do tego:
SLF4J is already a logging facade. Wrapping a facade with another facade adds zero value. Just use SLF4J + Logback directly. Direct SLF4J usage to mogę tylko powiedzieć że to jest taka rada jakby Ci kolega powiedział "jasne, będziemy wbijać sobie w chuja gwoździe, wszyscy tak robią, to jest proste, po prostu będziemy wbijać w chuja gwoździe. bezpośrednio"
no i zostaje temat summer-lagoon
tu jest kurwa pole do popisu i moim zdaniem to jest showstopper
problem jest taki, w javie i php jesteś przyzwyczajony do flow:
$user = User::findByName("ten jebany retard"); $user->firstName = "Raziel"; $user->save(); w javie to działa ciut inaczej (jak Doctrine w Symfony)
co oznacza generalnie że piszesz coś takiego:
@Transactional HttpResponse onPostTwojaStara(HttpRequest req) { User user = UserRepository.findByName(req.body.name); user.setFirstName("Raziel"); return HttpResponse.success(); } tutaj @Transactional otwiera Unit of Work, ono śledzi mutacje na encji i na zamknięciu tej metody generuje UPDATE'y i wpierdala je w transakcji do bazy
ale ani tamto pierwsze ani tamto drugie nie zadziała w Scali
nie zadziała bo w Scali nie mutujemy pól na klasach
to robi dużo dziwnych problemów
przykładowo relacje w php w Eloquent są dynamicznymi metodami i dynamicznymi mutowalnymi polami
relacje będą najtrudniejsze do zamodelowania
same zmiany na pojedyńczych encjach są proste
transact: val user = UserRepo.findByName("ten jebany retard") UserRepo.save(user.copy(firstName = "Raziel"))
260 11:24 ale w scali da sie chyba User.findByName("Raziel").update(firstName = "raziel").save()
lucas 11:25 nie bo nie możesz save wjebać na case classa chyba że zrobisz to jako głupi proxy method na implicit repo
Nowe Wiadomości w sensie w Eloquent na klasie Model jest statyczne pole $dbEngine czy jakoś tak
i przy boocie frameworka cała hierarchia klas Model dostaje ustawiony wstrzyknięty silnik skonfigurowany do bazy danych
konstruktor Model robi dużo dziwnej magii żeby zachować tę relację poprawną i dlatego możesz zawołać $user->save()
260 11:26 przyklad dobralem zeby byl jak najbardziej phpowy, save w takiej formie musialby byc extensionem i using UserRepo pewnie. Opcja save na repo tak jak podales wyzej IMO spoko, te copy robi update ladnie