首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >内部集成应该使用我们的开放API和web挂钩吗?

内部集成应该使用我们的开放API和web挂钩吗?
EN

Software Engineering用户
提问于 2018-09-11 09:55:45
回答 1查看 135关注 0票数 1

背景

我目前在一家规模相对较小的票务公司工作,有许多客户和客户。

我们在GraphQL中开发了一个'open‘(任何人都可以使用)无服务器的Node.JS API,该API是由细粒度的服务组成的,这些服务实现了自己的安全性,通过API网关使用GraphQL公开。我们自己使用这个API来为我们的反应性web应用程序提供功能。

为了补充API,我们还提供webhooks,使开发人员能够订阅系统中的关键事件(例如,有人购买门票、创建事件等)。促进与其他系统的实时集成。

并发症

我们现在希望与一种流行的电子邮件营销产品集成,在该产品中,我们的客户数据将自动流入多个客户帐户的邮件列表,并必须决定是否最好开发电子邮件营销集成逻辑,将其作为一种独立的解决方案,仅通过我们的API和webhooks、OR作为服务和队列集成到我们的API中,但只在必要时公开“HTTP端点”,以便利从电子邮件营销产品返回到我们系统的数据。

我认为最好的实践可能是,所有的东西都应该通过API/web挂钩,但是配置和使用我们自己的we钩子感觉很奇怪/笨重,特别是当我们在后端设置了SNS Topics和SQS队列来管理这样的问题时。另一方面,如果我们将其开发到后端,则可能会隐藏其他开发人员将来可能希望使用的宝贵功能。

问题

集成应该与我们现有的服务和队列一起开发到我们的后端,还是作为一个独立的产品与我们的API和web挂钩进行通信?

当然,我也想知道为什么,我真的很想知道是否有人开发了使用您自己的webhooks的集成,或者webhooks通常是保留给客户使用的。

预先感谢您所提供的任何指导:)

EN

回答 1

Software Engineering用户

发布于 2018-09-12 00:38:31

如果可能的话,我通常支持在公共API之上开发集成的方法。

这有几个原因:

  • 它允许您利用现有的承诺,因此当您需要重新处理核心系统的内部时,您就不用担心了。
  • 这是验证API质量并可能清理一些工作流的好方法。
  • 它防止了核心系统变得过于单一和不可维护。我对“微服务”不是很了解,但在我看来,细粒度的代码库打包是维护性的第一步。
  • 它减少了任务关键代码的数量,因为集成产品中的错误在最坏的情况下是子组件故障,不会使整个系统崩溃。

问得好,我很想听别人接近我!

票数 4
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/378273

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档