假設檢驗方差未知

by Rick Mak

麥瑞克(Rick Mak)

設計云數據庫時如何處理未知數并做出假設 (How to handle unknowns and make assumptions when designing a cloud database)

Say you’re a developer who wants to build a note taking app. Let’s look at one feature detail with huge implications on your back-end. To write a note, your app will need to be able to save the data.

假設您是一名開發人員，想開發一個筆記應用程序。讓我們來看一個對后端有重大影響的功能細節。要寫筆記，您的應用將需要能夠保存數據。

Saving a record to a database is straight forward. The key questions are:

將記錄保存到數據庫很簡單。關鍵問題是：

Who will need to access that record?
誰需要訪問該記錄？
Will it only be your user, or will your user share it with others?
它只會是您的用戶，還是會與他人共享？
Will your product be shoe-box app or a social app?
您的產品是鞋盒應用還是社交應用？

If you intend for the notes to be private to the author, you may conclude that you are making a shoe-box app. This means all data goes to a private DB (database).

如果您打算使注釋對作者不公開，則可以得出結論，您正在制作鞋盒應用程序。這意味著所有數據都將進入私有DB(數據庫)。

If you intend for your app to share notes with others, you may conclude it should be a public DB.

如果您打算讓您的應用與他人共享筆記，則可以得出結論，它應該是公共數據庫。

But will you know which it is before you start?

但是在開始之前您會知道是哪個嗎？

And what will you do if you need to change your product as you go? Public DB and private DB isn’t the first thing most developers think about when they’re building an app. We encountered these question when we were building our back-end product for our developers, Skygear.

如果您需要隨時隨地更改產品，該怎么辦？大多數開發人員在構建應用程序時都不會想到公共數據庫和私有數據庫。在為開發人員Skygear構建后端產品時，我們遇到了這些問題。

Because of our experience in building apps for clients, we assumed there was a right choice of database. And that our user would know how to choose.

基于我們在為客戶構建應用程序方面的經驗，我們認為數據庫是正確的選擇。而且我們的用戶會知道如何選擇。

How do you build a back-end for developers who aren’t sure of their products needs yet? Or for those who want to keep their options open in the future?

您如何為尚不確定其產品需求的開發人員構建后端？還是對于那些希望將來保留其選擇權的人？

As the tech lead in the project, I’d like to share with you our decision making process from 2 years ago. I hope it helps future development teams approach unknowns and assumptions.

作為該項目的技術負責人，我想與您分享我們2年前的決策過程。我希望它可以幫助未來的開發團隊應對未知和假設。

為什么我們開始考慮私有數據庫與公共數據庫？ (Why did we start thinking about private vs public DBs?)

Many apps require a back-end to store and query user data. The back-end is a lot of hard work to build and, let’s face it — not so enjoyable to create. Skygear is our open-source serverless back-end. It helps address common development features for mobile and web apps.

許多應用程序需要后端來存儲和查詢用戶數據。后端是很多艱苦的工作，而讓我們面對現實-創建起來并不那么愉快。 Skygear是我們的開源無服務器后端。它有助于解決移動和Web應用程序的常見開發功能。

The feature I’ll talk about is our Cloud DB, where you store and query user data. When we started to design Cloud DB, we asked ourselves how different apps store and query user data.

我將討論的功能是我們的Cloud DB，您可以在其中存儲和查詢用戶數據。當我們開始設計Cloud DB時，我們自問不同的應用程序如何存儲和查詢用戶數據。

We looked at our company’s mobile apps portfolio for inspiration. Our company does everything from consumer apps to e-commerce apps. So we grouped them into “shoe-box” and “social” apps.

我們從公司的移動應用程序組合中尋找靈感。從消費類應用程序到電子商務應用程序，我們公司都應運而生。因此，我們將它們分為“鞋盒”和“社交”應用。

Shoe-box apps store personal data that the user wants to keep private. For example, our side project Spentable helps a user track of their daily spending. Data stored in the app is meant to be private, in a shoe-box.

鞋盒應用程序存儲用戶想要保密的個人數據。例如，我們的輔助項目Spentable可幫助用戶跟蹤他們的每日支出。應用程序中存儲的數據是在鞋盒中私有的。

But, there is stuff that we want to share publicly or with friends. That also means the user needs to be in control of who can read their data. These two kinds of apps present a challenge in how we designed Skygear’s Cloud DB. We wanted to make storing data in Cloud DB as easy as possible. For shoe-box apps, all the developers need is a database where each user can only see the data that they are putting in. Yet, in social apps, developers need features such as ACL (access control). How can we make things simple for developers of both kinds of apps?

但是，有些東西我們要公開或與朋友分享。這也意味著用戶需要控制誰可以讀取其數據。這兩種應用程序對我們如何設計Skygear的Cloud DB提出了挑戰。我們希望使數據存儲在Cloud DB中盡可能容易。對于鞋盒應用程序，開發人員所需的只是一個數據庫，每個用戶只能在其中查看他們所放入的數據。然而，在社交應用程序中，開發人員需要ACL(訪問控制)等功能。對于兩種應用程序的開發人員，我們如何使事情變得簡單？

吃我們的蛋糕也吃 (Having our cake and eating it too)

We decided to solve this problem by introducing the concept of multiple databases in the Cloud DB: private DB and public DB. Each user has a private DB to put data in, and that data is only available to the same user. The app also has one public DB that is shared among all users.

我們決定通過在Cloud DB中引入多個數據庫的概念來解決此問題：私有DB和公共DB。每個用戶都有一個專用數據庫來放入數據，并且該數據僅可用于同一用戶。該應用程序還具有一個公共數據庫，該數據庫在所有用戶之間共享。

A shoe-box app developer is able to focus on saving and fetching the data without worrying about permissions because data in the private DB is always private.

鞋盒應用程序開發人員能夠專注于保存和獲取數據而無需擔心權限，因為私有DB中的數據始終是私有的。

But, private DB does not work at all for social apps. Developers for social apps should put data in the public DB because data in social apps are meant to be shared.

但是，私有數據庫根本不適用于社交應用程序。社交應用程序的開發人員應將數據放入公共數據庫中，因為社交應用程序中的數據是要共享的。

