# Monolith to Microservice: Architecture Behind V2 Webhooks

DevFeed: [Monolith to Microservice: Architecture Behind V2 Webhooks](<https://devfeed.tech/articles/monolith-to-microservice-architecture-behind-v2-webhooks-35100.md>)

Original publisher: [Read original article](<https://engineroom.teamwork.com/monolith-to-microservice-architecture-behind-v2-webhooks-27789c36ace9?source=rss----cea4eecd5960---4>)

Author: Paulius Jakimavičius

Published: 2017-09-11T15:09:33Z

Content type: article

Language: en

Sources: [Teamwork](<https://devfeed.tech/sources/teamwork.md>)

Topics: [Microservice](<https://devfeed.tech/topics/microservice.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Go Language](<https://devfeed.tech/topics/go-language.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [JSON](<https://devfeed.tech/topics/json.md>), [XML](<https://devfeed.tech/topics/xml.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [callback](<https://devfeed.tech/topics/callback.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [go](<https://devfeed.tech/tags/go.md>), [http](<https://devfeed.tech/tags/http.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [json](<https://devfeed.tech/tags/json.md>), [microservice-architecture](<https://devfeed.tech/tags/microservice-architecture.md>), [sha256](<https://devfeed.tech/tags/sha256.md>), [teamwork](<https://devfeed.tech/tags/teamwork.md>), [teamwork-project](<https://devfeed.tech/tags/teamwork-project.md>), [webhooks](<https://devfeed.tech/tags/webhooks.md>), [xml](<https://devfeed.tech/tags/xml.md>)

## AI overview

This article explains the redesign of Teamwork Projects webhooks from a monolithic implementation to a Go microservice. The update supports multiple webhooks per event, sends complete datasets in JSON, XML, or form format, adds SHA-256 checksums, and uses more frequent retry intervals.

## Source excerpt

We've recently released an update to the Teamwork Projects webhooks feature and I was asked to do a tech talk on the topic, a recording of which can be found below. This article is a rough summary of the talk with further elaboration of the thought process behind some of our decisions, but in summary: We have a microservice written in Go. We now support multiple webhooks per-event We send full datasets in chosen format (JSON, XML or Form) We offer better security and integrity with sha256 checksums We have more frequent retry intervals. https://medium.com/media/1208334bf98663ab7d55e4d2eaad4c95/hrefWhat are Webhooks? The basic idea of webhooks is simple -- it's a HTTP POST call triggered when some event occurs. You can think of it like a JavaScript callback, except it's a HTTP POST that can be sent anywhere, to anyone -- not limited to a single codebase or domain. In the case of Teamwork Projects, we have a set list of possible events you can subscribe to, denoted in OBJECT.ACTION style, so for example TASK.CREATED or MESSAGE.DELETED. Previous Approach (v1) Our original approach was no more complicated than the concept of webhooks itself -- when any of the supported actions are taken in Projects, a "fireWebhook" function is called, which checks if they're enabled and if there is a webhook set up for that event. If all is good -- we make a cfhttp call to the relevant URL with the item ID, item type and the action taken, all encoded as form data. Now there are a few limitations with this approach which showed up as the number of webhook users increased over time: Only one webhook per event -- although it made sense as a sort of anti-spam measure initially, this resulted in a few inconveniences for our customers. For example, a user sets up a TASK.CREATED webhook that notifies a custom service which adds the task ID to their internal database. This would make it impossible for them to later set up, say a Zapier zap using TASK.CREATED event as it is already "in use". Limited