Concepts: How to handle external dependencies?

Steffen Opel [Utoolity]

Component dependencies are a core concept of distributed architectures, and I really like how Compass natively supports component dependencies so that other features can be build atop the resulting dependency graph (e.g. announcements, as further discussed in Notifications for announcements).

I'm struggling a bit how to model external dependencies though, i.e. those that are not the engineering output of your own teams?

As an example, we (Utoolity) are building AWS integrations for the Atlassian platform, which requires us to closely track the API/SPI/SDK evolution of two major platforms, besides all the usual software dependencies on external libraries for an app's business logic etc.:

1. Now, in theory all those dependencies might still boil down to some kind of software artifact that could be tracked via a repository and Compass component in turn (e.g. the various AWS SDKs, the Atlassian OpenAPI and GraphQL types, the npm packages).
2. However, in practice that's rarely manageable and developers rely on community announcements, release notes, and changelogs instead, i.e. an ever changing information stream of varying granularity.

So while 2 strongly suggests that each team needs to curate their tailored stream of changes anyway, I'm finding myself right in the middle between the Compass dependencies and announcements capabilities and am curious about your thoughts in this regard?

Andrew Freedman

G'day Steffen,

This is a topic we're very interested in — we'd love to chat with you about how Compass can make it simple for you to work with external dependencies. Dave & Josh tell me they've had a chance to catch up with you previously, we'd love to discuss this topic over Zoom as well.

In short, we agree! Dependencies exist outside the edge of your organisation and they can be every bit as impactful on your components as the things you’ve built in-house.

One of our first candidates for helping with this problem is the concept of external libraries. It’s early thinking, but we suspect this will mean linking up to key library archives (as you suggest, npm — or PyPI, GitHub, etc) and creating a subscription which powers a library component in your local Compass. This would then be able to sit in your dependency graph and relay notifications, component attribute information and likely more.

We also think that Statuspage has an important role to play here. It already has the concept of "third-party components" which could form the foundation for a structured interface and has wide market penetration. We have plans for Statuspage integration and this would allow your upstream vendors to push Announcements/Events/attributes/metrics.

All of this is tentative though — being able to hear from our customers, such as yourself, is going to have a significant effect on how our thoughts turn into plans and eventually features so please, keep the feedback coming! We're also looking for ecosystem partners who can help us infill connections — something like Compass <-> npm could be an interesting opportunity.

— Andrew