Már ütköztem ebbe a problémába. Az ESP-n a tcp queue length kicsi, és egyszerre csak egy kérést tud kiszolgálni. Ha a böngésző a főlap betöltésekor sok (>5) kérést kezd el a szerver felé, akkor lesznek olyanok amire a szerver már nem válaszol, mert a tcp queue-ba se fér bele.
Találtam egy megoldást, ami nekem bevált:
- megírtam a frontendet react + blueprintjs
- minify-oztam, ebből az egész frontendre lett kb. 6 állomány amit be kell töltenie
- írtam egy olyan programot, ami kielemzi a lefordított minify-ozott frontend kódot, és generál hozzá egy javascript főprogramot, ami a következőket teszi:
- fogja az összes frontend-hez szükséges file-t
- mindegyikre lefuttat egy GET ajax kérést SZEKVENCIÁLISAN tehát megvárja amíg befejeződik az egyik, és csak utána kezdi a másikat
- eközben kirak a user-nek egy progress bart amin látszódik hogy hol tart
- miután az összeset GET-elte egyszer, redirect-el a valódi főlapra
- a valódi főlap is GET-eli őket, de addigra a cache-ben vannak és azok a kérések nem jutnak el az MCU-ig
- a frontend és a backend (MCU-n futó API) közötti kommunikáció pedig egyértelműen javascript kód AJAX hívásokkal, amik lehetőleg egymás után futnak le.
Az egész minify-ozott kód általában 2MB alatt van, ráfér egy ESP-re. A web szerver részénél meg csak annyi dolgod, hogy a statikus file-ok GET kérésére visszaadsz egy max-age header-t hogy biztosan cache-be kerüljön
Ez a megoldás egészen megbízhatóan működik, és csilli villi reszponzív React-os admin oldalakat lehet vele gyártani, amik simán ráférnek egy 600 forintos ESP-re.