Jaki sposoby na REST API oprocz Springa

Znacie jakies fajne sposoby na postawienie prostego REST API bez uzycia Springa czy Spring Boota ? Chetnie w swiecie JVM ale niekoniecznie.

Ktor, ratpack, javalin

Micronaut jest świetny.

Scala http4s

https://http4s.org/v1.0/service/

Uważam, że framework ma małe znaczenie i wszystko jest do siebie bardzo podobne.

Uważam, że niszowe frameworki to głupota i najczęściej zwykły hype i większe zło bo nagle ten nie-spring jest jeszcze gorszy niż sam Spring.

Biorą później te wszystkie reactive-sreactive i nie mają pojęcia jak tego używać.

Uważam, że framework ma małe znaczenie i wszystko jest do siebie bardzo podobne.
spuszczam na Ciebie hejt. Co to za herezje?
Czemu nie piszesz w Visual Basicu?

Poza tym jedyny niszowy framework w tym wątki jak na razie to chyba javalin. (ale może się nie znam).

DropWIzard

jarekr000000 napisał(a):

Uważam, że framework ma małe znaczenie i wszystko jest do siebie bardzo podobne.
spuszczam na Ciebie hejt. Co to za herezje?
Czemu nie piszesz w Visual Basicu?

Bo nie jest w javie Panie "Folklor 4programmers"
Żadne herezje, wrzucanie gdzies na proda jakiegoś http4s gdy 10 innych zespołów używa Springa to delikatnie mówiąc "niezbyt mądre".

Fixowanie się na frameworkach gdy jest tysiąc innych ważniejszych rzeczy jest po prostu słabe.

karsa napisał(a):

Bo nie jest w javie Panie "Folklor 4programmers"
Żadne herezje, wrzucanie gdzies na proda jakiegoś http4s gdy 10 innych zespołów używa Springa to delikatnie mówiąc "niezbyt mądre".

Fixowanie się na frameworkach gdy jest tysiąc innych ważniejszych rzeczy jest po prostu słabe.

Właśnie prezentujesz fixowanie się na frameworkach.
Przy okazji, jeśli 10 zesołów używa springa to wręcz krytyczne jest, zeby czasem użyć czegoś innego.
Jeśli tego nie zrobisz to będziesz myślał, że nie ma różnicy między frameworkami.

Spring też kiedyś był niszowy.

jarekr000000 napisał(a):

Właśnie prezentujesz fixowanie się na frameworkach.
Przy okazji, jeśli 10 zesołów używa springa to wręcz krytyczne jest, zeby czasem użyć czegoś innego.

Spring też kiedyś był niszowy.

To będą sami z tym frameworkiem bez żadnego wsparcia na produkcji.
Lepszy jeden solidny stack niż anarchia.

Co w tym krytycznego by użyć czegoś innego? Jakiż to inżynieryjny argument za tym stoi poza jarkową nienawiścią do Springa?

Żadne herezje, wrzucanie gdzies na proda jakiegoś http4s gdy 10 innych zespołów używa Springa to delikatnie mówiąc "niezbyt mądre".

Czemu nie jest zbyt mądre? To, co robią inne zespoły nie powinno nas za bardzo interesować, najwyżej jakiś manago pomarudzi, że wdrażanie ludzi przy zmianie zespołu trwa miesiąc dłużej. No i Spring ze Scalą (bo piszesz o http4s ) ...

@karsa ostatnio w co drugim wątku wyskakujesz z czapy z bulgotem jacy to programiści są źli bo cośtam, teraz padło na złych programistów którzy nie chcą klepać w Springu? :D

Pójdź za radą @WhiteLightning i załóż sobie wątek we Flame do hejtowania wielkich panów inżynierów klepaczy crudów, nikomu nie będziesz przeszkadzał a niejeden się chętnie dołączy

A w temacie to nie JVM, przestałem śledzić i nie wiem czy się jeszcze rozwija, ale kiedyś we Flasku można było najprostsze API w paru(nastu) linijkach sklecić

karsa napisał(a):

Żadne herezje, wrzucanie gdzies na proda jakiegoś http4s gdy 10 innych zespołów używa Springa to delikatnie mówiąc "niezbyt mądre".

Mądre/nie mądre to się dopiero okaże przy dobieraniu nowych ludzi do tego zespołu (wszędzie jest naturalna rotacja).

a) Spoko, niszowego frameworka nauczy się w pracy
b) MUSI mieć komercyjne doświadczenie rok, najlepiej 2 lata, w naszym niszowym frameworku na którym jedziemy.

Nic trudnego wrzucić coś niszowego i na tym bazować. Sztuka to później normalnie utrzymać i rozwijać.

null null napisał(a):

Żadne herezje, wrzucanie gdzies na proda jakiegoś http4s gdy 10 innych zespołów używa Springa to delikatnie mówiąc "niezbyt mądre".

Czemu nie jest zbyt mądre? To, co robią inne zespoły nie powinno nas za bardzo interesować, najwyżej jakiś manago pomarudzi, że wdrażanie ludzi przy zmianie zespołu trwa miesiąc dłużej.

