1. การที่ Facebook ขอให้ใคร ๆ เลิกใช้ FBML ซึ่งตัวเองปั้นมาเองกับมือ แต่ยังคงสนับสนุนอยู่อีกพักใหญ่ ๆ และไม่รู้ว่าจะถึงเมื่อไหร่ที่จะให้เลิกใช้เด็ดขาดไปเลย
2. บังคับให้แอปทุกตัวต้องเปลี่ยนการชำระเงินในทุก ๆ วิธี มาเป็นใช้ Facebook Credits แทน โดยทาง Facebook จะหักหัวคิวอร่อยเหาะที่ 30% ของมูลค่าการซื้อขายในแต่ล่ะครั้ง และถ้าใครไม่ทำตามแล้วตรวจเจอก็จะโดนแบน เรียกว่าโดนไม่ใช่น้อย
3. สั่งให้ทุกแอปต้องมี HTTP Secure เพื่อการรักษาความปลอดภัยที่ล้ำลึก จนไม่ว่าหน้าไหนก็ไม่สามารถจะล่วงล้ำก้ำเกินเข้าไปได้ (ทำให้เหมือนว่าแอปที่สร้างขึ้นมา สำคัญขนาดแอปของสถาบันการเงินเลยทีเดียวเชียว)

พวกเราเคยเอะใจกันมั้ยครับว่า การที่เราต้องเปลี่ยนโน่นนี่นั่นตามเจ้าของ Platform มันทำให้เราเกิดต้นทุน แถมต้นทุนดังกล่าวก็ไม่มีใครมาจ่ายให้เราซะด้วย เราต้องเป็นคนแบกรับเอาไว้เอง!!!

ผมเลยเริ่มมองว่า การทำแอปเพื่อเชื่อมกับ Facebook นั้น เราต้องมากำหนดความสัมพันธ์กันแล้วล่ะ ว่าเราจะสนิทสนมสนุกสนานกับ Facebook แค่ไหน จะเกาะ Facebook ทั้งตัว หรือจะเกาะแค่ลำไส้ใหญ่ หรือจะเกาะแค่ไส้ติ่งของ Facebook ดี?

พอมอง ๆ ไปว่ากลไกในการต่อเชื่อมกับ Facebook มันมีกี่ระดับบ้าง ก็พอจะคลี่ออกมาได้เป็นสามแบบเหมือนกัน ได้แก่

1. ใช้ Authentication, ใช้ Graph API, วางไว้ใน Canvas และต้องใช้ Facebook Credits – แบบนี้เห็นกันอย่างเยอะ เช่น พวกเกมที่ต้องเล่นผ่านหน้าจอของ Facebook เป็นต้น
2. ใช้ Authentication, ใช้ Graph API, ไม่วางไว้ใน Canvas แต่ใช้หน้าเว็บของตัวเอง และไม่ใช้ Facebook Credits – แบบนี้เป็นเฉพาะบางเกมหรือบางแอป ที่ต้องการระบบเครือข่ายสังคมของ Facebook แต่ปฏิเสธที่จะอยู่ในอาณาบริเวณหน้าจอของ Facebook เพราะว่าหน้าจอของ Facebook มันไม่เหมาะสมหรือสอดคล้องกับภาพลักษณ์ของเกมหรือแอป
3. ใช้ Authentication, ไม่ใช้ Graph API, ไม่วางไว้ใน Canvas แต่ใช้หน้าเว็บของตัวเอง และไม่ใช้ Facebook Credits – เราจะไม่เห็นแบบนี้ในเกมหรือแอป แต่จะเห็นในเว็บจำพวก BLOG ที่เขาเอาไว้เขียนเล่าเรื่องราวส่วนตัว อะไรประมาณนั้น

ทั้งสามแบบล้วนต้องใช้ Authentication ของ Facebook และต้องลงทะเบียนแอปกับ Facebook อยู่ดี ซึ่งมันก็คงหนีไม่พ้นที่จะต้องทำตามนโยบายของ Facebook ต่อไป ไม่ว่าจะเป็นการเพิ่ม HTTP Secure เพื่อให้เกิดความปลอดภัย บลา ๆ ๆ เป็นต้น

โดยสรุปแล้วผมมองว่าการเกาะกับ Platform ที่มันเป็นที่นิยมและมีชื่อเสียงนั้น มันเป็นเรื่องที่ดี เพราะเราจะทุ่นแรงในการปฏิบัติหลาย ๆ อย่าง เพราะ Platform มันจัดการให้หมดแล้ว แต่ทว่า ถ้า Platform มันเปลี่ยนบ่อยซะเหลือเกิน แถมเปลี่ยนแต่ล่ะครั้งก็เกิดต้นทุนเงินตราและต้นทุนแรงงาน อันนี้เราก็คงต้องมาพิจารณากันแล้วล่ะมั้ง ว่าเราจะเกาะลำไส้ใหญ่เขา หรือเราจะเกาะเขาแค่ปลายไส้ติ่งดี เพื่อเวลาที่เราจะฉีกตัวออกมาใหญ่ของเราเอง พังผืดจากลำไส้ใหญ่ของเขา มันจะได้ไม่มายึดติดเราจนเราขยับไม่ได้อ่ะ

โดยจะชวนพวกเราคุยสั้น ๆ เกี่ยวกับ Facebook Application แบบว่าสั้นจริง ๆ เพราะแบตกล้องมันเล่นหมดดื้อ ๆ ก็เลยถ่ายมาได้แค่นี้

httpv://www.youtube.com/watch?v=9ZlxrYeUYTg

อธิบายภาพข้างบนสั้น ๆ ได้ดังนี้

1. คุณต้องติดตั้ง Facebook Canvas เป็น, เข้าใจใน Facebook Graph API และเข้าใจใน Facebook Client Libraries (ทั้งหมดฟรี)
2. คุณต้องจดทะเบียน Domain (เสียตังค์) กับ Domain Registrar (Domain ที่ว่าก็คือ ไอ้พวก http://www.yourdomain.com อะไรเทือกนั้นแหล่ะ) เช่น Godaddy เป็นต้น
3. คุณต้องจดทะเบียน DNS (เสียตังค์) กับ DNS Provider เพื่อที่คุณจะได้ผูก Domain ของคุณเข้ากับ Amazon EC2 ได้
4. คุณต้องสมัครเพื่อใช้งาน Amazon EC2 (ไม่ต้องเสียตังค์) แล้วเข้าไปสร้าง Application + Db Instance (เสียตังค์ตามการใช้งาน) โดยสร้างขึ้นมาแค่ Instance เดียวก็พอ (ต่อไปถ้าคุณเก่ง คุณสามารถสร้างเยอะ ๆ ก็ได้นะเออ)
5. คุณต้องสร้าง Elastic IP ขึ้นมา (เสียตังค์) เพื่อให้ Instance ของคุณ สามารถติดต่อกับโลกภายนอกได้ โดยสร้างแค่ IP เดียวก็พอ (ก็ใช้แค่ Instance เดียวไง ก็เลยใช้แค่ IP เดียวก็พอ)
6. บังเอิญว่า Instance ใน Amazon EC2 เป็นพวกความจำสั้น ดังนั้น ถ้ามันโดน Restart หรือ Terminate เมื่อไหร่ล่ะก็ มันจะลืมทุกอย่างไปหมดเลย (รวมทั้ง Code และ DB ด้วย) ดังนั้น น่าจะเป็นการดี หากเราจะสร้าง Elastic Block Store ขึ้นมา (เสียตังค์) เพื่อเอามาเป็นที่พักข้อมูลจาก Instance เผื่อว่า Instance มันล่มหรืออะไรยังไง มันจะได้มีตัวสำรอง
7. แต่ถ้าคุณคิดว่า Elastic Block Store จะไม่ชัวร์ กลัวว่าตัวมันเองก็อาจจะล่ม คุณก็สามารถจะติดตั้ง Snapshot To S3 (เสียตังค์) เพื่อให้มันทยอยโอนข้อมูลของคุณ ไปเก็บไว้ใน Bucket (เสียตังค์) ของ Amazon S3 ก็ได้ (คุณต้องสมัครเพื่อขอใช้ Amazon S3 อันนี้ฟรี ไม่เสียตังค์)

สรุปว่าจะประมวลผล Facebook Application บน Amazon EC2 ก็ต้องจ่ายพอตัวเหมือนกัน แต่ถ้าทำออกมาดี ๆ ก็น่่าจะคุ้มอ่ะนะ เพราะถ้าให้ไปประมวลผลบน Shared Hosting ก็คงไม่ได้ เพราะทรัพยากรจำกัดจำเขี่ยเหลือเกิน เกิดผีเข้าผีออก มีคนเข้า Facebook Application ของเราเยอะขึ้นมา ไปทำ Shared Hosting เขาล่ม เดี๋ยวเขาจะเฉดหัวออกมาแทบไม่ทัน

ส่วนจะไปประมวลผลบน Dedicated Server หรือ Virtual Private Server ก็ยุ่งยาก ต้องติดตั้งทุกอย่างเองทั้งหมด (Amazon EC2 มันเทพ สั่งสร้าง Instance โป้งเดียว มันติดตั้งระบบปฏิบัติการและปรับแต่งทุกอย่างให้หมดเลย)

ยิ่งเป็น Co-Location ก็ยิ่งแล้วใหญ่ เพราะเดี๋ยวนี้ฮาร์ดแวร์มันทันสมัยขึ้นแทบทุกวี่ทุกวัน จะให้เช่าซื้อ Server มาเป็นของตัวเองมันจะไม่คุ้ม แบบว่ายังไม่ทันไร Server ที่มีก็ตกยุคซะแล้ว หรือถ้าไม่ตกยุค แต่ต้องมาอัด RAM ทำ Server Farm เองก็หลังแอ่นเหมือนกัน

1. คุณต้องรู้และเข้าใจภาษา PHP ในระดับหนึ่ง (ยิ่งเก่งยิ่งดี) เพราะมันเป็นภาษาทางการในการพัฒนา Facebook Application (ภาษาอื่นก็มี แต่ไม่นับเป็นภาษาทางการ)
2. คุณต้องรู้และเข้าใจหลักการของ Object Oriented Programming ซึ่งผมคิดว่าคนที่เรียนคอมพิวเตอร์มาทุกคน ล้วนเคยถูกกำหนดให้เรียนวิชานี้ทั้งนั้น (สมัยนี้นะ) ส่วนจะเรียนเป็นบทหนึ่งบทในรายวิชา หรือจะเรียนเป็นรายวิชาสามหน่วยกิต อันนี้ก็สุดแล้วแต่
3. คุณต้องรู้และเข้าใจภาษา Javascript ในระดับหนึ่ง (ยิ่งเก่งยิ่งดี) เพราะมันเป็นภาษาที่สร้างลูกเล่นเสริมให้กับ Facebook Application ของคุณ
4. คุณต้องรู้และเข้าใจหลักการของ Web Service เพราะมันเป็นกุญแจสำคัญในการสื่อสารระหว่าง Facebook Application กับ Facebook Platform

ทีนี้เรามาดูเรื่องที่น่าสนใจเรื่องหนึ่งกัน นั่นก็คือ Facebook Application มีทั้งหมด 3 แบบ แบบแรกเป็น Desktop Application, แบบสองเป็น Web Application และแบบสามเป็น Mobile Application

แต่ล่ะแบบล้วนมีพื้นฐานทาง Web Service ที่เหมือนกัน แต่ว่ามีกลไกปลีกย่อยที่แตกต่างกันตาม Platform ของตัวเอง โดยหัวข้อนี้จะเน้นเกี่ยวกับแบบ Web Application เป็นสำคัญ

วิธีการเรียนรู้ที่ดีที่สุดก็คือการเรียนจากคนอื่น (ผมขี้เกียจเขียนอธิบาย) ดังนั้น ขอให้พวกเราเข้าไปดูบทความที่กูรูเขียนเอาไว้แล้วก่อน (เพื่อเป็นการปูพื้นฐาน) ตามหัวข้อข้างล่างนี้

1. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP)
2. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) (2)
3. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) (3)
4. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) (4)
5. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) ฉบับปรับปรุง Graph API