Before we added support for ACL, this simple distinction for public and private data served us(and our users very well. Everything in private DB is truly private while everything is public DB is truly public.

在添加對ACL的支持之前，對公共數據和私有數據的這種簡單區分對我們(以及我們的用戶)都非常有用。私有DB中的所有內容都是真正的私有，而公共DB中的所有內容都是真正的公共。

“Everything is public” is not good enough. Most social apps have use cases that data is only shared among a group of friends.

“一切都是公共的”還不夠好。大多數社交應用都有用例，數據僅在一組朋友之間共享。

ACL is another difficult and interesting topic that should be it’s own article.

ACL是另一個困難而有趣的主題，應該是它自己的文章。

我們無法同時利用這兩個數據庫的優勢 (We couldn’t have the best of both databases)

Separating the DB into private and public ones was a good idea. We thought they supported the use case for majority of apps.

將數據庫分為私有和公共數據庫是一個好主意。我們認為他們支持大多數應用程序的用例。

But early adopters found our private and public options confusing.

但是，早期采用者發現我們的私有和公共選擇令人困惑。

Our early users gave us invaluable feedback. We also paid attention to the support questions we received. This is what we learned from developer feedback when they used our Cloud DB:

我們的早期用戶給了我們寶貴的反饋。我們還關注收到的支持問題。這是我們從開發人員使用Cloud DB時的反饋中學到的：

It’s not obvious to developers what they’re building at first
對于開發人員而言，起初他們正在構建的東西并不明顯

While it may be obvious which kind of app developer made by looking at the product retroactively, it is not obvious from the get-go. Forcing the developer to decide whether they are making a shoe-box or social app at the beginning is difficult, if not impossible.
回顧性地看待哪種應用程序開發人員可能很明顯，但從一開始就并不明顯。強迫開發人員決定一開始是制作鞋盒還是社交應用是困難的，即使不是不可能的。
Developers just want to get started quickly
開發人員只想快速入門

We want the developers to learn the basics as quickly as possible. Having to learn one more concept to choose which DB to use before they can actually save and retrieve data is too much to ask for new users.
我們希望開發人員盡快學習基礎知識。在實際保存和檢索數據之前，必須學習另一個概念來選擇要使用的數據庫，這對于尋求新用戶來說實在太多了。
The decision for public or private DB, once made, isn’t easy to reverse
一旦做出公共或私有數據庫的決定，就不容易撤銷

Suppose that a developer started with a shoe-box app idea and they put everything in the private DB. Later they may realize that they should make the app a social one instead. It is not easy to migrate data once they are put into a particular DB.
假設開發人員從一個鞋盒式應用想法開始，然后將所有內容都放入了私有數據庫中。后來他們可能意識到，他們應該改為使該應用程序成為社交應用程序。將數據放入特定的數據庫后，遷移數據并不容易。
Permissions are usually an after thought
許可通常是事后的想法

Data security a priority in our company. But data security is not the first thing that comes to the mind of a developer. Especially when they’re just doing a proof-of-concept prototype. They want to focus on the functionality first, and take care of the security later on.
數據安全是我們公司的首要任務。但是，數據安全性并不是開發人員想到的第一件事。尤其是當他們只是在做概念驗證原型時。他們想先關注功能，然后再注意安全性。

我們的外賣 (Our takeaways)

We are always thinking about how we could make our products better. We could do better in terms of software architecture, user documentation and ease-of-use. We sometimes brainstorm what we would do if we could rewind the clock two years to start over. But here is what we would tell our former selves:

我們一直在思考如何使我們的產品更好。我們可以在軟件體系結構，用戶文檔和易用性方面做得更好。有時我們會集思廣益，如果我們可以倒退時鐘以重新開始兩年。但是，這就是我們要告訴我們以前的自我：

If developers are already familiar with an existing concept, adopt it
如果開發人員已經熟悉現有概念，則采用它

Most developers are familiar with the concept of a database. It is a container of some sort where developers can save content. They can also retrieve data and support the CRUD (Create, Read, Update, and Delete ) property.
大多數開發人員都熟悉數據庫的概念。它是開發人員可以保存內容的某種容器。他們還可以檢索數據并支持CRUD(創建，讀取，更新和刪除)屬性。

Because developers are already familiar with the concept of a database, they would find a single database on Cloud DB straight-forward to use.
因為開發人員已經熟悉數據庫的概念，所以他們可以直接在Cloud DB上找到一個數據庫來使用。
Introduce new concepts when developers are prepared for them
在開發人員為新概念做好準備時引入新概念

This idea is actually an other way of saying that we should make the learning curve as easy as possible. Skygear was a prototype in its own way. We just launched V
這個想法實際上是說我們應該使學習曲線盡可能容易的另一種說法。 Skygear本身就是一個原型。我們剛剛推出了V

1.0!.
1.0 ！。

You never want to make life for your early adopters difficult. Having to learn everything before developers can do anything does not work well from a product perspective. Until developers need to think about data permission, they should not need to know about the difference between a private DB and public DB. We should let our users get started with the common concepts first to familiarize themselves with a new platform.
您永遠都不想讓早期采用者的生活變得困難。從產品的角度來看，必須學習所有知識之后開發人員才能做任何事情。除非開發人員需要考慮數據許可權，否則他們無需了解私有數據庫和公共數據庫之間的區別。我們應該首先讓用戶開始使用通用概念，以熟悉新平臺。

Only after they’re comfortable should we introduce new concepts to provide more options. In this case, there’s no harm for a developer to discover they need ACL so the new concept is a natural next step after they have learned how to use Cloud DB.
只有在他們感到舒適之后，我們才可以引入新概念來提供更多選擇。在這種情況下，對于開發人員來說發現他們需要ACL并沒有什么害處，因此，新概念是學習了如何使用Cloud DB之后自然而然的下一步。

我們學到了什么 (What we learned)

When we began working on Skygear two years ago, we wanted to build a kick-ass product with 2–4 of our senior developers. We had ready testers from our own in-house developers, who gave lots of critical feedback. We thought we were using our experience in web and mobile app development to make better decisions on how to design tools for other developers.

兩年前，當我們開始從事Skygear的開發時，我們想與2-4位高級開發人員一起開發踢球產品。我們有自己的內部開發人員準備的測試人員，他們提供了許多關鍵的反饋。我們認為我們正在利用我們在Web和移動應用程序開發方面的經驗來就如何為其他開發人員設計工具做出更好的決策。

But our experience also created assumptions about what to expect our users to know before using our product.

但是，我們的經驗還為用戶在使用我們的產品之前應了解的知識做出了假設。

The good thing about getting user feedback on Cloud DB as we went was that we learned that our assumptions were incorrect. Our most valuable lesson was the humbling reminder of a basic startup principle. No matter our experience, we often don’t know exactly what we’re building.

在進行過程中獲得有關Cloud DB的用戶反饋的好處是，我們了解到我們的假設是錯誤的。我們最有價值的一課是謙卑地提醒人們一個基本的啟動原則。不管我們的經驗如何，我們通常都不完全知道我們要構建什么。

Of course, that doesn’t stop us from trying to build that philosopher’s stone to make lives easier for our fellow developers anyway. As my co-founder, Ben, said one of his most productive days was when he tossed 1000 lines of code away.

當然，這并不能阻止我們嘗試建立哲學家的石頭，以使??我們的其他開發人員的生活更加輕松。正如我的聯合創始人本(Ben)所說，他最富有成效的日子之一是他丟掉了1000行代碼。

I would like to credit my colleague cheungpat who worked on the Cloud DB with me and helped write this piece.

我想感謝我的同事cheungpat和我一起在Cloud DB上工作，并幫助撰寫了這篇文章。

My team would love to hear your critical feedback for Skygear. Also check out our documentation and GitHub repos to see how we discuss Skygear features.

我的團隊很想聽聽您對Skygear的重要反饋。另請查看我們的文檔和GitHub存儲庫，以了解我們如何討論Skygear功能。