Główne różnice między SSI (po stronie serwera) i ESI (po stronie krawędzi)


13

Potrzebuję dołączyć dynamiczną treść do stron statycznych na poziomie serwera WWW. 2 dotychczasowe opcje to Server Side Include (SSI)i Edge Side Include (ESI).

Choć początki SSIwydają się stare i niejasne (ta strona w pamięci podręcznej z 95 z University of Illinois wydaje się być odniesieniem , najwyraźniej pochodzi z NCSA httpdserwera, który zasilał około 95% sieci ), ESIwydaje się , że jest nowsza i cieszy się ( w3 specyfikacje z 2001 roku, napisane głównie przez facetów z Akamai ).

Poza tym wciąż słyszę o Varnish+ESI i zastanawiam się, czy to powinno być właściwe rozwiązanie. Jednak mam już instalację w miejscu nginx, które obsługuje tylko SSI, i chciałby przestrzegać KISSzasady i unikać Varnish, jeśli to w ogóle możliwe.

W moim przypadku bezpośredniego użycia, który będzie obejmował dynamiczny pasek użytkownika u góry każdej strony, uważam, że SSIwykona to zadanie. Obawiam się jednak, że wraz z rozwojem mojej witryny będę potrzebował tylko obsługiwanych funkcji, ESIktóre zmusią mnie do przeprojektowania wszystkiego, co prowadzi do mojego pytania (w końcu czytelnik mówi):

Jakie główne funkcje, które nie są przez SSIto obsługiwane , sprawiłyby, że wybrałeś ESI(i odwrotnie)?


Poza prostotą projektowania, dlaczego nie możesz wykorzystać obu?
MikeyB,

2
Prostota projektu jest powodem, dla którego nie wykorzystałbym obu w tym momencie (nie dlatego, że myślę, że nie pasowałyby do siebie, ale ponieważ nie miałbym czasu na wdrożenie i utrzymanie obu).
Maks.

Z tego, co widziałem, ESI jest jak SSI, ale ma więcej funkcji (try-catch, ...).
Julien

Odpowiedzi:


2

Tagi dla SSI i ESI są tak podobne, że nie martwiłbym się tym zbytnio. Lakier i tak obsługuje tylko najbardziej podstawowe użycie ESI.

Używaj SSI i nginx, ponieważ je masz, a jeśli kiedykolwiek potrzebujesz buforowania Varnish, jesteś tylko trywialnym skryptem powłoki od zmiany SSI na ESI.


1

Lakier jest przeznaczony do tego, więc będziesz mieć więcej opcji z Varnish do zarządzania pamięcią podręczną niż z Nginx (nawet jeśli Nginx ma wiele wbudowanych opcji).

Ponieważ Nginx zawsze odpowiada moim potrzebom (prosta pamięć podręczna fragmentów, proxy, dobra prędkość ...) Jeszcze nigdy nie próbuję lakieru!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.