โอเค ผมจะัถือว่าพวกเราได้อ่านบทความในย่อหน้าข้างบนครบทุกอันแล้วนะ ทีนี้เรามาอธิบายส่วนของพื้นฐาน, การขยายความ และ ส่วนเสริมกันดีกว่า

สิ่งแรกที่จะบอกก็คือ Facebook เขาก็มีพัฒนาการของเขา ดังนั้น เขาย่อมไม่หยุดอยู่กับที่ ปรับโน่นเปลี่ยนนี่ไปเรื่อย ๆ รวมทั้ง API ของเขาด้วย โดยหลังจากที่ปล่อยให้มี API เดิมให้ใช้มาราวสองถึงสามปี จนกระทั่งผู้พัฒนา Facebook Application ใช้กันจนคล่อง ติดกันจนงอมแงมแล้ว เมื่อกลาง (ค่อนปลาย) ปี พ.ศ. 2553 ที่ผ่านมา ทาง Facebook ก็ออก API ตัวใหม่ออกมา นัยว่าเพื่อจะได้ใช้ง่ายขึ้น ดีขึ้น สะดวกขึ้น บลา ๆ ๆ ๆ ๆ โดยประกาศว่าให้ Facebook Application ใหม่ ๆ ที่ถูกสร้างขึ้น จงสร้างด้วย API ใหม่โดยพลัน ส่วน Facebook Application เก่า ๆ จะยังใช้ API เดิมได้อยู่ (แต่คงอีกไม่นาน)

นอกจากนี้ทาง Facebook ก็ตัดสินใจยกเลิกภาษาของตัวเอง (Facebook สร้างภาษา FBML ออกมา มันแบบ คล้าย ๆ กับ HTML แต่ไม่เป็นที่นิยม เลยต้องเลิกไป) แล้วหันไปสนับสนุน IFrame อย่างสุดแรงม้า (เว่อร์จริง ๆ)

ทีนี้มันก็จะเกิดเป็นประเด็นขึ้นมา เพราะ Facebook จำเป็นจะต้องรักพี่เสียดายน้อง เขาก็เลยยังคงต้องเก็บคู่มือในการใช้งาน API เก่า กับคู่มือในการใช้ API ใหม่เอาไว้ แถมดันเก็บรวม ๆ กันไว้อีกต่างหาก และที่สำคัญดันอธิบายแบบแยกส่วนด้วย (เออ เอากันเข้าไป)

และที่สำคัญ มีสิ่งหนึ่งที่นักพัฒนา Facebook Application เขารู้ แต่เขาไม่ค่อยเล่าให้ฟังกัน เนื่องจากมองว่ามันเป็นพื้นฐาน มันง่าย ใคร ๆ ก็น่าจะรู้ (ไม่จริงหรอก เรื่องเล็ก ๆ ง่าย ๆ นี่แหล่ะ มีคนไม่รู้เยอะ) นั่นก็คือ Facebook API มองได้เป็น 2 ส่วนใหญ่ ๆ คือ ส่วนของ ข้อตกลง Web Service และส่วนของ SDK!!!

ส่วนของข้อตกลง Web Service อ่ะนะ เป็นมาตรฐานวิธีในการเชื่อมโยงข้อมูลระหว่าง Facebook กับ Facebook Application ของเรา ซึ่งทาง Facebook ทำคู่มือออกมาให้เราอ่านกัน (แบบโคตรละเอียด แต่ กูงง กูงง กูงง) ไม่่ว่าจะเป็นคู่มือที่ชื่อ Apps on Facebook.com (อธิบายตั้งแต่การแสดงตน, ขอใช้สิทธิ์ และทำนู่นทำนี่) หรือ Grarph API (อธิบายว่าการแสดงตน, ขอใช้สิทธิ์ และทำนู่นทำนี่ ต้องส่ง Request แบบ Web Service ไปหา Facebook เป็นจำนวนกี่ท่อน และแต่ล่ะท่อนต้องยัดอะไรใส่เข้าไปบ้าง)

ส่วนของ SDK เป็นโค้ดของโปรแกรมแบบ Open Source ซึ่งพัฒนาขึ้นด้วยภาษาต่าง ๆ เช่น PHP หรือ Javascript เป็นต้น เพื่ออำนวยความสะดวกให้กับเรา ทำให้เราไม่จำเป็นต้องเขียนโค้ดเพื่อทำตามข้อตกลง Web Service ที่ Facebook กำหนดไว้ (มีชาวบ้านเขียนไว้ให้ ว่างั้น)

