我们选择Telegram作为团队应用程序，而不是Slake和Microsoft Team，然后移动

为什么我们选择Telegram用于团队应用程序，而不是Slake和Microsoft Team，然后又放弃它-从构建团队应用程序中学到的教训。

我们是一家中型公司，主要为银行和金融部门开发软件。我们最近为我们的公司创建了一个团队应用程序。本文的目标是展示我们如何构建一个安全的团队应用程序，以及我们所经历的各种选项。

我们的大部分劳动力由软件工程师组成。当我们作为一家只有几名员工的小公司起步时，一切都很顺利。我们只是使用常规的老式Gmail来管理任务和公司决策。为了进行更个人化和更内部的交流，我们使用了WhatsApp。由于每个人都熟悉WhatsApp，所以很容易将消息快速发送到群组。然而，随着我们的成长，Gmail+WhatsApp的模式势不可挡。

然后大流行发生了，我们中的大多数人不得不远程工作，我们没有使用太多的企业生产力工具。沟通和联系变得越来越困难。

事情似乎正在失控，我们决定是时候建立一个适当的团队沟通渠道了。我们开始查看推荐以及其他人也在使用的内容。最受欢迎的选择是Slake和微软团队。我们决定尝试Slake，因为微软团队更倾向于使用完整的Microsoft工具包，而我们使用的Microsoft工具和服务并不多。

Slak拥有压倒性的用户界面和手感。然而，许多功能根本不需要，UI与我们熟悉的其他通讯应用程序(如WhatsApp)不同。此外，每个用户每月7美元左右的价格计划，加上基本价，是远远不可持续的。此外，由於我们的劳动力正迅速增加，按目前的规模估计成本并不审慎。在我们的情况下，订阅成本只会继续增长。

另一个危险信号是GDPR和隐私。由于我们在欧盟法规下运营，我们受到GDPR的监管，GDPR涵盖员工和客户数据。因此，我们联系了Slake，表达了我们的担忧，支持团队将我们推荐到他们的GDPR页面。然而，这并没有帮助，事实上，我们没有从松弛在他们的欧盟服务器位置得到任何肯定的回答。作为金融界的一员，遵守规定对我们来说是非常重要的。一种可能的解决方案是在我们的服务器上部署Slake，然后着手保护我们的数据。但是，事实证明没有部署内部部署的选项。

在价格区间的低端还有其他功能不那么令人印象深刻的解决方案，但它们都不能完全满足我们的需求。

确保安全和隐私。我们关心的是如何控制我们的数据，因为我们要处理大量敏感的金融数据。

