ทำความรู้จัก HTML DOM

HTML DOM เป็นหนึ่งในความลับของ Web Developer เก่งๆ เชื่อไหมว่า โปรแกรมเมอร์ส่วนใหญ่ไม่รู้จัก DOM ทั้งๆ ที่ใช้กันอยู่บ่อยๆ เช่น document.getElementById(“element”); หลายคนคงร้องอ๋อ…

อย่ามองข้ามเรื่อง DOM นะครับ DOM เป็นพื้นฐานสำคัญในการพัฒนาเว็บยุคใหม่ Javascript Library หลายๆ ยี่ห้อที่เรารู้จัก สร้าง method ครอบ DOM นี่แหละครับ ตัวอย่างเว็บดังๆ ที่ใช้ Javascript Library คือ Twitter, Facebook, WordPress,…

ปัญหาสำคัญของโปรแกรมเมอร์ส่วนใหญ่คือ แก้ไขหรือปรับปรุง Javascript Library เองไม่ได้ เพราะไม่มีพื้นฐานที่ดีใน Javascript และ HTML DOM มีหลายๆ คนปฏิเสธ Javascript ไปเลยก็มี เด็กจบใหม่ส่วนใหญ่มีความเชื่อผิดๆ ว่า Javascript เป็นภาษาที่ใช้สร้างลูกเล่นในเว็บ ไม่ได้มีความสำคัญอะไร และเป็นสคริปต์ที่น่ารำคาญ เพราะทุกครั้งที่เปิดไดอารี่ออนไลน์ของเพื่อน ชอบมี popup ขึ้นมาบ่อยๆ เพียงแค่มุมมองเล็กๆ ที่อคติ เราอาจจะพลาดโอกาสสำคัญๆ ที่จะเรื่องรู้อะไรใหม่ได้ 

DOM (Document Object Model) คือการจัดเอกสาร HTML ให้อยู่ในรูปแบบของ DOM Tree โดยนิยาม objects และ properties เพื่อให้โปรแกรมหรือสคริปต์ สามารถปรับเปลี่ยนโครงสร้าง, ข้อมูล และ styles ของ HTML DOM ผ่าน methods ได้

DOM แบ่งออกเป็น 3 ส่วน

1. Core DOM – การจัดรูปแบบ DOM Tree สำหรับทุกๆ เอกสาร
2. XML DOM – การจัดรูปแบบ DOM Tree สำหรับเอกสาร XML
3. HTML DOM – การจัดรูปแบบ DOM Tree สำหรับเอกสาร HTML

รูปที่ 1

จากรูป 1 เป็นการเปรียบเทียบเอกสาร HTML เมื่อถูกจัดรูปแบบเป็น DOM Tree ถ้าดูดีๆ เหมือนรากต้นไม้ที่แตกสาขา โดยแต่ละกล่อง เราเรียกว่า Node เพราะฉะนั้นรูปที่ 1 คือ DOM Node Tree นั่นเอง

คำถามต่อแล้ว DOM Node Tree คืออะไร?
คือการนิยามแต่ละ Node ใน DOM Node Tree เราอาจจะเคยได้ยิน Keyword นี้กันบ้าง เช่น Node Parents, Children และ Siblings มาดูสิว่า เค้าอธิบายว่ายังไงกันบ้าง

รูปที่ 2

1. ในหนึ่ง Node Tree (ใน 1 เอกสาร HTML นั่นแหละ) จะมี Node เพียงแค่อันเดียวที่อยู่บนสุด เราเรียกว่า Root
2. ทุกๆ Node ยกเว้น Root จะต้องมี 1 Parent Node (ลูกๆ ยังต้องมีพ่อกะแม่ผู้ให้กำเนิด)
3. ใน 1 Node จะมีหรือไม่มีลูก (Children) ก็ได้
4. Leaf คือ Node ที่ไม่มีลูก (Children) จำนวนลูกเท่ากับ 0 นั่นเอง
5. Siblings คือ Nodes ที่มี Parent Node เดียวกัน (เป็นพี่น้องกันนี่เอง)

