服务器端Swift任重道远– Matt Massicotte –中

服务器端Swift任重道远

最近我很想起Swift。 大多数情况下，这是因为有关该语言的动态性的讨论。 但是，我已经写过有关此的内容。 昨天，我读了一篇非常有趣的文章，有关称为Vapor的Web框架。 看起来很酷。 我正在考虑踢轮胎。 但是，我也想行使作为互联网公民的权利，也可以提出申诉。 我认为采用Swift作为有用的服务器端工具非常冒险。 此外，如果不自己做大量工作，就不可能在许多任务上使用Swift。

宣布几个月后，Crashlytics将Swift引入我们的生产服务器端基础架构中，我们就一直在运行它，这可能会让您感到惊讶。 公平地说，这只是一小段代码。 我们使用它将残缺不清的Swift符号转换为更易理解的形式。 但是，我们必须将其包装在Objective-C中。 为什么？ 因为我们必须将其托管在Go流程中。 为什么？ 因为我们需要与称为NSQ（http://nsq.io）的队列服务器（我很喜欢并强烈建议）进行对话。 Swift没有NSQ客户端。

自己编写客户是可能的，但这将是一项艰巨的任务。 我们不久前就谈到了这一点，但最终决定，这笔投资太大，收益太少。 那是因为在NSQ客户端之上，我还不知道对statsd的支持。 我们将statsd用于通过石墨的服务器端监视。 没有监控，我们就无法在生产中运行事物。 Go也对此提供了大力支持。

我很高兴看到Swift获得对服务器端工作的支持。 我并不高兴将速度作为主要重点，但这是可以理解的。 （顺便说一句，我很想看看它与Go和DropWizard的比较。我们的Go端点具有不到毫秒的响应时间。）我认为Swift确实会为Go和Java带来真正的收益，长期的。 但是，Go如今拥有大量高质量的客户。 我四处闲逛，确实找到了一些Kafka和MySQL的Swift客户端。 这很有希望，但不足以构建您可以依赖的东西。 除非我们为队列服务器，数据库和其他服务器端基础结构提供一些经过考验的客户端，否则我认为服务器端Swift是一个入门者。

当然，我知道您必须从某个地方开始。 蒸气看起来是一个不错的开始。 谁知道，也许新苹果公司为他们正在运行的那个巨大集群提供了一个强大的工具，并且即将开放源代码的Swift Cassandra驱动程序🙂