Should in-house integrations use our open API and webhooks?

Question

Background

I'm currently working for a relatively small ticketing company with many clients and customers.

We have developed an 'open' (as in it can be used by anyone) Serverless GraphQL API in Node.JS. The API is made up of fine grained services that implement their own security, exposed using GraphQL through AWS API Gateway. We consume this API ourselves to provide functionality to our React web applications.

To compliment the API we also offer webhooks enabling developers to subscribe to key events in our system (e.g. someone buying a ticket, creating an event etc.) facilitating real time integration with other systems.

Complication

We are now looking to integrate with a popular email marketing product where our customer data will automatically flow into mailing lists for multiple client accounts and have to decide if it would be best to develop the email marketing integration logic as a standalone solution that integrates with our system via only our API and webhooks, OR, as services and queues within our API but only exposing 'HTTP endpoints' where necessary to facilitate data flowing back from the email marketing product to our system.

I imagine best practice might be that everything should go through the API/webhooks but it feels weird/clunky configuring and consuming our own webhooks, especially when we have SNS Topics and SQS Queues in place in the backend to manage problems like this. On the other hand if we develop this into our back end we risk hiding valuable functionality that other developers might want to use in future.

Question

Should the integration be developed into our backend alongside our existing services and queues or as a standalone product that communicates with our API and webhooks?

Of course I'd also like to know why, and would really like to know if anyone develops integrations that use your own webhooks, or if webhooks are usually reserved for use by clients.

Thanks in advance for any guidance you have to offer : )

Answer 1

I generally favor the approach of developing integrations on top of my public APIs when possible.

There's a couple reasons for this:

• It lets you leverage existing promises, so you have less to worry about when you need to re-work the innards of the core system.
• It's a good way to verify the quality of your API and maybe clean up some workflows.
• It prevents the core system from becoming too monolithic and unmaintainable. I'm not huge on "microservices" but granular code base packaging is #1 for maintainability in my opinion.
• It reduces the amount of mission critical code, since errors in the integrated product are sub-component failures at worst and won't bring down your whole system.

Good question, I'm interested to hear others approaches!