ทำไมเว็บไซต์ขนาดใหญ่จึงใช้ภาษาต่าง ๆ สำหรับส่วนหลังและส่วนหน้า

ความเข้าใจของฉันจากแอปพลิเคชัน MVC ขนาดเล็กคือคุณมีส่วนหน้าซึ่งเกี่ยวข้องกับ HTML, JS, jQuery และอื่น ๆ และคุณมีจุดสิ้นสุดด้านหลังซึ่งประกอบด้วยตัวควบคุมและรุ่นของคุณ

อย่างไรก็ตามเมื่อฉันพูดคุยกับนักพัฒนาจาก บริษัท ขนาดใหญ่พวกเขามักจะพูดถึงว่ามีส่วนหน้าและส่วนหลัง ดังนั้นบางครั้งฉันอาจได้ยินว่าพวกเขามีส่วนหน้ากับ C # และส่วนหลังกับ Java ทำไม บริษัท ใดต้องการแบ็กเอนด์และส่วนหน้าในภาษาอื่น สิ่งนี้ช่วยให้เว็บไซต์ขนาดใหญ่ดีขึ้นหรือไม่

เมื่อมีคนบอกว่าส่วนหน้าของพวกเขาถูกสร้างขึ้นใน C # นี่หมายความว่าพวกเขากำลังใช้เฟรมเวิร์กสำหรับส่วนหน้า (เช่น. NET) และกรอบงานเพิ่มเติมของแบ็กเอนด์ (เช่นสปริง) หรือมันหมายถึงบางสิ่งที่แตกต่างอย่างสิ้นเชิง?

"Front-end" และ "Back-end" อาจเป็นคำที่คลุมเครือโดยเฉพาะในแอปพลิเคชันระดับองค์กร "Front-end" อาจหมายถึง UI หรืออาจเป็นแอปพลิเคชันทั้งหมด "Back-end" สามารถใช้เพื่อหมายถึง internals หรืออาจเป็นฐานข้อมูลหรือบริการภายนอกที่มีการใช้งาน ความหมายของคำศัพท์มักขึ้นอยู่กับว่าคุณกำลังพูดคุยกับใคร คุณอาจถามว่า "เฮ้คุณหมายถึงอะไร"

เมื่อคุณเข้าสู่การพัฒนาองค์กรขนาดใหญ่คุณจะมีทีมจำนวนมากที่เขียนโค้ดจำนวนมาก ทีมเหล่านี้จะพัฒนาในภาษาต่าง ๆ โดยใช้กระบวนทัศน์ที่แตกต่างจากสถานที่ต่างกัน บางส่วนของรหัสนี้จะต้องทำงานร่วมกันและส่วนใหญ่จะไม่

ฉันทำงานให้กับธนาคารขนาดใหญ่ ทีมของฉันพัฒนาแอปพลิเคชันของเราใน C # ทั้งหมดของมัน. แต่เราใช้บริการเว็บที่เขียนด้วยภาษาจาวาเป็นส่วนใหญ่และบริการเหล่านั้นจะพูดคุยกับบริการอื่น ๆ ที่พูดคุยกับบริการอื่น ๆ ที่ได้รับข้อมูลบัญชีจากร้านค้าข้อมูลที่เหมาะสมและผู้ที่รู้ว่าใช้ภาษาใด

ฉบับย่อ: ผู้คนใช้เครื่องมือที่ทำให้งานเสร็จ

ฉันคิดว่าคุณต้องขยายคำถามให้กว้างขึ้น: ทำไมโครงการซอฟต์แวร์ขนาดใหญ่ถึงใช้ภาษาการเขียนโปรแกรมมากกว่าหนึ่งภาษา

มีหลายคำตอบที่เป็นไปได้