ถ้าถามว่า แบบนี้ เราก็ไม่จำเป็นต้องไปดาวน์โหลดโค้ด SDK มาก็ได้นี่หว่า เพราะถ้าเราแตกฉานในข้อตกลง Web Service ของ Facebook แล้ว เราก็สามารถจะเขียน SDK เองได้? ซึ่งผมก็คิดว่าอันนั้นก็จริงอ่ะนะ แต่จะลงมือทำไปทำติ่งอะไรล่ะ ในเมื่อเราเขียนเอง เขียนไปเขียนมา สุดท้ายมันก็ออกมาเหมือนกับ SDK ที่ำเขาทำให้อยู่ดี งั้นอย่าเสียเวลาเลยว่ะ ไปใช้ SDK ที่เขาทำก็สิ้นเรื่อง

โดย SDK ที่ว่าก็สามารถไปดาวน์โหลดได้ที่ GitHub เลือกโหลดเฉพาะ PHP-SDK (PHP Client Library) กับ Connect-JS (Javascript Client Library) นะ เพราะเป็นสิ่งที่โม้ ๆ อยู่ในหัวข้อนี้ (พอเข้าไปที่หน้าจอได้แล้ว อย่าลืมเหลือบไปดูที่เยื้อง ๆ มุมขวาของ Browser ด้วยล่ะ เพราะแถว ๆ นั้นมีปุ่ม “Download Source” ให้กด ก็กดตรงนั้นนั่นแหล่ะ จะได้ดาวน์โหลดมาทั้งยวงเลย!!!)

ต้องทำความเข้าใจก่อนว่า SDK ก็คือโค้ดที่มาเขียนเพื่อครอบข้อตกลงฯ ดังนั้น มันก็อาจจะเป็นชุดของ Function หรือเป็นชุดของ Class ก็ได้ โดยในที่นี้โค้ดของ PHP Client Library อ่ะเป็น Class ในขณะที่ Javascript Client Library อ่ะเป็น Function

ทีนี้ขึ้นชื่อว่าเป็น Class หรือ Function มันก็ต้องมีคู่มือประกอบใช่แมะ ว่ามันมีพารามิเตอร์อะไรบ้าง, มี Properties อะไรบ้าง หรือมี Method อะไรให้เรียกใช้ได้บ้าง?

ข่าวดีคือ Facebook ทำคู่มือ Javascript Client Library เอาไว้ให้เราอ่านเพื่อทำความเข้าใจนะ แต่ข่าวร้ายคือ Facebook ไม่ได้ทำคู่มือ PHP Client Library เอาไว้ให้อ่ะ มันยังไม่มี ต้องเข้าไปดูในโค้ดของ SDK เอาเอง!!!

มันก็เลยทำให้เราเกิดภาระเล็ก ๆ ขึ้นมา เพราะกลายเป็นว่า นอกจากเราจะต้องเรียนรู้ API ในส่วนของข้อตกลง Web Service แล้ว เรายังต้องมาเรียนรู้เพิ่มเติม (อีกเล็กน้อย) ในการใช้งาน PHP Client Library อีกหรือนี่???

ข้อสรุปอีกอย่างหนึ่งที่เกี่ยวกับ Facebook Application ก็คือ เราสามารถจะเขียน Facebook Application ด้วย PHP Client Library ล้วน ๆ ก็ได้ หรือจะเขียนผสม ๆ กันกับ Javascript Client Library ก็ได้ (อันนี้แล้้วแต่ความจำเป็น) นอกจากนี้ ถ้าเราเขียนมันจนชำนาญแล้ว เราก็ไม่จำเป็นต้องเขียนแบบ Pure PHP อีกต่อไป เพราะเราสามารถใช้ Web Application Framework (ไม่ว่าจะเป็น CakePHP หรือ CodeIgniter) เพื่ออำนวยความสะดวกให้เราเขียน Web Application ได้ง่ายและเร็วอีกด้วย