Renderowanie strony po stronie backendu i Vue.js. Trendy.

Piszę sobie na boku jedną apkę w Vue.js. Mam taki zamysł, że mam backend napisany w jakimkolwiek języku gdzie wystawiam REST API i chciałbym, żeby Vue.js mi konsumował to API. W planach mam jeszcze websocket podobny do tego jaki jest na forum.

Chciałem się przyjrzeć bliżej źródłom Coyote bo widziałem, że tutaj też jest coś robione w ten sposób i zauważyłem, że frontend pobiera np. całą stronę z wyrenderowanym html. Czy to jest zrobione w Vue? Jakie są aktualnie trendy? Konsumowanie suchego REST API czy renderowanie html po stronie backendu? Jak to może wyglądać w przyszłości?

Konsumowanie suchego REST API to jest wlasciwe podejscie

Ale jest wolniejsze niż to co jest tutaj na forum i np. bym musiał pobierać w osobnych zapytaniach posty, komentarze, role, profile i inne rzeczy. Być może cześć mógłbym zagregować, ale nie wszystko.

Tak, tak na pewno jest wolniejsze mhm :) oczywiscie buduuesz drugiego fb i zalezy ci zeby to bylo szybkie w h.... przydalby nam sie taki pracownik co bez testow wie co jest wolniejsze :)))) buahahah no i oczywiscie jak ktos nie ma doswiadczenia w programowaniu to bedzie pytal backend o kazda glupote. Od czego masz cache i sesje hmm ?

To chodzi o SSR (Server Side Rendering). W vue masz to w nuxcie na przykład.
Problemem z SPA jest, że klient otrzymuje js zamiast htmla i cierpi na tym SEO.

masterc napisał(a):

Konsumowanie suchego REST API to jest wlasciwe podejscie

Dlaczego ...
Server side nie umarło, i nadal można mieć ważne ku temu powody. Pierwsze z brzegu: z kodu jednego Modelu generować spójne HTML, PDF, XLS
Zwłaszcza utrzymanie aplikacji dwuwarstwowej może być skomplikowane, dzwoń z każdą zmianą np biznesu do frontmana i testuj

szafran98 napisał(a):

To chodzi o SSR (Server Side Rendering). W vue masz to w nuxcie na przykład.

Jak analizowałem to Vue + SSR dla fragmentów, np tabel z danymi wydało mi się perspektywiczne** ale ja się nie znam **
Przy czym myślimy o SSR w języku backendu

Żeby zakończyć temat to po długich przebojach przekopałem się przez dokumentację na temat SSR i Vuex oraz zrobiłem pierwszą działającą w ten sposób rzecz. Zostawię źródła dla potomnych.
https://ssr.vuejs.org/guide/data.html#data-store
https://nuxtjs.org/docs/directory-structure/store/
https://nuxtjs.org/docs/concepts/nuxt-lifecycle

W Coyote widzę, że Adam zrobił bardzo dużo w ten sposób:
https://github.com/adam-boduch/coyote/tree/b0c83cc8a244be3b9c8e39a295a76105c66985eb/resources/js/store

Tak jeszcze dodając moje myśli. Implementuję sobie pobieranie usera z REST przy pomocy Vuex i store.

Robię następujący eksperyment. Odpalam curla do frontu, sprawdzam ile razy restowy endpoint został uderzony.

W trybie dev. Uderzając front widzę kolejno rosnącą liczbę uderzeń do RESTa wraz jak wchodzę na swoją stronkę. Przy pierwszym requeście mam 1 uderzenie do RESTa. Przy następnym 2, później 3, 4, 5, itd. Kiedy zbuduję apkę i odpalę ją w trybie produkcyjnym to za każdym requestem frontu mam jedno uderzenie apki do RESTa. Co tu się wyprawia? :)

Dodam jeszcze, że ten moduł mam zaimplementowany w formie mixina, żeby on był dostępny ze wszystkich podstron.

Edit:
Ok, już rozkminiłem, że problem leży w tym, że używam używam store w mixinie, który mam globalnie, ale wciąż niesmak pozostał przez tę dziwną różnicę między trybami prod i dev.

Vue.mixin(organizationMixin)

Jak przerzuciłem używanie store do layoutu to problem przestał występować aczkolwiek nie jest to miejsce w którym chciałbym to mieć docelowo.

Edit2:
https://github.com/nuxt/nuxt.js/issues/7207
Zrobiłem trik stąd i teraz dobrze działa. Chyba się przekwalifikuję na fronta skoro już tyle umiem.

Jesli masz prosta aplikacje i interesuje cie ssr bez nuxt lub innych to istnieje https://github.com/spatie/server-side-rendering kiedys probowalem i dla vue dzialalo bez problemow

Ale jest wolniejsze niż to co jest tutaj na forum i np. bym musiał pobierać w osobnych zapytaniach posty, komentarze, role, profile i inne rzeczy. Być może cześć mógłbym zagregować, ale nie wszystko.

I nie ma w tym nic złego. Kilka requestów nikomu nie szkodzi. Jeżeli mówimy o forum to w endpoindzie z postami mogą być właśnie zagregowane podstawowe dane użytkowników (nazwa, avatar), przecież nie musisz robić requesta z pobieraniem całego profilu dla każdego użytkownika.

Jeżeli na stronie masz dużo elementów wymagających dużo danych (np. dashboard z tabelkami i wykresami) to osobne requesty są wręcz zbawieniem. Jeżeli pojedyncze dane ci zamulą (np. któryś wykres długo się wylicza) to użytkownik musi czekać na załadowanie strony. Jeżeli jednak mamy osobne requesty dla każdego to w miejsce danych komponentów możesz dać ładny placeholder, i każdy z elementów załaduje się kiedy będzie gotowy i użytkownik dzięki temu porusza się po stronie bez przeszkód.

Jeżeli boisz się o przesyt danych to odpowiedzią na ten problem jest GraphQL zamiast REST, ale i na starym dobrym REST wiele da się ugrać jeżeli się chce.

Widzę że ruszyłeś temat Nuxta i SSR, i dobrze, ale nie wiem czy z dobrych powodów. Te dane i te requesty i tak i tak będziesz robił, jedynie po stronie backu a nie frontu, na jedno wychodzi. Na SSR decydujesz się kiedy musisz uważać na SEO (ale i w SPA da się SEO ogarnąć dobrze) lub gdy z jakiegoś powodu nie chcesz upubliczniać endpointów API i musisz mieć gotowego HTMLa na wyjściu.

Konsumowanie suchego REST API czy renderowanie html po stronie backendu? Jak to może wyglądać w przyszłości?

Jeżeli przez renderowanie html po stronie backendu masz na myśli że user wchodzi na strona.pl i dostaje gotowy HTML w źródle to ok, ale jeżeli atrapę typu przez JS odwołuje się do /user/nazwa i dostaje w odpowiedni HTML z profilem użytkownika to niech się boska ręka broni przed takimi praktykami ;) Jeżeli robisz SPA lub SSR konsumujące API to to API powinno być jak najbardziej uniwersalne i zwracać wyłącznie dane (w domyśle JSON, sio od XMLa bo to nie 2005).

Moim zdaniem nie powinno się nawet używać tłumaczeń w API, tylko trzymać się jednego (angielskiego) języka, a tłumaczenia konkretnego statusu czy komunikatu błędu to zadanie już frontendu.