• การใช้งานขนาดใหญ่ประกอบด้วยชิ้นส่วนที่ค่อนข้างอิสระ บ่อยครั้งแต่ละส่วนถูกสร้างโดยทีมอื่นหรือแม้แต่ผู้รับเหมาภายนอกที่แตกต่างกัน ประโยชน์ของการไปกับการเสนอราคาที่ดีที่สุดมักจะใหญ่กว่าประโยชน์ของการมีทุกสิ่งในภาษาเดียวกัน
• ภาษามาและไปและบางครั้งองค์ประกอบของระบบขนาดใหญ่จะมีผลต่อระบบนิเวศ ตัวอย่างจากโลกของ Microsoft คือตอนนี้มีกี่ บริษัท ที่ใช้ C # สำหรับโครงการใหม่ทั้งหมด แต่พวกเขายังมี codebase VB จำนวนมาก ค่าใช้จ่ายในการเขียนโครงการใหม่เพียงเพื่อประโยชน์ในการเขียนโปรแกรมภาษาล่าสุดนั้นแทบไม่เป็นธรรมเลย
• การเชื่อมต่อกับส่วนประกอบของบุคคลที่สาม หากระบบปฏิบัติการ C # ของคุณต้องการทำงานเฉพาะที่มีเพียงโซลูชัน Java เท่านั้นคุณมีสองทางเลือก: ใช้โซลูชันด้วยตนเองหรือใช้โซลูชัน Java และพัฒนากาวเล็กน้อยเพื่อรวมเข้ากับระบบของคุณ ส่วนหลังนั้นมีราคาถูกกว่าสำหรับงานที่ไม่สำคัญ

การพิจารณาถึงประสิทธิภาพนั้นไม่เคยมีเหตุผลยกเว้นในแอพพลิเคชั่นที่มีความสำคัญอย่างยิ่งเช่นการซื้อขายที่มีความถี่สูง - ในพื้นที่เหล่านั้นจะเป็นประโยชน์ในการเขียนเอนจินคอร์ที่สำคัญในภาษาที่มีประสิทธิภาพดีขึ้น แต่ระบบที่รองรับ (UI, การรายงาน, ฯลฯ ) ในระดับที่สูงกว่าเช่น Java หรือ C #

เป็นญาติในองค์กรขนาดใหญ่
ใน บริษัท ของฉันสแต็คนั้นคร่าวๆ

(html/javascript)--> (JSP on Tomcat and Java based WebCMS) -> (.Net SOA)  

ดังนั้นสำหรับทีมพัฒนาเว็บไซต์ส่วนหน้าคือ HTML / JS และส่วนหลังคือ Java สำหรับองค์กรส่วนหน้าคือ Java และส่วนหลังคือ. Net

ในความเป็นจริงเลเยอร์. Net ต้องทำงานกับแอปพลิเคชัน COBOL / UNIX สำหรับการเรียกเก็บเงินและการอ้างสิทธิ์และอื่น ๆ ในมุมมองนี้. Net คือส่วนหน้าและ COBOL เป็นแบ็กเอนด์

และใช่อย่างที่คนอื่นพูดถึงเรามีทีมนักออกแบบ UX, HTML / JS devs, Java devs, Web Middleware, .Net devs, SQL devs, COBOL devs ที่ทำงานในแต่ละส่วนของสแต็ก

ในความเป็นจริงในองค์กรขนาดใหญ่ใด ๆ ที่เพียงพอมันเต่าตลอดทางลง

ความหมายที่สับสน

มันเป็นปัญหาความหมาย เมื่อมีคนพูดว่า. Front front. หรือ Java front end developer พวกเขามักจะพูดถึงคนที่รู้ภาษาเทมเพลตจำนวนมากและอาจเป็นเฟรมเวิร์กที่ไม่ควรใช้อีกเช่นเว็บฟอร์มที่เคยลองซ่อน การเชยสิ่งต่าง ๆ บนกำแพง http (เช่น "การพัฒนาเว็บ") จากนักพัฒนาแอปที่ไม่ต้องการหรืออย่างน้อยก็สันนิษฐานว่าไม่ต้องการเรียนรู้เกี่ยวกับอึทั้งหมด ในกรณีของ. NET และ Java ผสมกันฉันไม่แน่ใจ แต่ฉันเดาได้เฉพาะในแง่ของ MVC ที่พวกเขาได้รับ Java ทำหน้าที่แทนโมเดลธุรกิจทั้งหมดและ. NET จัดการทุกอย่างซึ่งจะอธิบายได้ดีกว่า เป็น "ระดับกลาง" แต่ก็ยังคงฝั่งเซิร์ฟเวอร์ทั้งหมด

การแยกที่แท้จริงคือสิ่งที่เกิดขึ้นบนเซิร์ฟเวอร์และสิ่งที่เกิดขึ้นกับลูกค้าหรือเบราว์เซอร์ คุณสามารถสร้างการ HTML ที่จะส่งไปยังหรือเป็นตัวแทนของ front end ด้วย "front end development" ดังนั้นฉันจึงชอบหลีกเลี่ยงความสับสนโดยใช้เงื่อนไขของไคลเอนต์และฝั่งเซิร์ฟเวอร์แทน front-end และ back-end เมื่อพูดถึงสิ่งที่ฉันทำ (โดยปกติแล้วจะทำงานที่ฝั่งไคลเอ็นต์)

ภาษาฝั่งไคลเอ็นต์

เหตุผลที่เราใช้ชุดภาษาเดียวกันบนเบราว์เซอร์นั้นเป็นเพราะเบราว์เซอร์อยู่ในช่วงท้ายการรับและส่วนใหญ่ (มีการต่อต้านจาก Microsoft และ Adobe ในตอนนี้ส่วนใหญ่ตายแล้ว) ไม่มีใครต้องการที่จะส่งสาม ฝั่งไคลเอ็นต์เวอร์ชันเดียวกันต่างกันเพื่อตอบสนองลูกค้าที่มีศักยภาพทุกคนหรือต้องติดตั้งปลั๊กอินที่เป็นกรรมสิทธิ์เพื่อให้เว็บทำงานได้ นอกจากนี้ทั้งสามภาษานั้นสรุปความกังวลด้านไคลเอนต์ได้เป็นอย่างดีทำให้เราสามารถสร้างและปรับเปลี่ยนส่วนหน้าของเว็บแอปได้อย่างรวดเร็วโดยการรักษาข้อต่อหลวมระหว่างโครงสร้างเอกสารลักษณะทุกอย่างและลักษณะการทำงานทั้งหมดอย่างไร คุณสามารถเปลี่ยนได้โดยไม่ต้องเปลี่ยนอีกสองตัวได้อย่างง่ายดาย

ภาษาฝั่งเซิร์ฟเวอร์

เหตุผลที่คุณมีตัวเลือก bazillions บนเว็บไซด์ของเซิร์ฟเวอร์นั้นเป็นเพราะคุณทำได้ มันเป็นเซิร์ฟเวอร์ของคุณ สิ่งที่ต้องทำคือสื่อสารผ่าน http / ssl และส่วนที่เหลือขึ้นอยู่กับคุณ JavaScript เป็นตัวเลือกอยู่แล้ว แต่นั่นก็เป็นคำถามที่น่าสนใจ หากคุณยังถือว่าแอปพลิเคชันบนเว็บเป็นสองแอพที่ด้านใดด้านหนึ่งของวอลล์ HTTP นั้น ฉันเห็นด้วยกับความเห็นที่เจ็บปวดว่าใช่คุณควรและฉันรัก Node.js

กล่าวโดยย่อว่าคุณมีโครงการขนาดใหญ่คุณยังมีทีมนักพัฒนาหลายคนที่ทำงานในโครงการและทีมเหล่านั้นมีแนวโน้มที่จะเชี่ยวชาญในชั้นต่าง ๆ ของแอปพลิเคชัน

หากคุณมุ่งเน้นไปที่ UI บนเว็บและคุณมีความยืดหยุ่นในการเลือกใช้งานคุณมีแนวโน้มที่จะใช้ภาษาที่กำหนดเป้าหมายบนเว็บเช่น JScript หรือ Flex มากกว่า C #

ในทำนองเดียวกันถ้าคุณอยู่ที่ส่วนท้ายของแหล่งข้อมูลการทำธุรกรรมของแอปพลิเคชันการจัดการกับการกระทำหลายอย่างพร้อมกันในเวลาเดียวกันภาษาพิเศษเช่น erlang มักจะถูกนำมาใช้ (หรือผลิตภัณฑ์ของบุคคลที่สามที่ใช้งานในบางส่วนของภาษาเหล่านี้)

เหตุผลคือความสมดุลทางธุรกิจ

