Wpis z mikrobloga

@BlackySeth: powinieneś mieć jakąś klasę serwisową, która te same dane zwróci zarówno do API jak i do funkcji, w której te dane potrzebujesz.

czyli tak upraszczając:

NIE:
repozytoria -> serwis -> api -> wywołanie w jakiejś funkcji

TAK:
repozytoria -> serwis -> (api lub wywołanie w jakiejś funkcji)
@BlackySeth: Rozbij sobie ten kontroler na dwie warstwy: jedna ma API restowe, a pod spodem ma API bezpośrednie. Pierwsza niech jedynie tłumaczy żądania. Myk w tym, że tę drugą będzie łatwiej używać do innych rzeczy i łatwiej testować.
@BlackySeth: czy w takim razie cache nie jest o jedną warstwę za wysoko? problem polega na tym, że próbujesz "naprawić" jedną niedogodność (cache) używając czegoś, co służy czemuś innemu (api), a z doświadczenia wiem, że choć takie rzeczy działają, to sprawiają później różnorakie problemy, od samego zrozumienia działania, przez testowanie, a na... wydajności skończywszy :)
@BlackySeth: to świetna idea. Kompletne rozdzielenie warstw aplikacji. Na tej zasadzie działają także mikroserwisy, które zyskują coraz większą popularność i chyba będą królowały w najbliższej przyszłości.
Robiliśmy w zespole kiedyś testy i niestety na serwerach PHP+Apache mieliśmy zbyt duże opóźnienia w odpytywaniu tego samego serwera rzędu 55ms na zapytanie, które rzutowały na sumaryczny czas odpowiedzi przy około 20 funkcjach na 1-1.5s dodatkowego czasu na odpowiedź. W webie to o 10 razy