由于Slake和微软团队听起来都不太乐观，我们决定检查一下在内部开发解决方案的可能性。我们没想到会很轻松，但当我们在giHub(https://github.com/DrKLO/Telegram)，)上找到Telegram的源代码时，我们既兴奋又松了一口气，任务可能比我们最初预期的要容易。

电报不需要介绍，它是一个很好的安全通信平台。值得注意的是，随着WhatsApp、Messenger等主要通信工具受到威胁，Telegram-一个基于云的高度加密的免费平台-已经站稳了脚跟。没有理由把目光投向别处，我们决定建立基于电报的通信工具。

但是，惊喜在等着我们，虽然不是令人愉快的。当我们开始使用Telegram源代码构建我们的应用程序时，我们意识到问题隐藏在显而易见的地方。

Telegram不是SDK或API平台。尽管Telegram消息传递应用程序本身是一个构建良好的工具，但它没有提供任何扩展或将其复制到应用程序中的功能。API远远不完整，对自定义功能的支持有限。

Telegram在他们的辩护中提到，他们是一个开源应用程序，而不是SDK。他们已经公开了他们所有的代码，并希望您能弄清楚如何使用它。

我们不介意花很多精力和时间去“想清楚”。但是，完全破坏交易的是发布结果解决方案也是开源的条件。

限制还在继续。尽管Telegram是一个开源应用程序，但如果需要，您不能使用Telegram的源代码并重新标记它。几乎没有构建完全独立的应用程序的余地。任何建立在Telegram之上的应用程序都需要突出显示Telegram的徽标。这完全违背了我们公司申请品牌的目的。

当您使用Telegram构建应用程序时，它又会与与用户链接的Telegram帐户和其他Telegram元数据同步。但是，这不是一个可选的步骤。您的应用程序不能作为独立实体生成，也不能使用您自己的身份验证。Telegram API唯一允许的事情就是与它们的数据和怪癖交互。这给企业环境中的用户管理带来了问题。

使用Telegram构建您的应用程序意味着我们可以连接Telegram云服务器。我们陷入了和以前一样的问题。

如果您希望在您的服务器上托管电报，这是行不通的。作为银行和金融行业的一员，我们必须在我们的服务器上部署这个应用程序。

没有简单可靠的扩展API可以构建在基础平台之上。看起来Telegram只是作为一款现成的一次性应用程序使用，没有其他我们可以修改的功能。

我们还遇到许多其他人报告了与Telegram类似的担忧和问题，比如这个，如果我们以前读过的话，会节省很多时间。我们对目前的解决方案感到失望，于是开始寻找更好的解决方案--一种完全符合我们需求的解决方案。

我们开始寻找更多的解决方案，发现了许多好的产品，比如谷歌的Firebase，我们觉得这些产品不必要地复杂和昂贵。我们还收到了一些使用Sendbird和Agora等消息传递API平台的建议，我们对此并不完全信服。有一次，我们很沮丧，我们的一位工程师建议我们应该从头开始建造整个东西！完全疯狂的想法。但是，是的，我们很快就没有时间和选择了。

Mesibo是一个相对较新的进入者，但似乎是我们遇到的强大的解决方案。我们越是沉迷于mesibo，我们就越爱上它提供的平台和功能，而且几乎没有付出任何代价。

我们在他们名为mesibo Messenger的开源消息应用程序中遇到了mesibo，这款应用可以在Android和iOS上使用。我们认为UI相当不错，没有任何令人分心的功能。我们所有的员工都可以很容易地使用这个应用程序，没有任何学习上的问题。

由于该应用程序的全部源代码都可以在GitHub上找到，因此我们研究了如何定制该应用程序。我们希望使用我们公司的颜色、横幅、徽标，更重要的是将其与内部员工办公桌相结合。幸运的是，Mesibo提供了Android、iOS和其他SDK，我们能够快速定制这款应用。好的一面是，没有电报那样的限制性许可证，也没有像Slake那样过高的定价。

我们注意到，与我们早先使用的Slake和Telegram等应用程序相比，消息和文件交换速度似乎更快，更重要的是，我们可以使用自己的服务器来存储数据。我们的团队交换了许多大文件和收据图像，他们报告说，在我们刚刚构建的应用程序上发送文件要快得多。

我们面临的一个问题是，mesibo演示应用程序使用基于手机的身份验证，而我们希望使用我们自己的员工ID，这要求我们创建新的屏幕来取代mesibo演示应用程序中基于手机的身份验证。

现在，这个应用程序托管在mesibo云上。尽管该平台与GDPR兼容，但我们更愿意将应用程序托管在我们的服务器上。我们这样做的主要原因是我们不能冒我们自己的内部和私人通信数据被泄露的风险。幸运的是，整个mesibo平台都可以免费下载。

有了Mesibo On-Premise解决方案，我们决定在我们的服务器上托管Mesibo，然后运行应用程序。我们下载了mesibo坞站映像，它在我们的服务器上运行时没有任何问题。文档非常清楚。如果您以前设置过Web服务器和数据库，在您自己的服务器上设置整个mesibo平台只需不到一个小时。

这个价格对我们来说更有意义，因为它是基于月度活跃用户(MAU)的，而且每个MAU每月只有0.01美元(相比之下，Slake的每个用户每月7美元)。这几乎是一笔很大的交易，有300多名员工，每月加起来只有3美元左右。想象一下，如果我们使用Slake，我们将花费2100美元。事实还表明，由于数据存储成本为零，他们的内部定价甚至更便宜。此外，我们还可以选择为办公室中的不同部门创建多个应用程序，并在同一中央帐户下管理所有这些应用程序。

这是意想不到的--我们甚至一开始都没有想到这些功能，但是我们用mesibo完全免费。有了Mesibo，我们可以进行无限的语音和视频通话。Mesibo还提供了视频会议功能，以及一个开源的网络应用程序，我们用自己的品牌&；Colors进行了修改，以便与我们的网站集成，不再使用Zoom。

我们发现它特别有用，因为它没有通话时长或会议参与者数量的限制，而且我们收到了反馈，认为通话质量要好得多。我们的团队沟通渠道看起来很完整，有视频会议和消息。

我们还添加了一些更多的功能，比如显示组织结构图和查看谁当前在线。Mesibo有很多有趣的功能，我们还没有探索和试验，比如聊天机器人脚本服务。这对于创建一个交互式的HR聊天机器人很有用，员工可以通过它来管理一些小任务，比如申请休假等。

凭借非限制性许可、品牌UI、视频会议和内部部署等强大功能，mesibo为我们勾选了所有合适的选项，我们仍在探索各种功能。值得注意的是，虽然Slake和微软团队等工具在华而不实的功能方面不断改进，但它们在服务隐私需求方面似乎并没有变得更好。Telegram要为其用户提供更多正确的服务，还有很长的路要走。

在我们更多地使用这个平台之后，我们一定会写下我们的经验。如果您有任何问题，请发表意见。