Skip to main content

Middleware

We use middleware whenever we need to connect two systems together (e.g. ecommerce platform and ERP), expose a private API for public use or extend the functionality of a SaaS service.

When choosing what middleware to use for a project, it’s important to ask the following questions:

  • Can the functionality be provided by an app or off the shelf connector instead?
  • Who in the team knows how to use this technology? Will we need to organise training for it?
  • How does this technology fit into our processes and procedures? How do we QA the work we do with this platform?
  • How will be monitor the solutions built with this technology? How do we know when something breaks? How do we fix it?

Our preferred approach for implementing middleware on our projects is using serverless services on Google Cloud. We use the internally developed Cloud Seed tool to provision middleware applications based on Cloud Functions, with built in support for all of the common integration patterns that we use on our projects, including webhooks, scheduled tasks, file drops and direct API requests.

Overview of our GCP middleware infrastructure

Cloud Seed seamlessly integrates into our development workflows, allowing us to:

  1. Implement middleware functionality using Typescript.
  2. Use a fully featured programming language for complex workflows.
  3. Version control our middleware code using Git and BitBucket.
  4. Peer review our middleware solutions through pull requests.
  5. Deploy middleware using Bitbucket Pipelines.

Using Other Solutions​

While we should try to use our recommended solution whenever we can, to create consistency across projects and enable knowledge sharing between teams, there are some situations when we might choose to use an alternative solution.

Alternative solutions should normally be limited to the following situations:

  1. The customer’s technology strategy includes a strong preference for another solution, and the customer will own and support the solution themselves after launch.

  2. The customer has contracted another integration partner to build and support the solution, and we will only be providing consultancy during development.

In all situations, when considering alternative middleware solutions we should refer back to the important questions outlined above. Any unknowns or risks should be appropriately documented and reflected in the project budget.