我正在使用postgre（AWS RDS）作为我的数据库，并使用节点（AWS EC2）作为服务器端。 我刚刚开始，所以我没有太多的背景。 我总是使用其他第三方软件，如Parse for DB，所以我有我的应用程序通过Parse API访问数据库。 所以我想我会为Postgres做同样的事情。 我越读越多的人说，我需要一个中间服务器，以防止从客户端应用程序直接链接到数据库出于安全原因。 我明白这一点，因此节点服务器。
但是，当我使用节点库时，我意识到build立从服务器到数据库的连接非常重要。 在稳定的境界内，我一次只能build立20个连接。 所以，如果我经历了从客户端应用程序到数据库的直接连接，对于数据库来说太过激烈了。
除了安全原因，这是人们推荐在客户端应用程序和数据库之间使用中间服务器层的主要原因吗？
还是有其他的技术原因，我不知道？
应用程序不能直接连接到数据库的原因很简单：应用程序是您已经发布的代码，运行在您无法控制的地方，因此无法使用数据库凭据进行信任。
代码可以被反向devise，并且发现了凭据，现在攻击者可以完全访问数据库，并且可以执行应用程序有权执行的任何操作。
一个中间层创build并强制实现一个关键边界：与数据库交谈的实体可以被信任访问数据库，因为除非devise缺陷，它不会自愿地对数据库做任何事情， 也不会允许任何人要求 。
所有其他的考虑基本上是次要的，即使你解决了这个问题，这个问题依然存在，隐约可见。
数据库可以位于任何后端服务器上，包括Web服务器或任何其他在线服务。
由于Parse不支持PostGres ，您将不得不寻找另一个系统来pipe理您的后端，这也可能对前端交互产生相当大的影响。
你不应该做的是试图find一个前端直接连接到数据库的方式。 这样做会在数据库上造成巨大的负担，也意味着重要的安全问题。
也许这是误会。 今天的Web应用程序不是简单的两层安装程序。 即使是老的XAMPP，WAMPP也是控制器（Model-View-Controller）。
用户不会直接与您的应用程序数据库后端进行交互，他们会看到用户界面和视图层。 后端工作stream程逻辑是您的代码，即控制器。 当您通过您的控制器连接到您的数据库模型。
但是，如果您在视图中引入了一些数据库查询function，则必须对其进行清理。 你介绍多less“中间层”并不重要。
除非您需要高可用性，让您透明地切换后端数据库服务器，或负载平衡应用程序服务器，ORfunction队列服务或OR服务器向外扩展等。没有理由引入不必要的中间件层。 每个中间件都会引入额外的单点故障。
你只需要介绍中间件，而不是因为有人说你需要它们。
中间件示例1：当您有复杂的逻辑需要与不同的数据源进行通信时，使用具有触发逻辑stream程的规则逻辑的中间件，比在应用程序中写入逻辑要好。
中间件实例2：使用消息队列系统将任务，消息，信息集中分发给服务器堆栈进行多处理或分布式处理。 因此，如果特定的应用程序是MQ可识别的，那么您甚至不需要连接到数据库，只需连接到MQ服务器即可。 说完成后，你的应用程序发送信息到另一个队列来通知结果，并让其他应用程序照顾的逻辑。
将数据库模型远离应用程序控制器逻辑听起来很酷，但是有一个平衡点。 您需要了解您的业务需求。