Microsoft将gRPC-Web支持引入.NET



Microsoft已在.NET Core和ASP.NET Core中推出了对gRPC-Web的实验性支持，从而允许直接从.NET Core gRPC客户端和ASP.NET Core gRPC应用程序中调用gRPC-Web。 gRPC-Web与HTTP / 1和HTTP / 2兼容，是一个JavaScript客户端库，支持与gRPC-Node相同的API来访问gRPC服务，而gRPC充当开源RPC框架，使客户端和服务器应用程序可以透明地进行通信。 借助gRPC-Web for .NET，Microsoft希望为浏览器应用程序带来以下功能： 服务器流 紧凑的Protobuf消息 类型强，代码生成的客户端 实验包使ASP.NET Core应用程序无需代理即可支持gRPC-Web，并允许.NET Core gRPC客户端调用gRPC Web服务，这对于Blazor WebAssembly应用程序很有用。除了从浏览器调用ASP.NET Core gRPC应用程序外，gRPC-Web的机会还包括： 从Blazor WebAssembly和Xamarin等平台调用gRPC。 在Azure App Services和IIS中托管ASP.NET Core gRPC应用程序。 使用gRPC-Web，有一个稳定的客户端gRPC-Web JavaScript客户端和一个代理，用于在gRPC和gRPC-Web for services之间进行转换。微软指出，gRPC-Web的性能成本较低，并且不再支持两个gRPC功能（客户端流和双向流）。 为了在.NET中开始使用gRPC，Microsoft已发布了有关在ASP.NET Core中创建gRPC客户端和服务器的教程。使用gRPC-Web，无需更改服务，仅修改启动配置。 gRPC GitHub存储库提供了有关为JavaScript SPA设置gRPC-Web客户端的说明。 紧贴InfoWorld的新闻通讯，以了解软件开发人员，分析师，数据库程序员和数据科学家的情况。 从我们仅限会员的内幕文章中获取专家见解。

Yorumlar

Yorum Gönder

Bu blogdaki popüler yayınlar

GNAP：下一代OAuth

Resim
那是2012年，经过修订的OAuth 2安全协议席卷了整个网络，使用户可以使用安全提供商轻松地登录网站。从AWS的Cognito到Okta的许多单点登录系统都实现了OAuth。 OAuth使您可以“与Google或其他提供商进行身份验证”，以访问完全不同的网站或应用程序。 它像啤酒节一样工作。您到办公桌前用您的ID（和一些钱）进行身份验证，然后他们会给您令牌。从那里，您可以前往每个啤酒帐篷，并为啤酒兑换令牌。 单个酿酒商无需检查您的ID或询问您是否付款。他们只是拿令牌，然后给您啤酒。 OAuth以相同的方式工作，但使用网站而不是啤酒。 可悲的是，OAuth是2020年最好的啤酒节。 我与FusionAuth的Dan Moore谈到了OAuth和拟议的替代品GNAP，如果没有G，则该替代品可能会发音为“小睡”。这种发音进一步说明了安全性是一个令人兴奋的领域。 GNAP解决了OAuth的一些局限性，并为其添加了新功能。 为什么要替换或增强OAuth？ OAuth是围绕浏览器设计的。它假定发出请求的发起者可以处理HTTP重定向。 此Web浏览器焦点是移动应用程序或“物联网”上任何“事物”的绊脚石。此外，像这样的OAuth参与者是200 7，要求您发布表单参数而不是JSON。 OAuth规范在某些地方含糊不清，自2012年以来，世界发生了变化。 RFC和BCP繁多，实质上是您必须实现的附加规范，以实现更多功能，更好的安全性和一般兼容性。名为OAuth 2.1的另一项工作希望将其中一些附加组件折叠成更一致的单一规范。 有关OAuth 2.1的一些动机，请参阅Okta的帖子“改变灯泡需要多少RFC”中的Lee McGovern。 ”与GNAP不同，OAuth 2 1只是一个增量版本，除了将规范堆栈合并为一个规范外，没有新的重大更改。 GNAP规范仍处于早期阶段。 GNAP的作者计划超越OAuth2。 1，并更改协议本身的性质。可以使用JSON来代替HTTP参数。应用程序端点是可发现的。 您不必支持重定向（或绕过重定向的各种方法）。摩尔使用宜人的术语“开发人员人体工程学”来指代这些变化。 GNAP的主要目标是将谁请求资源（RQ）和谁拥有资源（RO）分开。 GNAP还建议支持新的安全功能，例如： 听起来不错？您今天可以开始使用GNAP吗？如果您有兴趣...
Devamı

