Co to jest Middleware?

Co dokladnie rozumiecie przez Middleware? Czy to jest zwiazanego z jakimkolwiek desing patter czy cos? Kto to wymyslil i jaka jest tego definicja? Czy zostalo gdzies opisane kiedy dokladnie tego uzywac, a kiedy nie?

Np w Laravel jest dokladnie napisane, ze jest to klasa, ktora cos tam robi przed albo po HTTP request. Nie mozna Middleware uzywac np po sordu request czyli np wywolac ja z metody controllera. Ale czy to jest zasada? Czy tylko tak Laravel robi, a inne frameworki robia inaczej?

Bardziej mnie interesuje jak dzialaja Middleware np w Symfony :) Ktos, cos?

Nie wiem jak to jest w Laravelu, ale middleware w kontekście frameworków webowych to zwykle coś, co jest między requestem, a kodem, który ten request obrabia (również między kodem który zwraca response, a tym co faktycznie leci do klienta). Taki pośrednik.

Request —> middleware odbiera request i być może go jakoś modyfikuje przed przekazaniem dalej —> główna logika się dzieje i zwraca response —> middleware odbiera response i być może ją jakoś modyfikuje przed zwróceniem klientowi

Chyba słowo pochodzi sprzed rewolucji REST-owej
W tamtym czasie posiadało wyraziste znaczenie, obecnie nie więcej niż buzzowrd / IT-marketing

wg wikipedii od 1968 się używa tego słowa
https://en.wikipedia.org/wiki/Middleware

W "normalnych" aplikacjach jest dużo poziomów abstrakcji.

W bardziej "prostych", albo amatorskich, z reguły są dwie (jeśli w ogóle), warstwa interfejsu (w przypadku laravela to jest wszystko co ogarnia HTTP), i warstwa implementacji - czyli cały kod który piszemy w aplikacji.

Jeśli zachodzi potrzeba dodania większej ilości warstw (a w dużych aplikacjach zawsze zachodzi), to trzeba je wsadzić między istniejące warstwy, tylko jak rozumiem, w laravelu mało kto się tym przejmuje, więc nazwano to "Middleware".

W prostych słowach, w laravelu to jest po prostu kod który obsługuje request przed kontrollerem.

Co do drugiej części pytania - różne Frameworki do tego podchodzą inaczej, w niektórych w ogóle nie ma czegoś takiego. Jak dla mnie to Middleware to jest termin wymyślony przez laravela żeby gdzieś upchnąć feature'y.

To dotczy pipes&filters trochę.
Middle - pomiędzy
Ware - rzecz - dzięki @Riddle za poprawkę :)

I teraz w pipes and filters masz rurki które coś uruchamiają, jak np. Throttling czy Auth - one uruchamiają się zanim wykona się request docelowy - całość właśnie na zasadzie pipes&filters.
Czyli odpowiadając - to jest oprogramowanie "pomiędzy".

Jeśli chcesz więcej o pipes&filters to coś tam napisałem o tym na swoim insta: https://www.instagram.com/p/CxVbWo2NUhY/?img_index=1

Dalej nie wiem :D Dla mnie to jest cos pomiedzy requestem (before, after). Ale nie wiem moze i to mozna uzywac np z metody. Nie mam pojecia.

Riddle napisał(a):

Co do drugiej części pytania - różne Frameworki do tego podchodzą inaczej, w niektórych w ogóle nie ma czegoś takiego. Jak dla mnie to Middleware to jest termin wymyślony przez laravela żeby gdzieś upchnąć feature'y.

Bez urazy ale jak na kogos kto sprawia wrazenie ogarniajacego php'a, akurat co do middleware nie powinienes miec zadnych watpliwosci : PSR-15: HTTP Server Request Handlers

@poniatowski
W php chyba jedynie Slim4 tak naprawde pozwala w pelni korzystac z poprawnej integracji middleware w kodzie. Slim4 - application middleware i jako koncept jest to chyba najlepsza rzecz na jakiej mozna oprzec kod aplikacji webowych.
Middleware to najprosciej rzecz ujmujac:

controllers (action controllers), services (action services) i akcje (actions) bez sesji, walidacji, autoryzacji, autentykacji i wszystkiego co peta sie "pod nogami" w kodzie.

proximus-prime napisał(a):

Riddle napisał(a):

Co do drugiej części pytania - różne Frameworki do tego podchodzą inaczej, w niektórych w ogóle nie ma czegoś takiego. Jak dla mnie to Middleware to jest termin wymyślony przez laravela żeby gdzieś upchnąć feature'y.

Bez urazy ale jak na kogos kto sprawia wrazenie ogarniajacego php'a, akurat co do middleware nie powinienes miec zadnych watpliwosci : PSR-15: HTTP Server Request Handlers

@poniatowski
W php chyba jedynie Slim4 tak naprawde pozwala w pelni korzystac z poprawnej integracji middleware w kodzie. Slim4 - application middleware i jako koncept jest to chyba najlepsza rzecz na jakiej mozna oprzec kod aplikacji webowych.
Middleware to najprosciej rzecz ujmujac:

controllers (action controllers), services (action services) i akcje (actions) bez sesji, walidacji, autoryzacji, autentykacji i wszystkiego co peta sie "pod nogami" w kodzie.

Ja zawsze uzywalem i rozumiem middleware jako klasa ktora jesty wywolana przed albo po kontrolerze. I przyjmuje klase request jako DI. Widzialem ten link z psr. Kumpel jednak upiera sie, ze to nie dokonca tak jest. Niby twierdzi, ze zna DDD. I tam niby middleware jest pomiedzy roznymi warstwami. Dla mnie to dalej nie ma sensu. Tak jak jest opisane w PSR tak uzywa slim, laravel, zend etc. Nie wiem jak Symfony. Takze wydaje mi sie, ze tak jest. Middeware jest przed wywolane przed albo po wywolaniu kontrolera, tak ja to od zawsze rozumialem :)

