Web開發的窘境:碼還是不碼?

edithfang發表於2014-12-25
當為現有的應用程式開發前端時,經常出現的第一個問題是“我們應如何編譯它?”選擇自定義程式碼來解決最終產品問題可以給你很大的靈活性,但最終會需要大量金錢和時間用於開發和持續支援。在某些情況下,試著儘可能去抽象開發過程,減少程式碼編寫量更有意義。



小處著手

對於 Web 開發,程式設計時有大量的選擇適合不同的舒適度。我們的首選是以微乎其微的程式設計需求開始。像是www.wix.com就允許零程式設計建站,當然得使用圖形編輯工具來設計和體驗了,資料就存在後臺。許多託管提供商提供各種不同程度複雜度的這類工具。

如果你的網站相對較小或你使用的資料並不複雜,這些解決方案算是很好的了,但最終這些網站都在執行復雜功能的時候遇到了問題。這些應用通常沒有基於資料庫設計,這意味著當你的應用的資料庫和他們介面時需要一些自定義程式碼的開發。此外,根據不同的服務,前端頁面的底層原始碼可能需要挑戰性的修改,以便實現像過渡到 Angular 一樣的挑戰性的東西。

釋放前端

降低一下等級,我們遇到掩蓋了 API 後面應用的後臺部分的服務。這些工具允許你完全集中在開發前臺,直接使用Angular顯示從你選擇的服務提供商RESTAPI獲得的資料。像 Parse、Bckand 和Firebase 等供應商就供這種構建一個現有的資料儲存並提供從任何位置訪問你的資料或應用程式的服務。

也許你想自己專門開發應用程式前端,並讓另一方完全處理你的應用程式後臺。不管怎樣,你也受到你選擇的提供商的侷限——取決於提供商怎樣構建他們的服務,可能像 REST API 一樣簡單地轉譯你資料庫,或者允許自定義元件開發。

然而,在大多數情況下,前端才是你唯一能完全自定義的。

提供完整的堆疊

想要實現真正的可定製通常是通過使用完整堆疊法。這需要開發一個使用物件關係對映器(ORM)工具的後臺,比如 Rails。這讓你更靈活地操縱底層資料,而且有許多框架提供工具來減輕前端顯示頁的開發,開發 REST API 就允許你使用 AngularJS 和 Bootstrap 之類的工具快速開發一致且時髦的顯示部分。

這種方法的缺點是雙重的。第一,不太明顯的是,你必須有一個開發團隊,可以根據現有資料的介面需求開發 REST API。這是一個過程,不用數月的話也得數週時間去完成,最後你也只完成了後臺開發。更明顯的缺點就是你需要覆蓋所有的基礎設施——託管、縮放、安全等等——整個內部空間。這會極大地增加實施成本,也引入了經常維護成本。

合併這些方法

還有一個選項存在,那就是使用工具,既能與現有資料整合——提供 REST API——又能允許真正可定製的同時縮減後臺開發。這個工具就是 Django ——它提供了基本的 ORM 功能,一個現成的資料管理介面,可選的使用內建的顯示功能或使用 REST 後臺驅動 Angular 前端。其缺點和完整堆疊方法一樣,但稍微有些緩解;你的團隊可能會節省開發時間,但所有的託管、安全和維護仍然必須在內部完成。

這種方法的另一個選擇是像 Backand 式的後臺即服務提供商。Backand 接管你的現有資料並在幾分鐘(完全不需要數週)生成一個管理前端和所有的外部管理的後臺元件——擴充套件資料庫、安全訪問和託管程式碼。Backand 也基於你的資料動態地給了你 ORM 和構建 REST API,為你的應用層析提供一個簡單的前端介面。這種方法生成的解決方案同時提供最低的成本和最佳的生產率。當你犧牲一些後臺的靈活性,還可以減輕用可用的工具來開發定製元件的需求。

結論

總而言之,平臺的選擇最終歸結為你認為應用程式多麼複雜。如果你願意犧牲幾乎所有的靈活性,你的專案也就不需要編寫任何程式碼,一個像 Wix 的工具可能值得考慮。然而,當尋找應用 Angular 的來顯示你的資料的方法時,你通常有很多選項。你的選擇將取決於開發組織中的歧視因素,如專家平臺、可用開發和基礎設施預算、現有功能、團隊認知和其他因素等等。當開發一個 Web 應用程式時,最終最好的方法是最適合你的組織需要的那個。

今天就建立你的 Angular 應用,並把它連線到 Backand 支援的任何資料庫吧。

(英文backend,譯者caster_cai)
評論(1)

相關文章