Replies: 1 comment 4 replies
-
I still prefer Option 2 because it's easier for myself to understand the similarities and differences. But that's my opinion that I won't impose on folks. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is a follow-up thread for https://github.com/lyft/cartography/pull/1219/files/4accca82017477d772aa2a65cddb62869931eb6d#r1309246010.
We're refactoring the AWS NetworkInterfaces to use the cartography data model and are needing to handle an interesting case. A NetworkInterface node's properties can come from multiple sources:
Each of these AWS API calls contains different properties that we would like to unify in a single NetworkInterface node. To represent this using the cartography data model, we create a subclass of CartographyNodeSchema for each potential data source. For example:
EC2NetworkInterfaceSchema
represents a network interface as known by thedescribe-network-interfaces
API. This class API call includes fields not returned by any other API call such aspublic_ip
andrequester_id
.EC2NetworkInterfaceInstanceSchema
represents a network interface as known by thedescribe-instances
API.The end result is that after the cartography network interface and EC2 instance sync jobs run, the resulting graph will have NetworkInterface nodes with properties that are merged from all above sources. This works as long as the
id
fields match up.We've identified 2 ways to represent
CartographyNodeProperties
classes to handle this:EC2NetworkInterfaceNodeProperties
andEC2NetworkInterfaceInstanceNodeProperties
class:I prefer option 1 because it is more explicit even though there is duplication. I don't think we should create sub-sub-classes of items in https://github.com/lyft/cartography/tree/master/cartography/models/core, and I think we should prefer composition over inheritance.
It will get complicated to handle cases using a class hierarchy where a NetworkInterface's "secondary API" like
describe-instances
includes more fields than its "primary API" (describe-network-interfaces
), and vice versa.Here's how I think of it: a
CartographyNodeSchema
object is composed of several other objects including aNodeProperties
object. I don't want to need to think about any hierarchy or nesting structure beyond this.Beta Was this translation helpful? Give feedback.
All reactions