Czy zwracać obiekt DTO z innymi obiektami?

0

Robię aplikacje podobną do StackOverflow. Nie ukrywam, że uczę się robić REST API na ich API https://api.stackexchange.com/docs. Jednam mam pewien dylemat, co do zwracanego obiektu. Po tym API wnioskuję, że ich strona działa tak: robią zapytanie do API zwracające obiekt pytania za pomocą identyfikatora, następne wykonuję połączenie, aby zwrócić listę odpowiedzi dla pytania, ale tylko z identyfikatorami, bez ciała(bez tekstu) https://api.stackexchange.com/docs/answers-on-questions#order=desc&sort=activity&ids=48493222&filter=default&site=stackoverflow&run=true, i dopiero jak mają listę odpowiedzi z ID, to dla każdej odpowiedzi wykonują połączenie na np. https://api.stackexchange.com/docs/answers-by-ids#order=desc&sort=activity&ids=48493222&filter=default&site=stackoverflow&run=true, aby pobrać zawartość odpowiedzi(tekst). Koniec końców wychodzi jedno połączeni do pobrania samego pytania, jedno połączenie do pobrania listy odpowiedzi, i w przypadku gdy pytanie ma np. 10 odpowiedzi, to robią jeszcze ok. 10 zapytań, aby pobrać każde pytanie. Czyli wychodzi 12 zapytań do serwera. Czy to nie jest za dużo. Czy robienie osobnego zapytania dla osobnej rzeczy jest wydajne. Czy to trochę nie za dużo połączeń?

Mozna przecież by było zwrócić taki przykładowy obiekt

{
  "answerCount": 0,
  "answered": true,
  "answers": [
    {
      "body": "string",
      "comments": [
        {
          "body": "string",
          "created": "2018-01-30T15:00:39.521Z",
          "id": 0,
          "owner": {
            "displayName": "string",
            "id": 0
          }
        }
      ],
      "created": "2018-01-30T15:00:39.521Z",
      "id": 0,
      "lastEditDate": "2018-01-30T15:00:39.521Z",
      "owner": {
        "displayName": "string",
        "id": 0
      }
    }
  ],
  "body": "string",
  "comments": [
    {
      "body": "string",
      "created": "2018-01-30T15:00:39.521Z",
      "id": 0,
      "owner": {
        "displayName": "string",
        "id": 0
      }
    }
  ],
  "created": "2018-01-30T15:00:39.521Z",
  "id": 0,
  "lastEditDate": "2018-01-30T15:00:39.521Z",
  "owner": {
    "displayName": "string",
    "id": 0
  },
  "tags": [
    "string"
  ],
  "title": "string"
}

gdzie w obiekcie pytanie, znajdują się od razu odpowiedzi i komentarze i nie trzeba tego wszystkiego pobierać z serwera osobno. W przypadku gdy pytanie ma np. 20 odpowiedzi i np. każda odpowiedź ma po 10 komentarzy, to wychodzi przecież z ponad 200 połączeń do serwera.

Co o tym sądzicie?

0

Zazwyczaj takie rzeczy jak pytanie, które ma 20 odpowiedzi które ma 10 komentarze da się pobrać jednym query do bazy (robi się wtedy podwójny join).

0

To nie jest odpowiedź na moje pytanie. Czy zabieg jaki stosuje SO jest opłacalne?

1
Czarek12 napisał(a):

To nie jest odpowiedź na moje pytanie. Czy zabieg jaki stosuje SO jest opłacalne?

Nie, ale z tego co widzę, to ich aplikacja frontendowa nie wykonuje tylu zapytań, a pobiera gotowego HTMLa. Architektura SO wydaje się być trochę bardziej skomplikowana. Stawiam na jakiś pośredni serwer www, z którego wykonywane są odpowiednie zapytania (te, o których mówisz), a odpowiedź jest cacheowana w postaci strony HTML, która jest następnie zwracana do użytkownika bez potrzeby wykonywania za każdym razem tylu zapytań na drodze przeglądarka -> serwer HTTP.

Możliwe, że przy aktualizacji danego pytania, np. przy pojawieniu się nowej odpowiedzi w systemie pojawia się event, który inicjalizuje przebudowanie tak scacheowanej strony HTML ponownie.

0

Czyli coś na zasadzie, że w Spring wykonuję zapytanie na określony adres za pomocą np. RestTemplate, zwrócone dane ładuję na model i zwracam widok z modelem i układam na tronie np. w Thymeleaf?

1
Czarek12 napisał(a):

Czyli coś na zasadzie, że w Spring wykonuję zapytanie na określony adres za pomocą np. RestTemplate, zwrócone dane ładuję na model i zwracam widok z modelem i układam na tronie np. w Thymeleaf?

Tak, coś w tym stylu. Zaletą takiego rozwiązania jest to, że warstwa, która zaciąga dane może być wykonana w jakiejkolwiek technologii, która umożliwia ich (danych) poźniejszą prezentację na WWW, ponieważ komunikuje się z serwisem RESTowym przez HTTP.

0

Czyli wychodzi na to, że i tak wykonują wiele zapytań, ale nie z przeglądarki, tylko z samego kodu.

1
Czarek12 napisał(a):

Czyli wychodzi na to, że i tak wykonują wiele zapytań, ale nie z przeglądarki, tylko z samego kodu.

Tak, ale nie wykonują tych zapytań za każdym razem, kiedy użytkownik (przeglądarka) prosi o stronę. Widok HTML jest zbudowany raz, umieszczony w pamięci podręcznej, a następnie zwracany jako statyczny content HTML do użytkowników (przeglądarek). Widok jest przebudowywany w momencie jego aktualizacji, np. jak już wspominałem - aktualizacji pytania albo pojawienia się odpowiedzi.

0

Mam jeszcze pytanie. Zapytanie https://api.stackexchange.com/docs/answers#order=desc&sort=activity&filter=default&site=stackoverflow&run=true zwraca listę odpowiedzi, ale taki obiekt nie posiada ciała, czyli tekstu tej odpowiedzi. Więc biorę ID i wykonuję zapytanie na https://api.stackexchange.com/docs/answers-by-ids#order=desc&sort=activity&ids=48531405&filter=default&site=stackoverflow&run=true, aby pobrać odpowiedź, a tutaj znowu nie ma zawartości tekstu odpowiedzi. Jak z takiej odpowiedzi pobrać tekst odpowiedzi?

1 użytkowników online, w tym zalogowanych: 0, gości: 1