Spytaj wszystkich dev(opsów) lub platform engineers z większych firm to się dowiesz. Nie tylko programiści żyją w tym światku.
Zespoły produktowe muszą używać pewnego rodzaju platformy. Nawet w Netflixie wiekszość to teraz już Spring jezeli chodzi o JVM, a niby firma taka uprawiająca autonomie...

Ludzie biorą sobie jakiś nowy framework i później braki w:

• observability
• resilience
• integracje z różnego rodzaju toolingiem

Bo coś co było np. w springu z paczki to zespół nie raczył pomyśleć, że coś trzeba jednak doklepać.

karsa napisał(a):

To będą sami z tym frameworkiem bez żadnego wsparcia na produkcji.
Lepszy jeden solidny stack niż anarchia.

To nie jest anarchia, to jest postęp.
Ktoś kiedyś użył C++, jak wszystkim starczało C.
Ktoś użył Javy, jak w modzie był visual basic, Pascal i C++.
Jakiś heretyk wdrożył Springa jak wszytko było Java EE (i to nawet niedawno).

Co w tym krytycznego by użyć czegoś innego? Jakiż to inżynieryjny argument za tym stoi poza jarkową nienawiścią do Springa?

Główny argument to taki, że bardzo trudno, wręcz niemożliwe, jest znalezienie kogoś kto tego Springa ogarnia. Framework pole minowe - konkretne narzekania już wielokrotnie prezentowałem.
Osobiscie znam ludzi, którzy pracują ze Springiem od wersji 1.x i kompletnie nie ogarniają (co bardzo boli na produkcji).

BraVolt napisał(a):

karsa napisał(a):

Żadne herezje, wrzucanie gdzies na proda jakiegoś http4s gdy 10 innych zespołów używa Springa to delikatnie mówiąc "niezbyt mądre".

Mądre/nie mądre to się dopiero okaże przy dobieraniu nowych ludzi do tego zespołu (wszędzie jest naturalna rotacja).

a) Spoko, niszowego frameworka nauczy się w pracy
b) MUSI mieć komercyjne doświadczenie rok, najlepiej 2 lata, w naszym niszowym frameworku na którym jedziemy.

Nic trudnego wrzucić coś niszowego i na tym bazować. Sztuka to później normalnie utrzymać i rozwijać.

Oraz będziesz beta testerem bo pierwszy się przekonasz najprawdopodobniej jak coś się wywali na produkcji. Jak w przypadku kotlinowego http4k gdzie były jeszcze deadlocki na http cliencie w 2019 roku. Wielu też nie bierze pod uwagę, że czegoś najprawdopodobniej będzie brakować i będzie trzeba to doklepać samemu lub zwyczajnie zintegrować.

http://boringtechnology.club/

karsa napisał(a):

Oraz będziesz beta testerem bo pierwszy się przekonasz najprawdopodobniej jak coś się wywali na produkcji. Jak w przypadku kotlinowego http4k gdzie były jeszcze deadlocki na http cliencie w 2019 roku. Wielu też nie bierze pod uwagę, że czegoś najprawdopodobniej będzie brakować i będzie trzeba to doklepać samemu.

Chciałem się tylko spytać czy OP napisał, że wrzuca na produkcję, bo właśnie przepisywać będzie Netflixa?

Sorry, ale to normalne, że zanim się z czymś pójdzie na produkcję to się testuje na małych projektach. Czasem rok, czasem dwa. Robi load testy, DOSy itd.
Jest się beta testerem (choć serio - w przypadku większości tu wymienionych to raczej tylko nazywanie tego beta testami to ignorancja).
Dla mnie ważne jest przetestowanie w pracy zespołowej - bo w zgranym, jednososobowym zespole wszystko idzie zwykle dobrze.

Ale oczywiście można to olać, bo przecież jest Spring - nic już lepszego nie powstanie, po co się męczyć.

jarekr000000 napisał(a):

karsa napisał(a):

Oraz będziesz beta testerem bo pierwszy się przekonasz najprawdopodobniej jak coś się wywali na produkcji. Jak w przypadku kotlinowego http4k gdzie były jeszcze deadlocki na http cliencie w 2019 roku. Wielu też nie bierze pod uwagę, że czegoś najprawdopodobniej będzie brakować i będzie trzeba to doklepać samemu.

Chciałem się tylko spytać czy OP napisał, że wrzuca na produkcję, bo właśnie przepisywać będzie Netflixa?

Sorry, ale to normalne, że zanim się z czymś pójdzie na produkcję to się testuje na małych projektach. Czasem rok, czasem dwa. Robi load testy, DOSy itd.
Jest się beta testerem (choć serio - w przypadku większości tu wymienionych to raczej tylko nazywanie tego beta testami to ignorancja).
Dla mnie ważne jest przetestowanie w pracy zespołowej - bo w zgranym, jednososobowym zespole wszystko idzie zwykle dobrze.

Ale oczywiście można to olać, bo przecież jest Spring - nic już lepszego nie powstanie, po co się męczyć.