苹果将\u200b\u200b低级原子操作引入Swift语言

Resim
苹果已经发布了Swift Atomics，这是一个开放源代码软件包，使系统程序员可以直接使用Swift语言构建同步结构，例如并发数据结构。\n\nAtomics库于10月1日推出，可在GitHub上使用，可在Swift中直接使用低级原子操作。在各种Swift类型（包括整数和指针值）上都启用了原子操作。\u003cbr\u003e提供了用于原子操作的API，这些API遵循Swift API的设计原则。\n\n苹果公司确实提供了一些警告：底层的操作工作在非常低的抽象水平上。 Swift标准库团队的苹果工程师Karoy Larentey说，众所周知，原子原子比低级并发结构更难正确使用。\u003cbr\u003e\n\n在swift.org上发布了原子操作的示例：\n\nimport Atomicsimport Dispatchlet counter \u003d ManagedAtomic（0）DispatchQueue.concurrentPerform（iterations：10）{_ in for _ in 0。\u003cbr\u003e。\u003c1_000_000 {counter.wrappingIncrement（by：1，1，ordering：。\u003cbr\u003e relaxed） .load（顺序：.relaxed）//⟹10_000_000\n\n}\n\n作者指出，这些操作不遵循Swift变量的常规排他性规则。\u003cbr\u003e原子操作可以从多个并发的执行线程中执行，只要该值只能通过原子操作访问即可。\n\nAtomics是通过Swift提议而启用的，该提议为Swift采用了C / C ++内存样式，并描述了常规Swift代码如何与原子操作互操作。新程序包中的大多数API均来自演进提案的先前版本。\u003cbr\u003e\n\nAtomics计划要求增加更多类型并改进当前的测试套件。标记原子被注视着，为解决并发数据结构的问题提供了一种工具。已经建立了一个原子论坛来讨论该技术。\u003cbr\u003e另外，还要求支持原子浮点运算。\n\n版权所有©2020 IDG Communications，Inc.\n\n随时了解InfoWorld为软件开发人员，分析师，数据库程序员和数据科学家提供的新闻通讯。\u003cbr\u...
Devamı

2个你不应该相信的云和AI神话

Resim
在技​​术界，我们有两个主要的缺点：我们过于渴望迎接未来，而讽刺的是，如果发展速度不如我们预期的那么快，就无视它。举个例子，今天有两个持续存在的神话：第一，云支出正在使数据中心支出大打折扣；第二，人工智能过度炒作的蛇油在很大程度上使企业购买者失败。 让我们按顺序整理这些。 Gartner开创了第一个神话，分析师Dave Cappuccio认为，到2025年将有80％的企业关闭其数据中心（而2018年则为10％）。好斗吗可以，但是Cappuccio给出了他的思考的一些扎实的理由：“随着互连服务，云提供商，物联网（IoT），边缘服务和SaaS产品的不断增加，留在传统数据中心拓扑结构中的原理将有优势有限。” 原因是数据引力。尽管这种引力作用了一段时间（如果数据存在于数据中心中，但是将其推送到云中进行处理变得效率低下），但现在产生了相反的效果：越来越多的数据诞生于云中，并且将会在那里存储，处理和分析。 但是...数据中心并没有死。 这是David Linthicum在InfoWorld上所做的观察。 Linthicum在Synergy Research Group对数据中心支出的分析中感到高兴，他写道：“在云增长的同时，数据中心支出并未下降。尽管有预测说云将迅速取代数据中心，但这还是可以的。大多数人认为，在云上花费1美元，将是在传统数据中心上花费的1美元。事实并非如此。” 当然，企业的野心与现实可能会大相径庭。 或者，就像泰勒·特雷斯特（Tyler Treat）不太外交地告诉我的那样，“我见过其中一些企业。换句话说，企业可能仍在为数据中心而苦苦挣扎，并且他们准备移动的准备不足。 但是，无论出于何种原因，仍然有这样的情况，就像云一样炙手可热，大约97％的IT支出仍然保留在本地。这并不是要贬低云。这只是根据我们在企业迁移中的实际情况而定的水平。 这使我们进入了神话＃2。 回到Gartner，分析师Nick Heudecker曾经建议大约85％的大数据项目失败。两年后，IDC专注于与大数据相关的AI项目，并将失败率定为50％（针对四分之一的受访者）。 从这样的调查数据中诞生了无数的标题，这些标题基本上都在尖叫：“大多数AI项目都失败了。”这些标题中的隐含含义是对AI背后的技术不成熟的指责。虽然毫无疑问，人工智能将继续发展，但基本真理却有所不同。 一方面，正...
Devamı