ກອບເວັບ Pusa ທີ່ໂອນເຫດຜົນດ້ານຫນ້າຂອງ JavaScript ໄປຫາຝ່າຍເຊີຟເວີ

ກອບເວັບ Pusa ໄດ້ຖືກເຜີຍແຜ່ດ້ວຍການຈັດຕັ້ງປະຕິບັດແນວຄວາມຄິດທີ່ໂອນເຫດຜົນດ້ານຫນ້າ, ປະຕິບັດໃນຕົວທ່ອງເວັບໂດຍໃຊ້ JavaScript, ໄປຫາດ້ານຫລັງ - ການຄຸ້ມຄອງອົງປະກອບຂອງຕົວທ່ອງເວັບແລະ DOM, ເຊັ່ນດຽວກັນກັບເຫດຜົນທາງທຸລະກິດແມ່ນດໍາເນີນຢູ່ໃນ. ດ້ານຫຼັງ. ລະຫັດ JavaScript ທີ່ຖືກປະຕິບັດຢູ່ໃນດ້ານຂອງຕົວທ່ອງເວັບແມ່ນຖືກແທນທີ່ດ້ວຍຊັ້ນທົ່ວໄປທີ່ເອີ້ນຕົວຈັດການທີ່ຕັ້ງຢູ່ດ້ານຫລັງ. ບໍ່ຈໍາເປັນຕ້ອງພັດທະນາໂດຍໃຊ້ JavaScript ສໍາລັບດ້ານຫນ້າ. ການປະຕິບັດການອ້າງອີງ Pusa ແມ່ນຂຽນໃນ PHP ແລະໄດ້ຮັບອະນຸຍາດພາຍໃຕ້ GPLv3. ນອກເຫນືອຈາກ PHP, ເຕັກໂນໂລຢີສາມາດຖືກປະຕິບັດໃນພາສາອື່ນ, ລວມທັງ JavaScript / Node.js, Java, Python, Go ແລະ Ruby.

Pusa ກໍານົດອະນຸສັນຍາການແລກປ່ຽນໂດຍອີງໃສ່ຊຸດຄໍາສັ່ງຫນ້ອຍທີ່ສຸດ. ເມື່ອຫນ້າເວັບໂຫຼດ, ຕົວທ່ອງເວັບຈະໂຫລດເນື້ອຫາ DOM ພື້ນຖານແລະຫຼັກ JavaScript ຂອງ Pusa-Front. Pusa-Front ສົ່ງເຫດການຂອງຕົວທ່ອງເວັບ (ເຊັ່ນການຄລິກ, ມົວ, ຈຸດສຸມແລະການກົດແປ້ນພິມ) ແລະຕົວກໍານົດການຮ້ອງຂໍ (ອົງປະກອບທີ່ເຮັດໃຫ້ເກີດເຫດການ, ຄຸນລັກສະນະຂອງມັນ, URL, ແລະອື່ນໆ) ໄປຫາຕົວຈັດການເຄື່ອງແມ່ຂ່າຍ Pusa-Back ໂດຍໃຊ້ຄໍາຮ້ອງຂໍ Ajax. ອີງຕາມຂໍ້ມູນທີ່ໄດ້ຮັບ, Pusa-Back ກໍານົດຕົວຄວບຄຸມ, ປະຕິບັດ payload ແລະສ້າງຊຸດຄໍາສັ່ງຕອບສະຫນອງ. ໄດ້ຮັບການຕອບສະຫນອງຄໍາຮ້ອງຂໍ, Pusa-Front ປະຕິບັດຄໍາສັ່ງ, ການປ່ຽນແປງເນື້ອໃນຂອງ DOM ແລະສະພາບແວດລ້ອມຂອງຕົວທ່ອງເວັບ.

ສະຖານະຂອງ frontend ແມ່ນຖືກສ້າງຂຶ້ນແຕ່ບໍ່ໄດ້ຄວບຄຸມໂດຍ backend, ເຊິ່ງເຮັດໃຫ້ການພັດທະນາສໍາລັບ Pusa ຄ້າຍຄືກັບລະຫັດສໍາລັບບັດວີດີໂອຫຼື Canvas, ບ່ອນທີ່ຜົນຂອງການປະຕິບັດບໍ່ໄດ້ຖືກຄວບຄຸມໂດຍນັກພັດທະນາ. ເພື່ອສ້າງຄໍາຮ້ອງສະຫມັກແບບໂຕ້ຕອບໂດຍອີງໃສ່ Canvas ແລະ onmousemove, ມັນເປັນໄປໄດ້ທີ່ຈະດາວໂຫລດແລະໃຊ້ script JavaScript ເພີ່ມເຕີມຢູ່ຝ່າຍລູກຄ້າ. ໃນບັນດາຂໍ້ເສຍຂອງວິທີການ, ຍັງມີການໂອນສ່ວນຫນຶ່ງຂອງການໂຫຼດຈາກ frontend ກັບ backend ແລະການເພີ່ມຄວາມຖີ່ຂອງການແລກປ່ຽນຂໍ້ມູນກັບເຄື່ອງແມ່ຂ່າຍ.

ໃນບັນດາຂໍ້ໄດ້ປຽບແມ່ນ: ການກໍາຈັດຄວາມຕ້ອງການສໍາລັບການມີສ່ວນຮ່ວມຂອງນັກພັດທະນາດ້ານຫນ້າຂອງ JavaScript, ລະຫັດລູກຄ້າທີ່ມີຄວາມຫມັ້ນຄົງແລະຫນາແຫນ້ນ (11kb), ການບໍ່ສາມາດເຂົ້າເຖິງລະຫັດຕົ້ນຕໍຈາກທາງຫນ້າ, ບໍ່ຈໍາເປັນຕ້ອງມີ REST serialization ແລະເຄື່ອງມືເຊັ່ນ gRPC, ກໍາຈັດ ບັນຫາຂອງການປະສານງານການຮ້ອງຂໍເສັ້ນທາງລະຫວ່າງ front-end ແລະ back-end.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru