Firebase Admin Node httpAgent: ufikiaji wa proksi kwa huduma
Tambua shughuli zipi za Firebase Admin Node zinatumia wakala wa HTTP uliosanidiwa kabla ya kudhani trafiki yote ya SDK inatumia proksi moja.
Wito wa uthibitishaji hufanya kazi kupitia proksi, lakini muunganisho wa hifadhidata unashindikana. Katika programu ya Firebase, hilo linaweza kuwa tofauti ya usafirishaji na si proksi inayokatika.
Chaguo la programu httpAgent katika Admin Node SDK linatumika kwa huduma zinazofanya wito wa REST, zikiwemo Auth na Messaging. Wigo wake ulioandikwa hauandishi Realtime Database na Firestore. Vitu vya stakabadhi pia vina usanidi wake wa wakala kupitia mbinu husika za kiwanda cha stakabadhi.
| Shughuli inayoshindikana | Usanidi wa kuchunguza |
|---|---|
| Wito wa huduma ya Admin REST | Wakala wa HTTP wa programu |
| Kupata tokeni ya stakabadhi | Usanidi wa HTTP wa kitu cha stakabadhi |
| Muunganisho wa hifadhidata | Usaidizi wa usafirishaji wa mteja wa hifadhidata mwenyewe |
Ndiyo sababu kuongeza wakala wakati wa kuanzisha hakuwezi kuthibitisha kuwa kila muunganisho unaofuata unachukua njia moja. Rekodi huduma na lengwa linaloshindikana kabla ya kubadilisha usanidi ambao tayari unafanya kazi kwa huduma nyingine.
Majadiliano ya zamani pia huchanganya zana ya mstari wa amri ya Firebase na SDK za programu. Marekebisho ya CLI ya kusoma http_proxy hayathibitishi kuwa mteja wa hifadhidata ndani ya mchakato wako wa Node anatumia chaguo hilohilo.
Tumia kiolesura cha usanidi kinachoauniwa kwa usafirishaji unaouhitaji kweli. Kurekebisha utegemezi wa WebSocket ulio ndani kunaweza kuonekana kama unaathiri muunganisho mmoja huku njia nyingine ikibaki bila mabadiliko, na hufanya sasisho la utegemezi la baadaye kuwa gumu kueleweka.