เรียนรู้วิธีใช้ Phoenix Framework เพื่อ ความสนุกสนาน ในการสร้างเว็บ/แอพมือถือ แบบเรียลไทม์
ที่ รวดเร็ว สำหรับ " ผู้ใช้ปลายทาง " เชื่อถือได้ ปรับขนาดได้ บำรุงรักษาได้ และ ขยาย ได้ ( อย่างง่ายดาย ) !
ในฐานะนักพัฒนาเว็บ/แอปมือถือ เรา จำเป็น ต้อง ใช้ประโยชน์จาก งานที่คนอื่นๆ ( ฉลาดจริงๆ ) ทำกัน
แทนที่จะสร้างสิ่งต่าง ๆ " ตั้งแต่เริ่มต้น " ตลอดเวลา; นั่นคือ เหตุผลที่ เราใช้ เฟรมเวิร์ก เพื่อสร้างแอปของเรา!
ดู: " เหตุผลยอดนิยม 10 ประการว่าทำไม Phoenix " ( ต่อไปในหน้านี้! )
มีกรอบการทำงาน มากมาย ให้เลือก ( บางกรอบ "ยอดนิยม" บางส่วน ระบุไว้ ด้านล่าง ในส่วน " คำถาม " )
แต่ถ้าเราไปตามสิ่งที่ " นิยม " เราก็จะยังขี่ม้า ( และเกวียน ) ไปทุกที่และไม่ คืบหน้า
หมายเหตุ : เหตุผล ทั้งหมด " ทำไม " สำหรับ Elixir ก็มีผลกับ Phoenix ด้วย !
ลองเข้าไปดู: https://github.com/dwyl/learn-elixir#why
กรอบงานเว็บแอปพลิเคชัน ที่ไม่มีการประนีประนอม !
" ข้อจำกัด " ที่ใหญ่ที่สุดในโครงการเทคโนโลยีใดๆ ก็คือ ผู้คน "ผู้ประกอบการ"/"ผู้ก่อตั้ง" หรือ "เจ้าของผลิตภัณฑ์" สามารถมี ความคิดดีๆ ในโลกได้ หากพวกเขา ไม่สามารถ เปลี่ยนความคิดให้กลายเป็น ความจริง ได้ ก็ ไร้ความหมาย
แน่นอน ว่า คุณควรรันการวัดประสิทธิภาพของคุณ เอง บนฮาร์ดแวร์/คลาวด์ของคุณเอง และทำการตัดสินใจ อย่างมีข้อมูล ตาม ความต้องการ ของแอป/ผลิตภัณฑ์ของคุณ แต่ ... เมื่อเรา อ่าน สถิติเกี่ยวกับจำนวน ผู้ใช้พร้อมกัน ที่แอป Phoenix สามารถจัดการได้ ( พร้อมการถ่ายทอดสด การเชื่อมต่อ WebSocket ) เรา ทึ่ง มาก! หมายความว่าเราสามารถสร้างแอปแบบเรียลไทม์โดยใช้ทรัพยากรน้อยลง 90%
ทั้งหมดนี้หมายความว่าคุณใช้จ่ายเงินน้อยลง อย่างมาก ในโครงสร้างพื้นฐานฮาร์ดแวร์/คลาวด์ ดังนั้นแอป/บริษัทของคุณจะได้รับ ความได้เปรียบทางการแข่งขัน ด้าน ต้นทุน
หากคุณอยู่ในตำแหน่ง ที่โชคดี ที่จะ พิจารณา ใช้สิ่ง ที่ดีกว่า สำหรับโปรเจ็กต์ ต่อไป ของคุณ ไม่ต้องมองหาที่ไหนไกลนอกจาก Phoenix!
อ่านเพิ่มเติม: http://www.phoenixframework.org
ผู้คน/ทีม/บริษัท จำนวนมาก ใช้ Erlang/Elixir และ Phoenix อยู่แล้ว และเห็นผลลัพธ์ที่น่าอัศจรรย์!
รวมถึง: Adobe, BBC, Spotify, Pinterest, Discord (แอปแชทเกมเมอร์), Groupon (Fave), Lonely Planet, Brightcove, Slack ...
ดู: https://github.com/doomspork/elixir-companies
คุณ ไม่สามารถ สร้าง Phoenix App โดยไม่รู้จัก Elixir
หากคุณยังใหม่กับ Elixir ให้ "ติดดาว" ( บุ๊กมาร์ก ) repo this ( เพื่อให้คุณสามารถกลับมาใช้งานได้ในวันพรุ่งนี้ )
จากนั้นไปที่: github.com/dwyl/ learn-elixir เรียนรู้ elixir จนกว่าคุณจะรู้สึกว่าคุณเข้าใจไวยากรณ์ จากนั้นกลับมาเรียน Phoenix!
โดยเฉพาะ คุณควรมุ่งเน้นไปที่การเรียนรู้ "พื้นฐาน" ของ Elixir:
Phoenix ใช้ Node.js เพื่อรวบรวมเนื้อหาเช่นไฟล์ JavaScript และ CSS ( โดยใช้ Webpack)
เพียงให้แน่ใจว่าคุณได้ ติดตั้ง Node.js แล้ว https://nodejs.org
คุณไม่จำเป็นต้องรู้จัก Node เพื่อใช้ Phoenix
หากคุณได้เรียนรู้ Elixir และติดตั้ง Node.js แล้ว ขั้นตอนแรกในการเริ่มต้นใช้งาน Phoenix ก็คือการติดตั้ง!
เอกสารของ Phoenix นั้นยอดเยี่ยมมาก ดังนั้นเราขอแนะนำให้ปฏิบัติตามคำแนะนำในการติดตั้งอย่างเป็นทางการของ Phoenix!
คุณจะต้องติดตั้ง PostgreSQL ด้วย โดยมีบทช่วยสอนเกี่ยวกับวิธีการติดตั้งตามลิงก์ในคู่มือการติดตั้ง Phoenix ที่ลิงก์ด้านบน แต่คุณยังสามารถตรวจสอบ repo learn-postgresql ของเราเพื่อดูคำแนะนำ และแจ้งปัญหาหากคุณมีปัญหาใดๆ !
แม้ว่าความเข้าใจ พื้นฐาน เกี่ยวกับ JavaScript อาจ มีประโยชน์ในบางครั้ง แต่คุณไม่ จำเป็น ต้อง รู้ วิธีใช้ Node เพื่อใช้ Phoenix
หากคุณสงสัย ว่าเหตุใด พวกเขาจึงเลือก Brunch.io มากกว่า " ทางเลือก "
คำตอบสั้นๆ คือ: ความเรียบง่ายและความเร็ว! ดู: http://brunch.io/docs/why-brunch
หมายเหตุ : Phoenix v1.4 ( ยังไม่เผยแพร่ในขณะที่เขียน ) ใช้ WebPack สำหรับการรวบรวมเนื้อหา ดู: CHANGELOG.md
ทำความคุ้นเคย กับคู่มือ "Up and Running" ( อย่างเป็นทางการ ): https://hexdocs.pm/phoenix/up_and_running.html#content 
เมื่อคุณติดตั้ง phoenix และปฏิบัติตามคำแนะนำ "และใช้งาน" อย่างเป็นทางการแล้ว
กลับมาลอง ตัวอย่าง ที่เหมาะสำหรับผู้เริ่มต้น เหล่านี้:
เรา แนะนำ ให้ผู้คน ซื้อ ( หรือยืม ) หนังสือของ @chrismccord: "Programming Phoenix"
ดู: https://pragprog.com/book/phoenix14/programming-phoenix-1-4 
ผู้เขียนมี ผลงานที่น่าประทับใจ เป็นรายบุคคล และ โดยรวมแล้ว พวกเขาครอบคลุม Phoenix อย่างครอบคลุม อย่างที่ไม่มีใคร สามารถทำได้ ! Chris สร้าง Phoenix, José สร้าง Elixir และ Bruce เป็นนักเขียนด้านเทคนิคมากประสบการณ์และมีหนังสือที่ประสบความสำเร็จ มากมาย ในชื่อของเขา!
( เช่น หนังสือเล่มนี้เป็นตัวเลือกที่ชัดเจนในการเรียนรู้ฟีนิกซ์! )
https://youtu.be/MD3P7Qan3pw
https://youtu.be/srtMWzyqdp8
" Phoenix มอบ ประสิทธิภาพ ของ Ruby-on-Rails
ด้วย ความสอดคล้อง และ การยอมรับข้อผิดพลาด ของ Erlang ”
Phoenix ใช้ภาษาการเขียนโปรแกรม Elixir ซึ่งหมายความว่าแอปของคุณได้รับการคอมไพล์และรันบน Erlang Virtual Machine "BEAM"
Erlang เป็น VM ที่ทนทานต่อข้อผิดพลาดสูงที่ผ่านการทดสอบการต่อสู้ซึ่งใช้งานโดยบริษัทโทรคมนาคม หลายแห่ง
WebSockets (" ช่อง ") สร้างขึ้น ในเฟรมเวิร์ก ซึ่งหมายความว่าการสร้างแอปด้วยการสื่อสารและการโต้ตอบ "เรียลไทม์" นั้นง่ายกว่าเฟรมเวิร์ก/แพลตฟอร์ม อื่น ๆ มาก ! ( ไม่จำเป็นต้องใช้โมดูล magic ของบุคคลที่สาม! ทุกสิ่งที่คุณต้องการ พร้อมให้คุณรับใช้ผู้คน นับล้าน แล้ว!! )
ดู: http://www.phoenixframework.org/docs/channels
ความไม่ซิงโครไนซ์ ง่าย เพราะการเขียนโปรแกรมทั้งหมดใน Phoenix ( Elixir ) นั้น ใช้งานได้ ! ซึ่งหมายความว่าฟังก์ชันที่มีประโยชน์แบบนามธรรมนั้นง่าย มาก เช่น ขอการรับรองความถูกต้อง การบันทึก และการประมวลผลเป็น " piplines " ที่ มนุษย์สามารถอ่านได้ ง่าย! ( ไม่จำเป็นต้องมีโมดูล async ของบุคคลที่สาม! ไม่มี "สัญญา", "เครื่องกำเนิดไฟฟ้า" หรือ "สิ่งที่สังเกตได้" ในการจัดการ!! )
Security & Resilience Mindset เป็น default การเข้ารหัส (SSL) นั้น ง่ายดาย ใน Phoenix/Elixir และ การลด การฉีด SQL , Cross-site Scripting ( XSS ) และ การป้องกัน CSRF นั้น มีอยู่ในตัว ( เปิดใช้งานโดย default ) ดังนั้นจึงแทบจะเป็นไปไม่ได้เลยที่โปรแกรมเมอร์ " มือใหม่ " จะแนะนำประเภทนี้ ของข้อผิดพลาดด้านความปลอดภัย
รหัสที่กระชับ ไม่สามารถ พูดได้ ! เราสามารถเขียนบรรทัด ได้น้อยกว่า ในแอป Node.js/Java/Rails/Go ที่เทียบเท่ากัน ซึ่งหมายความว่านักพัฒนาจะ มีประสิทธิภาพ มากกว่าและมี โค้ดที่ต้องดูแลรักษาน้อยกว่า !
ทดสอบได้ เนื่องจากการตั้งโปรแกรมการทำงานของคอนโทรลเลอร์ทั้งหมด!
ปรับใช้ง่าย : https://hexdocs.pm/phoenix/heroku.html
การปรับใช้ Zero-downtime ฟรี ! ( อีกครั้งเพราะ Erlang ) Erlang จัดการการเปลี่ยนผู้ใช้ " สด/ใช้งานอยู่ " จากแอปเวอร์ชันเก่าไปเป็นเวอร์ชันใหม่ โดยที่พวกเขา ไม่รู้ ด้วยซ้ำว่าได้รับการอัปเกรด/อัปเดตแล้ว!!
การตรวจสอบ/การจัดการแอปของคุณในตัว ผ่านหัวหน้างาน Erlang หมายความว่าคุณทราบ แน่ชัด ว่าแอปของคุณทำงานอย่างไร มีชิ้นส่วนใดบ้างที่ขัดข้อง/รีสตาร์ท และเพราะเหตุใด นี่คือคุณสมบัติที่เรา จ่าย ( มาก ) สำหรับในเฟรมเวิร์กอื่น และที่นี่ ฟรี !!
คุณ นึกถึงเหตุผล อื่นบ้าง ไหม ว่าทำไม การใช้ Phoenix ถึง ยอดเยี่ยม !
กรุณาแบ่งปันความคิดของคุณ ในกระทู้นี้: #13
before จะลองใช้/ใช้ Phoenix หรือไม่?ใช่ . ดู: https://github.com/dwyl/learn-elixir
เลขที่ . คุณสามารถเริ่มเรียนรู้/ใช้งาน Elixir ได้ ตั้งแต่วันนี้ และเรียกใช้ฟังก์ชัน Erlang เมื่อจำเป็น
แต่คุณ ไม่จำเป็น ต้องรู้ Erlang before จึงจะสามารถใช้ Phoenix ได้!
มีเฟรมเวิร์กแอปพลิเคชันเว็บ มากมาย ที่คุณ/เราสามารถเลือกได้: https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
แล้ว ทำไม ใครๆ ก็เลือก Framework ที่เขียนด้วยภาษาโปรแกรมที่ไม่ใช่ " กระแสหลัก "...?
นี่เป็น ข้อมูลที่ผิด เรายัง คง ใช้ Hapi.js ในโครงการ จำนวน หนึ่งตาม ความเหมาะสม
ซึ่งรวมถึงโปรเจ็กต์ไคลเอนต์ หลายรายการ และแอป/เครื่องมือ dwyl ภายใน
เรา ตัดสินใจ ใช้ Phoenix สำหรับโปรเจ็กต์ ใหม่ ของเราด้วยเหตุผลง่ายๆ เหล่านี้:
#LessIsMore #LessButBetter #SmallIsBeautiful #SyntaxMattersสำหรับโปรเจ็กต์ใหม่ของเรา เรา ต้องการความทนทานต่อข้อผิดพลาดของศูนย์ข้อมูลหลายศูนย์ !
เราได้รับ " ฟรี " โดยใช้ Erlang -> Elixir -> Phoenix !!
ใน ความเห็น ของเรา Hapi.js ยังคงเป็น Node.js framework ที่ " ดีที่สุด " และเราจะใช้และ แนะนำ continue
สำหรับผู้ที่ต้องการแอปเรียบ ง่าย ที่ปรับขนาดได้และดูแลรักษาง่าย
ดู: https://github.com/dwyl/learn-hapi
นอกจากนี้ เรายังคงใช้ JavaScript สำหรับ AWS Lambda Micro-Services ทั้งหมดของเรา ซึ่งจะไม่เปลี่ยนแปลง
เรียบง่าย มีประสิทธิภาพ และปรับขนาดได้ดีมาก!
ดู: https://github.com/dwyl/learn-aws-lambda
เว็บเฟรมเวิร์กที่ " มีประสิทธิผล " ดั้งเดิม คือ "Ruby-on-Rails" และ "Django" ( python ) ย้อนกลับไปในปี 2548!
(เรา ใช้ ทั้งสองอย่างนี้เป็นระยะเวลาหนึ่งใน " การเดินทาง " ของเรา และสามารถพูดถึง ข้อดี ของทั้งสองอย่างได้!)
การใช้ Rails หรือ Django ไม่มีอะไร "ผิด "
เราคิดว่ายังมีกรณีการใช้งานอีกมากสำหรับทั้งสองเฟรมเวิร์ก
เราเพิ่ง รู้ ว่าการสร้าง "เรียลไทม์" ง่ายกว่า ( มาก )
กับ Phoenix เพราะ "Channels" ( WebSockets ) ถูกอบเข้า
และการทำงานพร้อมกันของ Elixir/Erlang นั้นเป็นเกมบอลที่แตกต่างไปจากเดิมอย่างสิ้นเชิง!
Erlang (และ Phoenix) สามารถรองรับ ผู้ใช้ หลายล้านคน พร้อมกันบนเซิร์ฟเวอร์เดียว
ในขณะที่เซิร์ฟเวอร์ Rails/Django สามารถรองรับได้เพียงไม่กี่พัน ( อย่างดีที่สุด !)
หากแอปของคุณให้บริการผู้คนได้เพียงไม่กี่พันคนในคราวเดียว คุณก็ไม่เป็นไร!!
เรา ชอบ ความจริงที่ว่า Erlang ใช้กระบวนการ " lighweight long-lived "
ซึ่งหมายความว่าเราสามารถเชื่อมต่ออุปกรณ์ ( IoT ) นับ ล้านได้ ... สำหรับ IoT Erlang คือคำตอบ ( อย่างไม่ต้องสงสัย )!
สำหรับเว็บแอปที่เรียบง่ายกว่าที่คุณคาดหวังให้มีผู้ใช้เพียงไม่กี่คนต่อวัน Rails/Django ยังคงใช้งานได้
แต่ ทำไม ต้องประนีประนอม ถ้าคุณ ไม่ จำเป็นต้อง ทำ ?
หากคุณสามารถมี Tesla ในราคา "ราคา" ของ Ford Focus ได้ ทำไมคุณ จะทำไม่ได้ ?!?
ทำไม ต้องเลือก สิ่งที่ดี ในเมื่อคุณสามารถมี/ใช้ สิ่งที่ดีที่สุด ได้อย่างง่ายดาย ?
ใช่ GitHub ยังคงใช้ Rails สำหรับ Web App/Site ของตน
แต่ลองถามทีม หลัก ที่ GitHub ว่า ( ได้รับโอกาสในการเริ่มต้นใหม่ ) พวกเขาจะ เลือก Rails หรือ ไม่
เพื่อสร้าง GitHub ในปี 2560 และดูว่าจะมีกี่คนที่พูดว่า " ใช่ แน่นอน " ( ด้วยสีหน้าตรงไปตรงมา... )!
นอกจากนี้ GitHub ยังทำสิ่งต่างๆ มากมาย กับ Scale Rails ในเบื้องหลัง
และฟีเจอร์ ใหม่ ( ฝั่งไคลเอ็นต์ ) จำนวนมาก เขียนด้วย JavaScript! ดู: https://github.com/github
สิ่งที่สำคัญที่สุดคือ: ทุกสิ่ง สามารถ ปรับ ขนาดได้โดยใช้ "DevOps"
แต่ ฟีนิกซ์ ถูก สร้างขึ้นมา เพื่อ ปรับขนาด ตามdefaultเพราะ Erlang (ถูก) คิดค้น (เป็น) ขนาด!
" ภาษาโปรแกรมมีสองประเภท - ภาษาที่ไม่มีใครใช้ และภาษาที่ใครๆ ก็พูดถึง " ~ Bjarne Stroustrup ( ผู้สร้าง
C++)
โกเป็นที่นิยม มาก ส่วนใหญ่เกิดจากการที่ Google " สนับสนุน " มัน
มีจุดมุ่งหมายเพื่อลดความซับซ้อน ( แทนที่ ) C++ และ Java ภายใน Google ...
และส่วนใหญ่ก็ทำสำเร็จ!
เราชอบโก มาก มันเป็นตัวเลือก "หมายเลขสอง" ของเราในการตัดสินใจเลือกภาษาการเขียนโปรแกรม
( หลังจาก Elixir ) ใน "post JS stack" ของเรา... การตัดสินใจ ใช้ elixir แทน สิ่ง else เป็น เรื่องง่าย :
อ่านเพิ่มเติม:
Play Framework แทน ... หากคุณคุ้นเคยกับการเขียน Java หรือปรับใช้กับ JVM อยู่แล้ว Play Framework เป็นตัวเลือก ที่ยอดเยี่ยม : https://www.playframework.com
Scala เป็นภาษาโปรแกรม ที่ดี และทุกคนควรเรียนรู้มัน! https://www.scala-lang.org/what-is-scala.html
เราใช้ Play สองสามครั้ง ( ก่อนที่เราจะใช้ Node.js ) และชอบมัน มาก !
แต่ Scala เป็นภาษาโปรแกรม "kitchen sink" ( หลายกระบวนทัศน์ ) ที่ให้ผู้คนใช้ " Java ทั้งหมด " ...
เราคิดว่า "Java Interoperability" ของ Scala หมายความว่า "ง่ายเกินไป" ที่จะยอมให้โค้ดเบสของคุณ มีความซับซ้อน โดยเฉพาะ "OOP Mutation" ...
เหตุใดเรา (DWYL) จึง ไม่ ใช้ "Play" สำหรับโปรเจ็กต์ ใหม่ อีกต่อไป ประการแรก เราเปลี่ยนไปใช้ Hapi.js ( Node.js ) เมื่อ ไม่กี่ ปีก่อนเพราะมัน " เบา " มากกว่า และช่วยให้เราเขียนโปรแกรม เล็กๆ ที่ใช้ RAM เพียงไม่กี่เมกะไบต์ได้ ( ซึ่งแอป Play ของเรากินทรัพยากรมาก .! คุณเคยลองใช้แอป Scala บนแล็ปท็อป "พื้นฐาน" เช่น Chromebook หรือไม่... )
สรุป "เหตุผล" สำหรับ Phoenix แทน Play:
เราแค่คิดว่าสำหรับโครงการ ของเรา โมเดลการทำงานพร้อมกันของ Erlang ทำงานได้ดีขึ้น และ โค้ดฟังก์ชัน ที่แปลง ข้อมูลที่ไม่เปลี่ยนรูป นั้น ง่ายต่อ การทดสอบและบำรุงรักษา
หากคุณมี หลักฐาน ว่า " สกาล่าง่ายกว่า " เรา ยินดี รับฟังจากคุณ!
บอกเรา: https://github.com/dwyl/learn-phoenix-web-development/issues
ถ้าคุณชอบ Functional Programming ( FP ) มาก ทำไมไม่ใช้ Haskell ล่ะ?