สมมติว่าคุณเป็นนายจ้างรายใหญ่ในเมืองเดียว คุณต้องจ้างนักพัฒนาจำนวนมากเพื่อสร้างบริการที่แตกต่างกันมากมาย สมมติว่าการประเมินเบื้องต้นของคุณคือ Lanuage A เหมาะสมกับความสนใจของคุณที่สุดและคุณต้องการเริ่มต้นด้วย

หากคุณยอมรับเทคโนโลยีเดียวคุณอาจแหวกว่ายไปในพรสวรรค์ คุณแน่ใจหรือไม่ว่าต้องการจ้าง Langauge ที่มีคุณภาพผู้ชายที่มีดาวภาษา B อยู่ใกล้ ๆ เกิดอะไรขึ้นถ้าเฟรมเวิร์กของ Langauge A ในวันพรุ่งนี้ยึดได้รับการสนับสนุนจากผู้พัฒนาหลัก ถ้าวันพรุ่งนี้มีภาษา C ที่น่าทึ่งคุณควรเพิกเฉยเพราะคุณมุ่งมั่นที่จะเรียนภาษาเมื่อห้าปีก่อน?

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

... และนั่นคือสิ่งที่ บริษัท ทำ

การคิดถึงส่วนหน้าและส่วนหลังของคุณเป็นประโยชน์สำหรับแอปพลิเคชันที่แยกกันซึ่งทั้งคู่ใช้แหล่งข้อมูลเดียวกัน

แม้สำหรับไซต์ขนาดเล็กคุณสามารถนึกถึงส่วนหน้าว่าเป็นสิ่งที่ไคลเอนต์ติดต่อกับและส่วนหลังเป็นสิ่งที่คล้ายกับ CMS สิ่งเหล่านี้สามารถแยกเป็นแอปพลิเคชัน MVC ได้อย่างง่ายดาย ส่วนหน้ายังคงต้องการรุ่นและตัวควบคุมเพื่อให้ทำงานได้อย่างไรก็ตามตัวควบคุมคือจุดเริ่มต้นสำหรับผู้เยี่ยมชมไซต์ของคุณและโมเดลจะเป็นวิธีที่คุณได้รับข้อมูลจากฐานข้อมูลของคุณไปยังผู้ใช้

ฉันมักจะชอบใช้ Django / Python เป็น CMS ที่ส่วนท้ายและใช้ Rails, CodeIgniter หรือ Spring MVC ที่ส่วนหน้า บ่อยครั้งที่ไม่มีทางเลือก ไคลเอนต์มีไซต์ดั้งเดิมที่ตั้งค่าในบางภาษาในส่วนหน้าและพวกเขาเพียงต้องการโซลูชัน CMS ลูกค้าส่วนใหญ่ไม่ทราบด้วยซ้ำว่า CMS กำลังใช้ภาษาหรือกรอบงานอื่นหากไม่ได้รับการบอกกล่าว

มันเกี่ยวกับการค้นหาสิ่งที่ดีที่สุดสำหรับไซต์ที่คุณต้องการสร้าง ปลายด้านหน้าและด้านหลังจำเป็นต้องแชร์ฐานข้อมูลจริง ๆ เท่านั้นตราบใดที่ทั้งคู่สามารถทำงานกับมันได้อย่าลังเลที่จะเลือกตัวเลือกที่ดีที่สุดสำหรับงานในมือ

ตัวอย่างของภาษาส่วนหลังคือ PHP ซึ่งเป็นภาษาสคริปต์ เมื่อมีการร้องขอหน้า PHP เซิร์ฟเวอร์จะอ่านโค้ด PHP และแสดงผลมาร์กอัป ผลลัพธ์คือ HTML ที่ส่งถึงคุณ คุณผู้ดูเว็บเพจไม่เคยเห็นโค้ด PHP หนึ่งบรรทัด สมมติว่าผู้ดูแลเว็บเซิร์ฟเวอร์ทำงานได้อย่างถูกต้องเซิร์ฟเวอร์จะดำเนินการและไม่สามารถแสดงรหัส PHP จริงได้ มีการแยกวิเคราะห์เมื่อเพจถูกแสดงผลและผลลัพธ์ของการแปลโค้ดนั้นคือ HTML