Pusa interreta kadro kiu transdonas JavaScript-antaŭfinan logikon al la servila flanko

La reto-kadro de Pusa estis publikigita kun la efektivigo de koncepto, kiu transdonas la antaŭfinan logikon, efektivigitan en la retumilo uzante JavaScript, al la malantaŭa flanko - administrado de la retumilo kaj DOM-elementoj, same kiel komerca logiko estas farita sur la malantaŭa fino. La JavaScript-kodo ekzekutita ĉe la retumila flanko estas anstataŭigita per universala tavolo, kiu vokas pritraktantojn situantajn ĉe la malantaŭa flanko. Ne necesas disvolvi per JavaScript por la frontfino. La referenca efektivigo de Pusa estas skribita en PHP kaj estas licencita sub la GPLv3. Krom PHP, la teknologio povas esti efektivigita en iu ajn alia lingvo, inkluzive de JavaScript/Node.js, Java, Python, Go kaj Ruby.

Pusa difinas interŝanĝan protokolon bazitan sur minimumisma aro de komandoj. Kiam la paĝo ŝarĝas, la retumilo ŝarĝas la suban DOM-enhavon kaj la JavaScript-kernon de Pusa-Front. Pusa-Front sendas retumilajn eventojn (kiel klako, malklariĝo, fokuso kaj klavopremo) kaj petajn parametrojn (la elementon, kiu kaŭzis la eventon, ĝiajn atributojn, URL ktp.) al la servilo de Pusa-Back uzante petojn de Ajax. Surbaze de la ricevitaj datumoj, Pusa-Back determinas la regilon, efektivigas la utilan ŝarĝon kaj generas respondan aron de komandoj. Ricevinte la petan respondon, Pusa-Front plenumas komandojn, ŝanĝante la enhavon de la DOM kaj la retumila medio.

La stato de la fasado estas generita sed ne kontrolita de la backend, kio faras evoluon por Pusa simila al kodo por vidkarto aŭ Kanvaso, kie la rezulto de ekzekuto ne estas kontrolita de la programisto. Por krei interagajn aplikojn bazitajn sur Canvas kaj onmousemove, eblas elŝuti kaj uzi pliajn JavaScript-skriptojn ĉe la kliento. Inter la malavantaĝoj de la metodo, estas ankaŭ translokigo de parto de la ŝarĝo de la fasado al la backend kaj pliiĝo de la ofteco de interŝanĝo de datumoj kun la servilo.

Inter la avantaĝoj estas: elimini la bezonon de partopreno de JavaScript-programistoj, stabila kaj kompakta klientokodo (11kb), nealirebleco de la ĉefa kodo de la front-end, neniu bezono de REST seriigo kaj iloj kiel gRPC, forigante la problemoj de kunordigado de petovojigo inter la front-end kaj back-end.

fonto: opennet.ru

Aldoni komenton