Web開發的窘境：碼還是不碼？
當為現有的應用程序開發前端時，經常出現的第一個問題是“我們應如何編譯它？”選擇自定義代碼來解決最終產品問題可以給你很大的靈活性，但最終會需要大量金錢和時間用于開發和持續支持。在某些情況下，試著盡可能去抽象開發過程，減少代碼編寫量更有意義。
本文中，我們將展示一些基于現有數據構建應用程序的方式方法，并說明為什么你會從中選擇一種。我們還將談及相關的前端代碼，尤其像 AngularJS 一樣有效地使用管理驅動方法的情況。
小處著手
對于 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 支持的任何數據庫吧。
</div>