Když jsem nějakou z nich potřeboval, tak jsem se ji naučil velice rychle.
Presne o tomto hovorim...9/10 ludi neovlada poriadne JPA, nerozumeju rozdielu medzi @OneToMany a @ManyToOne a preco by mali uprednostnovat Lazy fetch pre Eagerom (resp. eager maximalne v @OneToOne inak nikdy !!!!). Rovnako nevedia dedit v JPA, nevedia, co je Entity graph (bleee) a preco je nutny, nerozumeju ani N+1 problemom, myslia si,ze daju em.persist a to staci a uz vobec nie, ako to cele debugovat a ladit... a co takto nad to postavit QueryDSL alebo JOOQ ?
Pozriet si nejake Baeldung tutorialy nie je skutocne vsetko.
A že by se někdo musel naučit hned všechny, aby mohl dělat v Javě, to asi nebudeš tvrdit ani ty?
Urcite nie, ale rovnako nebudem niekoho presviecat, ze naucit sa Spring (Spring Boot) a jeho projektom je vec na par dni...rukou mi preslo niekolko vyvojarov a trva to niekedy aj roky....ono to je aj o tom, aby clovek rozumel ako to v tom Springu aj funguje (pozdravujem magic autoconfigure beany a @ConditionalOnXYZ anotacie) ked uz riesi, preco nieco debuguje.
Na druhou stranu u spoustu těch Spring knihoven moc ani nechápu smysl - proč používat Spring Rabbit, když je to zhruba stejně složitý jako použít ten Rabbit přímo...
Uplne vsetko nema zmysel...na druhu stranu si neviem predstavit implementovat rucne veci napr. z cloud starterov - OpenTelemetri, Zipkin, Sleuth tracovanie, napojenie na Vault, Discovery server, Broker alebo taku blbost ako bootstrap.yaml tahaneho z nejakeho remote umiestnenia (konfig server, git, ...)....
Ono to vsetko zacne davat zmysel - pretoze medzi jednotlivymi projektami je velka synergia - priklad Actuator, ktory zazracne funguje podla toho, co zo springu pouzivate.... Sleuth, ktory "zazracne" funguje, ked detekuje dalsie Spring projekty na classpathe (JDBC tranzakcie, P6Spy, Scheduled, AMQP listenery, ...).
Prave podla toho sa pozna senior a skuseny technolog, ktory si uvedomuje, preco to cele ma zmysel takto postavit....
Ale je pravda, nie uplne vsetko je potrebne....zrovna ten spominany
Spring AMQP je hodne uzitocny....
Vysvetlim preco...
Jednak je to, ze ponuka abstrakciu (rovnaky sposob ako sa s tym bude pracovat) pre rozne messaging technologie - od AMQP po Kafku (rozdiel je len v tom... ze sa vola jeden @RabbitListener a druhy @KafkaListener)....
Ale to najdolezitejsie ... je to HIGH LEVEL zapuzdrenie --- a tu pozor ... tu je ten rozdiel medzi tutorialmi z Baeldungu.... viete si predstavit, ze si rucne v low level Rabbit kniznici budete implementovat Acknowledge spolu s propagovanou tranzakciou z JDBC, Retry mechanizmy alebo rucne implementovat Error handling a replayom cez DLQ ? A nepacilo by sa Vam, keby automaticky fungovala propagacia tranzakcie pri praci s Kafkou a JDBC (nie naozaj nemam na mysli XA tranzakcie) ... videl ste uz niekedy implementaciu posuvania offsetu v Kafke v low level kniznici od Kafkacov ? No tak pre toto existuje Spring AMQP projekt...aby ste vyuzivali tu synergiu.
Jinak díky za nabídku, ale pokud jsi reprezentativní vzorek lidí ve vaší společnosti, tak k vám jít pracovat opravdu nechci 
To je uplne v poriadku, na takychto ludi ani necielime...dnes je naozaj znalost syntaxe a zakladov jazyka uplne nepostacujuca....
Az budes mat odkodenych ako lead dev a architekt 10+ rokov, napis, potom mozme pokecat ;-)
Zobrazit příspěvky
