完全在客户端使用持久化数据存储

您有 localStorage。您也有 IndexedDB。它们都位于客户端并且能够存储数据，但仅限于单个浏览器。我无法在笔记本电脑上存储数据，然后稍后在手机上访问并获得相同的数据。网站使用后端数据库来实现这种功能。数据存储在其他地方，因此您可以在任何地方访问。

但是，如果您不想处理后端呢？有一些第三方解决方案可以解决这个问题。

Firebase

Firebase 提供 “实时数据库”功能，因此，您不仅可以从客户端收集、存储和发送数据，而且这些数据还可以在当前连接到同一数据库的任何其他设备之间同步（如果您需要这样做）。

Firebase 实时数据库不使用典型的 HTTP 请求，而是使用数据同步——每次数据更改时，任何连接的设备都会在几毫秒内收到该更新。

这只是 Firebase 的众多功能之一。它还具有身份验证、消息传递和文件存储等功能，所有这些功能加起来形成了一个非常引人注目的基础架构，可以用来构建应用程序。

Airtable

我们之前已经介绍过如何将 Airtable 用作前端开发人员。它是一个非常不错的类似电子表格的界面，用于存储任何类型的数据。您当然可以自己输入数据，其 UI 非常适合此目的，或者可以通过基于您设置的数据结构自动创建的表单来收集数据。它还可以连接到大量其他应用程序以收集数据。

您还可以通过 API 发送和检索数据，这些 API 可以完全在客户端工作。很酷。

Fieldbook

Fieldbook 也用于数据存储，但从电子表格 UI 开始。我喜欢这个想法，它可以让用户思考其业务背后的数据，并赋予他们组织、连接、收集和使用这些数据的控制权。

Fieldbook 有 API，允许您完全在客户端使用数据。

Ben Orozco 撰写了一篇关于使用它为 Ember.js 应用程序提供支持的文章。对我来说，正是这种感觉非常酷和强大的东西。这些服务具有 JSON API，并且许多现代框架都具有基于 JSON 的状态管理，它们看起来像是天作之合，并且可以为前端人员提供极大的帮助。

选择一种

我对这些产品的经验不足，无法就使用哪种产品提供建议。在我看来，它们都令人印象深刻，值得查看其定价和功能集以及免费试用等。

一个非常重要的区别是身份验证。

Airtable 使用“简单的基于令牌的身份验证”，这意味着 API 密钥。如果您从网站上使用它，那么任何可以看到该网站的人都可以看到该密钥，并有权对该“表”执行任何操作。

Fieldbook 使用基本身份验证，这意味着您必须在 Ajax 请求中传递身份验证头才能执行操作。这最终与 API 密钥和密钥生成标头相同，任何可以查看使用 API 的网站的人员都将拥有这些信息，并且可以访问该“簿记”。

我相信 Firebase 拥有最强大的身份验证系统。他们将身份验证作为软件包的一部分提供，例如针对您应用程序的用户本身。“使用 Twitter 登录！”（或 Facebook、Google 或任何其他 OAuth 提供商）。然后，您可以使用相同的系统为不同的用户提供不同的访问级别，包括您自己。例如，如果您以自己的身份进行身份验证，则可以构建/查看不同的 UI，允许您以管理员身份在应用程序中执行更多操作，但其他以普通用户身份进行身份验证的人员则可以看到您的常规网站。

Steven

# 2017年4月12日

我还没有积极使用它，但 graph.cool 也看起来很有希望，尤其是在它使用 GraphQL 查询数据的情况下。我认为它本身有一个简单身份验证 API，但可以连接到其他服务（如 Auth0）以实现更复杂的实现。

Paul d'Aoust

# 2017年4月13日

对于那些需要您在客户端公开身份验证凭据的服务，如何在服务器上使用一个简单的代理来提供您的网站？它不必复杂；以下是 Nginx 用户的一个示例

location /airtable-proxy {
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-NginX-Proxy true;
  proxy_set_header Authorization Bearer _MY_AIRTABLE_API_KEY_
  proxy_pass https://api.airtable.com/v0/_MY_AIRTABLE_APP_ID_;
  proxy_ssl_session_reuse off;
  proxy_redirect off;
}

（其中_MY_AIRTABLE_API_KEY_ 和 _MY_AIRTABLE_APP_ID_ 当然会被替换为您自己的值）。这是一篇很棒的小文章，详细介绍了更多信息（它这样做是为了避免跨源 AJAX 请求的问题，而不是隐藏机密，但实现方式类似）

Chris Coyier

评论永久链接# 2017年4月14日

是的！如果可能，这就是最佳做法。这样，您就可以 99% 在客户端进行操作，但仍然可以隐藏 API 密钥等。

唯一的缺点是您仍然需要服务器和服务器访问权限，这意味着您无法使用 CodePen 项目或 GitHub Pages 或类似的东西。
Theo

评论永久链接# 2017年4月14日

如果您使用代理来隐藏密钥，但基本上只是将所有内容转发到服务，那么是什么阻止了某人简单地使用您的代理随意获取和修改您的数据？

在我看来，您服务器上的内容不应该是简单的代理，而应该进行身份验证或至少进行某种服务器端验证。或者我错过了什么？
Chris Coyier

评论永久链接# 2017年4月15日

我相信也有一些方法可以处理这种情况，具体取决于您想要实现的复杂程度。您可以检查推荐来源，这将阻止一般随机用户访问服务，但不能提供完美的覆盖范围，因为推荐来源可能被伪造。您可以进行某种随机数生成并进行检查。我相信后端极客已经很大程度上解决了这类问题。

Sean O

# 2017年4月17日

只是好奇这些提供商的一些隐私问题——假设我有一些敏感的用户数据，我永远不想将其公开给 Google 或任何其他大型数据聚合器，这些提供商会将这些用户数据保密吗？我还没有深入研究每个条款和条件，但我很想知道。

Chris Coyier

# 2017年4月27日

另一个需要考虑的！

Google Sheets 是免费的（您可以创建电子表格，就像 Excel 或其他任何电子表格一样，加上 Google 表单并输出到其中）。

Google Sheets 有一个 API（v4 是最新版本：https://developers.google.com/sheets/api/），允许您读取和写入数据。

它有身份验证，并且可以使用 JavaScript 进行操作：https://developers.google.com/sheets/api/quickstart/js

Sheetsu 是一种工具（我认为）可以使 API 更易于处理：https://sheetsu.com/

此评论线程已关闭。如果您有重要信息需要分享，请联系我们。