英文原文：To Code or Not to Code
当为现有的应用程序开发前端时，经常出现的第一个问题是“我们应如何编译它？”选择自定义代码来解决最终产品问题可以给你很大的灵活性，但最终会需要大量金钱和时间用于开发和持续支持。在某些情况下，试着尽可能去抽象开发过程，减少代码编写量更有意义。
本文中，我们将展示一些基于现有数据构建应用程序的方式方法，并说明为什么你会从中选择一种。我们还将谈及相关的前端代码，尤其像 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 支持的任何数据库吧。
相关文章
