1

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 : )

|improve this question
4

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!

|improve this answer
  • Thanks for your reply Robin! I agree with you but do you think dogfooding webhooks is common/good practice? Feels clumsy to me. This is really what's at the heart of my hesitation. – Dan Sep 12 '18 at 2:07
  • We have abstracted helper functions for 'services' (e.g. get-events) and 'system events' (SNS) which load up 'queues' (SQS) that invoke 'services' (Lambda). Seems a shame to ignore this wonderful workflow and configure webhooks instead which means we have to create a new integration API (with auth) to catch the hook requests, which then has to implement it's own queues and services. See what I mean? If you still think stand alone is the way to go, I'm all ears just wanted to offer a little more context and see if this changes anything. – Dan Sep 12 '18 at 2:24
  • 1
    Hmm, I see what you mean. I don't thinks it's particularly hacky to consume your own webhooks, but I guess in my opinion it comes down to whether you're looking to replicate or expose the functionality in the future - if not, the additional abstraction layer may not be worth it. – robinsax Sep 12 '18 at 4:02
  • You also need to consider which team is building what and how is this new functionality is going to be used in the future. – chchrist Sep 12 '18 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.