Oczywiscie i sie zgadzam.
Ja osobiscie też najpierw bawie sie sam i waliduje coś by ewentualnie w ogole pomyslec o wdrożeniu.
Ale większosc ludzi realnie testuje dopiero na produkcji.

Chyba jeszcze nie padło, u mnie w firmie jest jeszcze Vert.x - chociaż byłem przeciwny z powodów powyższych i brakowało dobrego rationale.

Osobiście spędziłem trochę czasu na poznanie trochę języków i frameworkow. Miało to sens tylko tam gdzie coś się różniło diametralnie.

Ale w przypadku frameworkow, ich nauka to się wydaje po prostu stratą czasu.
Lepiej się pouczyć Linuxa, Clouda, http, TCP itp.

@jarekr000000: zadna produkcja totalnie dla zabawy i eksperymentowania.

Może napisz więcej co chciałbys zrobić i jakie języki Ci pasują. To można będzie konkretniej doradzić.

Jeżeli znasz Javę to może Scala i może akka-http lub ten http4s.

Jeżeli chodzi o pracę to prędzej kotlin, to i tak warto zobaczyć jak to działa ze Spring lub jakiś http4k, ktor, Vert.x.

Lub zupełnie inny biegun Go, samo sdk lub z go-chi.

Lub Elixir z phoenix.

imo i tak lepiej się skupić na czymś innym.

@jarekr000000: chce pobawic sie narzedziami testowymi pod katem performance, testy backendu, end to end itp. Kladac nacisk wlasnei na strone testowa. Wiec chce sobie postawic prosty serwis restowy, do ktorego bede sie dobijal z poziomu testow. Moze sie z tego cos wiecej wykluje, moze nie. W Springu wiem jak to zrobic i mam go w pracy stad chce sie pobawic czyms innym. Co do jezykow -> najchetniej cos z JVM, przy czym chetnie sie dowiem jesli ktos zna fajne rozwiazania w innych jezykach (najprawdopodobniej nie uzyje, ale bede wiedzial ze takie cos istnieje).

Do takiej zabawy chyba niezły będzie Ratpack:

• bije wszystko co znam (poza może gołym Apache HTTP) pod wzlędem odporności na obciążenie,
• umożliwia niezłą kontrolę nad przetwarzaniem - np. zrobienie takiego głupiego serwera, który przyjmie na twarz 10 tys requestów... poczeka 2 minuty, i dopiero odpowie,
• non blocking,

Wady:

• jest w javie,
• nie wspiera HTTP2.0

Ktor kotlinowy jest zbliżony, ale bardziej sophisticated, i tak sobie zdokumentowany. więc mimo fajniejszczego jezyka muszę przejrzeć kod serwera, aby dowiedzieć się jak niektóre sztuczki zrobić.
Tu przykład dziwnego testu, który miał pokazać czy ktor jest faktycznie non-blocking:
https://github.com/neeffect/nee/blob/master/nee-ctx-web-ktor/src/test/kotlin/pl/setblack/nee/ctx/web/KtorThreadingModelTest.kt

Do takich małych rzeczy używamy niekiedy
http://sparkjava.com/

jax-rs, implementacje - resteasy, jersey itp

A o biednej Javie EE / Jakarcie zapomnieliście?
https://eclipse-ee4j.github.io/jakartaee-tutorial/jaxrs002.html#GILIK

package jakarta.tutorial.hello;

import javax.ws.rs.Consumes;
import javax.ws.rs.GET;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;

/**
 * Root resource (exposed at "helloworld" path)
 */
@Path("helloworld")
public class HelloWorld {
    @Context
    private UriInfo context;

    /** Creates a new instance of HelloWorld */
    public HelloWorld() {
    }

    /**
     * Retrieves representation of an instance of helloWorld.HelloWorld
     * @return an instance of java.lang.String
     */
    @GET
    @Produces("text/html")
    public String getHtml() {
        return "<html lang=\"en\"><body><h1>Hello, World!!</h1></body></html>";
    }
}

Servant to bardzo przyjemna biblioteka.
Jego głównym celem jest stworzenie abstrakcji do opisu api. To punktuje głównie wtedy, kiedy robisz frontend w haskellu i masz out of the box integracje z abstrakcjami frontendu (np. https://github.com/imalsogreg/servant-reflex) + statyczne typowanie na cały projekt.

@WhiteLightning: Gdybyś między dobrym a łatwym chciał wybrać to drugie to może... Express ;-). Ostatecznie JS to najbardziej naturalny język do REST-a.

robie teraz klienta do API w react router i jest to calkiem proste i wygodne w obsludze, nie wiem jak ludzie mogli sie meczyc z tym JSF (albo piseli klienta w jquery?)

lambdadziara napisał(a):

robie teraz klienta do API w react router i jest to calkiem proste i wygodne w obsludze, nie wiem jak ludzie mogli sie meczyc z tym JSF (albo piseli klienta w jquery?)

W jsfie wszystko kreci sie wokol ajaxa