HTML DOM Properties และ Methods
ยกตัวอย่างบางส่วนของ properties มาให้เห็นกัน สมมติ Node x คือ Tag H1 ดูรูปที่ 1 ประกอบ

1. x.innerHTML – แทนที่ข้อมูลใน Node x ด้วย Tag HTML โดย method นี้จะ compile Tag HTML ให้
2. x.innerText – แทนที่ข้อมูลใน Node x ด้วย Text ธรรมดา โดย method นี้จะไม่ compile Tag HTML ให้ ถ้าใส่ Tag HTML ตัวมันเองจะมองว่าเป็นเพียงแค่ Text
3. x.nodeName – ชื่อของ Node x คือ “H1”
4. x.parentNode – parent node ของ x คือ “BODY”
5. x.childNodes – child nodes ของ x (ลูกของ H1 คือ #text, #text คือ Text Node)
6. x.nodeValue – value ของ x คือ null แต่ value ของ #text ซึงเป็นลูกของ x คือ “My header”

ยกตัวอย่างบางส่วนของ methods

1. x.getElementById(id) – เกทอิลิเมนต์ด้วย id ที่เรากำหนด, และ id ต้องมีหนึ่งเดียวในเอกสาร HTML
2. x.getElementsByTagName(name) – เกทอิลิเมนต์ด้วยชื่อ Tag ตามที่เรากำหนด ผลลัพธ์ที่ได้จะเป็น array ของ object เวลาเราจะอ้างอิงแต่ละ object คือ x.getElementsByTagName(“DIV”)[i].nodeType, i มีค่าได้ตั้งแต่ 0-n โดย n < x.getElementsByTagName("DIV").length
   Tip-Trick ในการจำ ถ้า methods ใด มี keyword แบบนี้ “getElements” ผลลัพธ์ที่ได้ต้องเป็น array
3. x.appendChild(node) – แทรก child node ใน x เช่น x.appendChild(document.createTextNode (“ลงทุนกับสลากออมสิน“)); คือ การสร้าง Text Node แทรกใน Node x
4. x.removeChild(node) – remove child node จาก x เช่น x.removeChild(x.firstChild) เมื่อกี้ผมแทรก Text Node อันใหม่ใน x ทำให้ x มีลูก 2 ตัว ผมก็ remove ลูกตัวแรกออก ก็คือ #text ที่มี value เท่ากับ “My header” ใน Tag H1 ก็จะเหลือแต่ #text ที่มี value เท่ากับ “ลงทุนกับสลากออมสิน” เพียงตัวเดียว แค่นั้นเอง 
5. ที่มา:http://honglub.com/web-applications/html-dom-tutorial/

Config Reverse Proxy สำหรับ Apache 2.4 เพื่อใช้งาน WebSocket

ผมเคยเจอคำถามและได้รับอีเมลบ่อยๆ ว่า “สามารถใช้ PHP กับ Node.js ได้หรือเปล่า?” คุยกันถึงรายละเอียดแล้วก็พบอีกว่าส่วนใหญ่พัฒนาเว็บด้วย PHP รันบน Apache web server กันอยู่แล้วแต่ต้องการใช้งาน WebSocket ซึ่งเขียนด้วย Node.js

ถามว่าใช้งานด้วยกันได้ไหม? ทำได้ครับแต่ต้องใช้กำลังภายในกันนิดนึง

ผมเคยเขียนถึงไปแล้ว ว่าถ้าจะใช้งาน WebSocket แบบเนียนๆ เสมือนรันบน web server เดียวกัน (ไม่ต้องระบุ port) ก็ต้องทำ reverse proxy และอาจจะต้องเพิ่ม software อื่นๆ เข้ามาใน stack ด้วยเพราะ Apache 2.2 ลงไปยังไม่รองรับ WebSocket แต่ใน Apache 2.4 สามารถใช้งานได้แล้วครับ ซึ่งวิธีทำก็ไม่ยุ่งยากเลยเหมือนทำ reverse proxy ทั่วไป แต่เพิ่มขั้นตอนนิดหน่อยตามนี้ครับ

Enable modules ที่จำเป็น

ขั้นตอนแรกก็ enable modules ที่ต้องใช้งานก่อนซึ่งก็คือ  proxy , proxy_http  และที่สำคัญเลยคือproxy_wstunnel เราจะใช้ module นี้ในการคุยกันระหว่าง client-server ผ่าน WebSocket

1 2	$sudo a2enmod proxy proxy_http proxy_wstunnel

enable แล้วโปรแกรมจะแนะนำให้ restart ยังไม่ต้อง restart ก็ได้นะครับเพราะเราจะ config เพิ่มอีกค่อย restart ทีเดียวเลย

Config Apache 2.4 ให้รองรับ WebSocket

ให้ cd เข้าไปไดเรกทอรีที่เก็บไฟล์ config ของคุณครับ อย่างเช่นผมใช้ Ubuntu ก็จะอยู่ที่ /etc/apache2/site-enabled/  เปิดไฟล์ config virtual host ที่ต้องการขึ้นมาได้เลย (ถ้าใช้ default ก็เปิดไฟล์ 000-default.conf )

1 2	$sudo vim domainname.conf

เพิ่ม directive นี้เข้าไปก่อนครับ (แต่ละอันหมายความว่ายังไงไปอ่าน document กันเองนะครับ ในที่นี้ผมขอข้ามไปละกัน)

1 2 3 4 5 6 7 8

ProxyRequests Off ProxyVia Off                                     <Proxy>   Order deny,allow   Allow from all </Proxy>

สมมุติว่าเรารัน Node.js app โดยใช้  transports: ['websocket']  ไว้ที่ port 10001 ก็เพิ่ม ProxyPass และ ReverseProxy ตามนี้

1 2 3

ProxyPass         /socket.io/1/websocket  ws://localhost:10001/socket.io/1/websocket ProxyPassReverse  /socket.io/1/websocket  ws://localhost:10001/socket.io/1/websocket

2 บรรทัดข้างบนคือบอกว่าถ้าเจอ /socket.io/1/websocket  จะเปลี่ยนไปคุยกันด้วย WebSocket protocol แทน

แต่…ช้าก่อน ยังไม่จบครับ เราต้องทำ reverse proxy ไป HTTP protocol เพื่อให้ client สามารถเรียกไฟล์ socket.io.js ได้ก่อน โดยเพิ่ม 2 บรรทัดนี้เข้าไป

1 2 3

ProxyPass        /ws   http://localhost:10001 ProxyPassReverse /ws   http://localhost:10001

เวลาเรียก socket.io.js ในหน้า HTML ก็ระบุเป็นแบบนี้

1 2	<script src="/ws/socket.io/socket.io.js"></script>

เสร็จแล้ว save และ ต้อง restart Apache ให้อ่าน config ใหม่ก่อนนะครับถึงจะใช้งานได้

1 2	$sudo service apache2 restart

ลองเข้าเว็บเปิด debugger คลิกแท็บ Networks ดูครับ ถ้าไม่มี error อะไรก็น่าจะใช้งานได้แล้ว ถ้ายังใช้งานไม่ได้ก็ลองปรับเปลี่ยน path ต่างๆ ดูเพราะส่วนมากปัญหาที่เจอก็เรื่อง path นี่แหละ

ลองทำดูนะครับ

 ที่มา:https://khasathan.in.th/archives/1060

Node.js – Web Workers

 โดยปกติ Node.js โดยใช้ event-loop ทำงานด้วย thread เพียง thread เดียว ปัญหาคือถ้ามี task ที่เป็น sync ทำงานนานๆ มันจะไป block event-loop (เพราะค้างอยู่ใน call stack) ทำให้โปรแกรมทำงานต่อไม่ได้แม้ตัวมันเองจะบอกว่าทำงานแบบ async ก็ตาม

เพื่อแก้ปัญหาดังกล่าวเลยเกิด Web Workers ขึ้น โดยสามารถแตก thread ไปประมวลผลโดย thread หลักไม่โดน block นอกจากแก้ปัญหาที่ว่านี้แล้วในงานที่ต้องการประมวลผลหนักๆ ก็สามารถแตก thread สร้างหลายๆ worker ช่วยกันทำงานได้ด้วย

module สำหรับ Node.js ดูได้จากลิงก์นี้ครับ https://www.npmjs.com/package/webworker-threads

Web Workers ใช้บน browser ได้ด้วยนะครับ (จริงๆ มันเริิ่มจาก browser ก่อนนั่นแหละ)

1. http://www.html5rocks.com/en/tutorials/workers/basics
2. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers 

ที่มา:https://khasathan.in.th/archives/991

Web service หรือ Web API สำคัญกับการพัฒนา Web application และ Mobile application ยังไง?

ถ้าใครที่คลุกคลีกับการทำเว็บมาตั้งแต่ยุคนั้นคงจะได้สัมผัสกับการทำเว็บไซต์ที่เริ่มตั้งแต่เป็นหน้าเว็บ HTML แห้งๆ อยากอัปเดตอะไรก็ต้อง FTP เข้าไปแก้ไขหน้า HTML เองจนจนมาถึงยุคที่ทุกอย่างเป็น dynamic ข้อมูลมีการเปลี่ยนแปลงตลอดเวลา ทุกอย่างเป็นไปอย่างอัตโนมัติด้วยโปรแกรม ฝั่ง user เองก็ได้รับประสบการณ์การใช้เว็บไซต์แบบใหม่คือสามารถเพิ่ม content ของตัวเองได้, แชร์ข้อมูลกับคนอื่นได้,  การพูดคุยกันแบบ real-time หรือแม้กระทั่งเป็นสื่อและเป็นเครื่องมือสำหรับทำธุรกิจ

เพื่อความสะดวกในการพัฒนาจึงต้องแยกการพัฒนาออกเป็น 2 ส่วนคือ Front-end และ Back-end

ส่วนฝั่ง developer เองก็ต้องพัฒนาทั้งทางด้านเทคนิคและกระบวนการทำงานด้วยเหมือนกัน ด้านเทคนิคที่ว่าก็คือภาษาโปรแกรมที่สามารถทำงานตามลอจิกสามารถรับ-ส่งข้อมูลผ่าน HTTP ซึ่งก็คือ CGI สมัยนั้นนิยมเขียนด้วย Perl จนมาถึงยุค PHP ที่สะดวกกว่า ง่ายกว่า ยืดหยุุ่นกว่าและถูกใช้มาเรื่อยๆ จนปัจจุบัน ฟีเจอร์เด็ดของ PHP ที่ทำให้เป็นที่นิยมคือสามารถเขียนแทรก tag HTML ได้แต่ก็กลายเป็นปัญหาในการพัฒนาภายหลังเพราะส่วนแสดงผลและลอจิกการทำงานผูกติดกันอยู่ ต่อมมาแนวคิด MVC (Model-View-Controller) ซึ่งบอกว่าควรจะแยกส่วนแสดงผล (View) ส่วนที่แทนตัวข้อมูล (Model)  และส่วนลอจิกการทำงานของโปรแกรม (Controller) เมื่อแต่ละส่วนไม่ขึ้นต่อกันก็จะทำให้กระจายงานได้ดีขึ้น (ต่างคนต่างไปทำงานส่วนที่ได้รับมอบหมาย) ทำงานได้ไม่ต้องรอกัน การเพิ่ม/ลดอะไรในโปรเจกต์ทำได้สะดวกและยืดหยุ่นขึ้น จนเกิดเป็น layer ของการพัฒนาเว็บไซต์คือฝั่ง Front-end และ Back-end

Web service หรือ Web API เข้ามาแทรกตรงไหนใน MVC?

ถึงตอนนี้พอจะมองออกไหมครับว่า Web service หรือ Web API เข้ามาแทรกตรงไหนใน MVC?

คำตอบก็คือส่วน Model ครับ ความจริงแล้วแนวคิดนี้ไม่ใช่อะไรใหม่ก็อาศัยแนวคิดดั้งเดิมของการแชร์ข้อมูลระหว่างกันโดยการกำหนดโครงสร้าง รูปแบบของข้อมูลแล้วเวลาเรียกใช้งานก็เรียกใช้ผ่าน interface ที่กำหนดโดยไม่ต้องเข้าถึงตัวข้อมูลจริงๆ (API ของภาษาโปรแกรมก็ใช้แบบนี้) หรือฐานข้อมูลเลยซึ่งตรงนี้เป็นแนวคิดของพวก ORM (ตัวอย่างที่ดังหน่อยก็เช่น Java Hibernate) แต่ถ้าต้องการส่งข้อมูลผ่านเครือข่ายส่วนมากมักส่งด้วย message อันนี้แหละครับคือแนวคิด Web service หรือ Web API ที่เราคุ้นเคย แม้ข้อมูลจะเป็น String แต่ก็มีการนิยามตัวข้อมูลเป็นโครงสร้างบอกว่าส่วนไหนคืออะไรแทนที่จะใช้ Text เพียวๆ ก็มีการใช้ XML แทนหรือ JSON ซึ่งช่วงหลังนิยมใช้มากกว่าเพราะเข้าใจง่ายกว่าไม่มี ข้อมูลเล็กกว่าเพราะไม่มีชื่อ tag เปิด/ปิดเหมือน XML  แถมฝั่ง front-end ยังเอาไปใช้ได้ทันทีเพราะ JSON เป็นเหมือน object ของ Javascript ซึ่งเป็นภาษาที่นิยมใช้ฝั่ง front-end แม้ว่า ORM หรือ Web service จะทำงานต่างกันแต่มีจุดประสงค์เดียวกันคือฝั่งที่เรียกใช้ไม่จำเป็นต้องรู้การทำงานเบื้องหลังเลย คือมีหน้าที่ใช้อย่างเดียวทำให้การทำงานสะดวกมากขึ้น ทำงานได้เร็วขึ้นเพราะ data ถูกเตรียมไว้ให้หมดแล้ว

Web service หรือ Web API เนี่ยมันดีกับการพัฒนา Web application และ Mobile application ยังไง?

เล่ามาซะยาวยืดแล้วตกลง Web service หรือ Web API เนี่ยมันดีกับการพัฒนา Web application และ Mobile application ยังไง? ผมขออธิบายเป็นข้อๆ ตามนี้แล้วกันครับ

1. Web service เดียว API เดียวใช้ได้ทั้ง Web application และ Mobile application

เมื่อเราแยกส่วนแสดงและส่วน data model ออกจากกันแล้ว ก็แล้วแต่เราหละครับทีนี้ว่าจะเอาไปแสดงผลแบบไหนบนอุปกรณ์อะไร สมมุติว่าเรามี Web service ให้บริการข้อมูลอยู่ตัวหนึ่ง request ไปจะได้ข้อมูลกลับคืนมาเป็น JSON นักพัฒนา web application หรือ mobile application ก็เอาไป render แสดงผลต่อได้แล้ว ถ้าออกแบบโครงสร้างของ JSON ดีๆ ก็สามารถจับโยนเข้า template engine render ง่ายๆ เลยนะครับ

2. Front-end developer ทำงานสะดวกขึ้น

front-end developer != designer นะครับ แต่หมายถึงคนที่เอา HTML/CSS/Javascript มาสร้างสรรค์ให้เป็น UI ตามที่ designer ออกแบบไว้ได้ อาวุธคู่กายของ คงหนีไม่พ้น Javascript แต่ตัว Javascript เองเป็นภาษาที่ทำงานบนเบราว์เซอร์ฝั่ง client  หมายความว่าเราไม่สามารถ query ข้อมูลจากฐานข้อมูลฝั่ง server ได้

แต่ถ้ามี web service หรือ web api ให้ front-end developer เรียกใช้ก็จะไม่มีปัญหานี้อีกต่อไปครับเพราะ สามารถเขียน AJAX ไปเรียกข้อมูลเอาไปแสดงผลได้เลย

3. Back-end developer ทำงานสะดวกขึ้น

ถึง Web service และ Web API จะทำงานฝั่ง server หรือ back-end อยู่แล้วแต่ application เดี๋ยวนี้มี layer การทำงานข้างหลังหลาย layer นะครับ ซึ่ง back-end developer แต่ละคนก็ใช่ว่าจะคุ้นเคยกับ database ทุกคนหรือคุ้นเคยดีแต่การเขียนคำสั่ง SQL บ่อยๆ ก็เป็นเรื่องน่าเบื่อหน่ายในการพัฒนาซอฟต์แวร์เหมือนกัน และการที่มี Web API ก็ช่วยให้การทำงานตรงนี้ง่ายขึ้นเหมือนกันเพราะ developer รู้แค่ว่าเมื่ออยากได้ข้อมูลต้อง request ไปที่ไหนและ return อะไรมาบ้างก็พอแล้ว

 4. Project management สะดวกขึ้น

ข้อนี้เหมือนแถ แต่ผมไม่ได้แถนะครับ ลองนึกตามดูว่าถ้าทีมของเราซึ่งอาจประกอบไปด้วย  Project manager, System Analysis, Back-end developer และ Front-end developer ต้องทำแอปขึ้นมาสักแอปหนึ่ง เวลาวางแผนการทำงานถ้าเป็นระบบเดิมอาจต้องทำเป็น step 1-2-3 คือ design และ analysis ร่วมกันจากนั้นก็ให้ back-end developer ไปทำ front-end developer ก็ต้องรอจน back-end developer ทำเสร็จก่อนถึงจะทำต่อได้ซึ่งบางทีก็ใช้เวลามากโดยไม่จำเป็นเพราะงานบางอยากเราสามาถทำ parallel กันได้

สมมุติว่าเรามี Web API เป็น core หลักเป็นแกนกลางของระบบตอน design และ analysis ก็ออกแบบ fix ไปเลยว่า back-end ต้องคืนค่าอะไรบ้าง และ front-end ต้องส่งค่ายังไงบ้าง เสร็จแล้วก็สร้าง mock up ของข้อมูลเพื่อให้ front-end developer สามรถเอาไปทำงานต่อได้เสมอว่าเรียก service จาก back-end จริงๆ ส่วน back-end ก็พัฒนาข้างหลังไป เมื่อทั้ง 2 ส่วนทดสอบจนไม่เจอข้อผิดพลาดแล้วก็เปลี่ยน end-point ของ service ชี้ไปที่ service ที่ใช้งานจริง

จากที่อธิบายไปข้างต้นจะเห็นว่าฝั่ง front-end และ back-end จริงๆ แล้วก็สามารถทำงาน parallel กันไปได้ โดยไม่ต้องรอกันเลย การบริหารเวลาของ project manager ก็ทำได้ง่ายขึ้นเวลาที่ทำก็สั้นลง มีเวลา release ซอฟต์แวร์ให้ Tester ทดสอบแล้วรับ feedback มาแก้ไขได้อีก เวลาเอาไปใช้งานจริงข้อผิดพลาดจากโปรแกรมก็น้อยลง

5. ช่วยกระจายข้อมูลและเกิด Third party application มากมาย

Success story ในหัวข้อนี้ที่อยากจะยกตัวอย่างว่า Web API ทำให้เกิดการกระจายข้อมูลและ Third party application ได้ยังไง ลองนึกถึง RSS และ Social API ต่างๆ ดูครับ Web API นี้ไม่เพียงแต่จะใช้เป็น Private service เท่านั้นบางครั้งก็นำมาให้บริการเป็น Public service โดยการเปิด API ให้ developer เข้าถึงได้และนำข้อมูลไปใช้งานต่อซึ่งมีทั้งฟรีและเสียตังค์ ซึ่งปัจจุบันก็เป็นโมเดลธุรกิจแบบหนึ่งในการทำธุรกิจไอทีได้เหมือนกัน

6. ความปลอดภัยในการแชร์ข้อมูลกับคนอื่น

แต่ก่อนถ้าเราจะแชร์ข้อมูลเราทำยังไงกันบ้างครับ? วิธีที่นิยมทำกันคือการให้ username และ password ของ database ไปเลยซึ่งขัดกับหลัก security อย่างมาก หรือดีขึ้นมาหน่อยคือ set server เป็น user ชั่วคราวและเตรียมข้อมูลหลอกๆ ที่มีโครงสร้างเหมือนกับข้อมูลจริงไว้ให้แต่ก็เสียเวลามากเช่นกัน

โปรเจกต์บางโปรเจกต์จำเป็นต้องใช้คนจากภายนอกหรือ outsource ความปลอดภัยข้อมูลนอกจากจะป้องกันด้วยการทำสัญญาไม่เปิดเผยข้อมูลแล้ว การป้องกันทางเทคนิคก็ควรจะทำด้วยเหมือนกัน การเปิดให้เข้าถึงผ่าน Web service และ Web API ก็ช่วยเรื่องความปลอดภัยได้ระดับหนึ่งเพราะไม่ต้องยุ่งกับ database โดยตรง

7. การขยาย application (scaling) ทำได้ง่ายกว่า

อย่างที่ผมได้บอกไปก่อนหน้านี้ครับว่า back-end มันมีหลาย layer ข้างหลัง URL ที่เราเรียกไปข้างหลังอาจจะมี server ซึ่งทำงานอยู่หลัง proxy, load balance อีกที ในกรณีที่มีการใช้งานเยอะเราอาจจะต้องเพิ่ม server ข้างหลังให้มากขึ้นเราก็สามารถเพิ่มเข้าไปได้เลยโดยที่ฝั่ง client ไม่จำเป็นต้องทำอะไรเพิ่มเลยครับเพราะเรียกใช้งานผ่าน URL ของ Proxy, load balance อยู่แล้ว

และด้วยความที่มันคุยกันด้วย message (String) นั่นก็หมายความว่านอกจากเราทำ cache ได้ตั้งแต่ database แล้วยังสามารถ cache ในอีก layer นึง จะใส่ซอฟต์แวร์สำหรับทำ cache พวก Memcached, Vanish  หรือ NoSQL อย่าง Redis ก็แล้วแต่จะออกแบบ นอกจากจะ cache ฝั่ง server ได้แล้วด้วยความที่เป็น String ก็ cache ที่ฝั่ง client ได้อีก การที่ทำ cache ได้หลาย layer แบบนี้ก็ทำให้ประสิทธิภาพโดยรวมของ  application ดีขึ้นตามไปด้วย

สรุป

มาถึงตรงนี้ก็น่าจะพอนึกภาพออกนะครับว่า Web service หรือ Web API สำคัญกับการพัฒนา Web application และ Mobile application ยังไง ลองศึกษาและนำมาปรับใช้งานในการพัฒนาซอฟต์แวร์ดูครับเผื่อชีวิต developer ของท่านจะง่ายขึ้น 

ที่มา:https://khasathan.in.th/archives/792

Javascript และ NodeJS วน loop แบบมี delay ยังไงนะ?

เนื่องจาก Javascript และ NodeJS (จริงๆ ก็ภาษาเดียวกัน) ไม่มี function สำหรับการทำ delay หรือ sleep มาให้เพราะถูกออกแบบมาให้ทำงานบนเบราว์เซอร์แต่แรกจึงมีแค่ setTimeout() และ setInterval() เท่านั้นซึ่งก็เป็น callback based ทั้งคู่ ถ้าใช้งานปกติทั่วไปมันให้ผลเหมือนกับ function delay หรือ sleep ในภาษาอื่นครับ แต่ถ้าใช้ใน loop จะไม่ให้ผลอย่างนั้น

ถ้าต้องการวน loop แล้วให้มี delay ล่ะจะทำยังไง? ก็ทำได้หลายเทคนิิคครับตั้งแต่ใช้ time เข้ามาช่วยคือบวกเวลาปัจจุบันเพิ่มด้วยเวลาที่อยาก delay วนรอบรอจนกว่าจะได้เวลาที่ต้องการแล้วก็จบ loop วิธีนี้ถึงจะทำงานได้เหมือนกันแต่มันใช้ CPU เยอะมาก วิธีที่ดีกว่าคือดัดแปลงจาก setTimeout() ตามตัวอย่างโค้ดข้างล่างนี้เลย ดัดแปลงกันตามสะดวก

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

var delay_loop = function (list) {     (function loop(i) {         setTimeout(function () {             console.log(i);             i -= 1;             if (i) {                 loop(i);             }     }, 1000); // delay 1 sec during each iterate   }(list.length)); };   var sample_list = [1, 2, 3, 4, 5]; delay_loop(sample_list);