To co chciałem wyrazić to to, że często dodanie "Middleware'ów" do frameworka staje się koniecznością, przez słabe decyzje projektowe tego frameworka.

poniatowski napisał(a):

Ja zawsze uzywalem i rozumiem middleware jako klasa ktora jesty wywolana przed albo po kontrolerze.

Uscislajac - klasy w liczbie mnogiej, wywolywane w okreslonym przez developera porzadku. Jesli chodzi o moment wywolania to raczej wylacznie przed kontrolerem, dlatego ze wszystko co wypluwa z siebie kontroler to response, a jesli juz cos musisz robic dodatkowo z respons'em ogarnia to dodatkowa, warstwa czyli responder.

poniatowski napisał(a):

I przyjmuje klase request jako DI.

Nic z tych rzeczy, w sensie formalnym middleware jest takim samym serwisem jak kazdy inny, pomijajac fakt iz wstrzykiwanie DI kontenera jest wery bad a przejmowanie jego funkcji przez request to w ogole juz jakis kosmos, same middleware a takze wszystkie niezbedne mu zaleznosci ogarnia DI. Request w tym przypadku w praktyce formalnie sluzy juz nie tylko abstrakcja dla transferu danych miedzy klientem a aplikacja, ale rowniez miedzy middleware reszta aplikacji (kontrolerem, serwisami)

poniatowski napisał(a):

Widzialem ten link z psr. Kumpel jednak upiera sie, ze to nie dokonca tak jest. Niby twierdzi, ze zna DDD. I tam niby middleware jest pomiedzy roznymi warstwami.

W takim przypadku jedna dowolna warstwa znajdujaca sie miedzy dwiema innymi zawsze bedzie w jakims sensie middleware, musicie porozumiec sie co do wspolnej plaszczyzny definicji.

poniatowski napisał(a):

Dla mnie to dalej nie ma sensu. Tak jak jest opisane w PSR tak uzywa slim, laravel, zend etc. Nie wiem jak Symfony.

Jesli chodzi o Symfony, to zanim pojawil sie PSR15, Fabien Potencier, formalnie podobny mechanizm zrealizowal za pomoca event'ow, ale niestety wylacznie w odniesieniu do samego frameworka. Custom'owa organizacja Twojego wlasnego kodu ktora moglaby polegac na samodzielne podpiecie pod inicjowany frameworkiem event chain jest oglednie mowiac "nie ulatwiona", a to z tego powodu, ze de facto ego tworcy symfony nigdy nie pozwalalo mu przyznac, ze cos wartosciowego moze rowniez powstac poza SensioLabs. Zreszta podobna sytuacja ma miejsce w przypdaku pozostalych PSR'ow.

To słowo ma różne znaczenia w różnych typach aplikacji.

Jeżeli chodzi o HTTP/WWW to Middleware jest po prostu tym co jest między request a response.

Middleware odbiera request i produkuje z niego response.

Biorąc to bardzo konserwatywnie, to cały PHP jest Middlewarem, bo za request i response odpowiada serwer WWW, a PHP jest tym co "stoi" pomiędzy, i sam serwer WWW jest dla PHP przeźroczysty.

Oczywiście poszczególne frameworki w samym PHP rozdzielają request i response na interfejsy, tworząc wirtualny, "cieńszy" middleware, ale powtarzam: konserwatywnie rzecz biorąc to cały PHP jest Middlewarem jeżeli patrzymy na czyste HTTP.

I to właśnie przeźroczystość jest tym co rozdziela między sobą jakiekolwiek warstwy: czy mówimy o Middleware, czy np. o warstwie danych i warstwie aplikacji (bo taki podział też jest): jeżeli te dwie warstwy są dla siebie przeźroczyste i od siebie niezależne, wtedy mamy dobrze zaprojektowany system, i prawidłowo oddzielone warstwy.

poniatowski napisał(a):

Bardziej mnie interesuje jak dzialaja Middleware np w Symfony :) Ktos, cos?

To proste Middleware to funkcja ktora jest wywolywana przed akcja kontrolera. Mozesz sprawdzac czy ktos ma dostep do danego zasobu, do wykonania akcji, pobierac licznik nowych wiadomosci, cokolwiek

moj przyklad z larvy plik web.php

Route::group(['middleware' => ['auth', 'check.user.access']], function () {

    // worldpay
    Route::get('/payment-cash/{contract}/amount/{amount}/mode/{mode}', [PaymentController::class, 'paymentCash'])->name('contract.payment.cash');

jeden middleware to standardowy auth i sprawdzmy czy dostep do funkcji/akcji w grupie ma uzytkownik po zalogowaniu. a drugi moj sprawxa czy dany uzytkownik ma dostep do tej grupy. I to wszystko

Ja się spotkałem z tym określeniem w takim znaczeniu jako mechanizmu który pozwala modyfikować zachowanie w środku programu, użytkownikom 2nd, 3rd party. Normlanie masz dostęp do publicznego API czyli przodu aplikacji, lub są jakieś mechanizmy pozwalające robić bardzo nisko poziomowe podmianki. czyli na końcu. W tym rozumieniu, ciekawym przykładem midle-ware jest scrach, który ma nie zmienialne UI, nie zmienną logike i backend, ale mozesz wstrzyknąć swój kod i ruszać duszkami. Innym przykładem który przychodzi mi namyśl moga byc programy do symulacji, do których przekazujesz matematyczny model własności materiału. Te samo UI do projektowania, ten sam backend do obliczeń, użytkownik końcowy ma dostęp do kawałka w środku.

[ed] teraz widzę ze to temat PHP a nie ogólny