-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add catalog graph plugin #7185
Add catalog graph plugin #7185
Conversation
|
plugins/catalog-graph/package.json
Outdated
"@backstage/theme": "^0.2.10", | ||
"@material-ui/core": "^4.12.2", | ||
"@material-ui/icons": "^4.9.1", | ||
"@material-ui/lab": "4.0.0-alpha.47", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This version is different from what we use elsewhere. I had some trouble with the autocomplete that is resolved here. We could update to this version everywhere, I don't think that this bump included any breaking changes. On the other side we could just sit it out and wait for #7094 that includes the autocomplete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actual, the build seems to fail because my version is to new #7196
624893d
to
d979a1a
Compare
The ownedBy graphs showing in the video tell me that there's room for a future addition, that lets you toggle making relations into nodes too. Maybe with a different color. gets the fanout a bit under control and clarifies things when there are 8 relations of one type and three of another, etc |
Yeah, the idea is to have more rendering modes over time that everyone can choose how he want the display it. I already played around with toggling. The bad thing about it is that the graph can quite drastically change when you "open" a relation. That felt quite hard to use and keep track of the context then. The idea of grouping multiple entities into a single node is neat too 🤔 |
Ah but, even without the opening and closing. Even as a static thing, replacing arrows with arrow-node-arrow |
And I didn't mean to collapse entities actually, even though that sounds interesting :) I was just not gonna make a nicer ascii graph, I meant three arrows to B, C, D as three separate nodes :) |
Ah, yeah. Also played around with that idea. Can't show a screenshot (to much internal stuff on it), but I had two issues:
|
cd713b4
to
9cba3ea
Compare
Just wanted to stop in to say: well done, @Fox32 ! Beautiful rendering, and wonderful feature to drive up discoverability of the engineering output. This drives such value. Kudos!!! |
🎉 Amazing! Can't wait to try this out! |
I like this a lot, we have implemented something similar internally. I would love to give it a try in our backstage instance 👍 What has been very valuable for us is to also expose "metrics" out of the dependency graph to spot "non-standard component relationships", for example, suggesting to break down a component's responsibility into multiple sub-components when we detect If I can propose (yet another 😆) feature idea that we also have internally, is the capability to "simulate edition" of the graph. An engineer can then more easily sketch ideas of how the "system landscape" should be. At the end of the process, we allow them to exporting sketches to common graph description languages (like |
Love it! |
Also, can't wait to combine this with like symbology or similar to give status overviews at a glance. For example, looking at your local "neighborhood" of nodes and seeing that one of your dependencies has a big warning triangle on it because it isn't updating properly or has some kind of alert going |
Signed-off-by: Oliver Sand <oliver.sand@sda-se.com>
Signed-off-by: Oliver Sand <oliver.sand@sda-se.com>
9cba3ea
to
3742f41
Compare
Signed-off-by: Oliver Sand <oliver.sand@sda-se.com>
c0e509f
to
aec9385
Compare
CI is green now 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NICE!
RELATION_DEPENDS_ON, | ||
RELATION_DEPENDENCY_OF, | ||
], | ||
}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to have a defaults mechanism (kinda like the EntityTable
columns or something like that)? This is a bit much to have to slap into the example app :) So if you don't give a selectedKinds
it'll be CatalogGraphPage.defaultSelectedKinds
or so
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it's a bit complicated here. Not providing selectedKinds means "all selected kind" or "no kinds filter". So I can't set a default for undefined
(same for relations). On the other hand, setting these is just a matter of taste, we could also go with "no filter" in the example app and readme.
<EntityAboutCard variant="gridItem" /> | ||
</Grid> | ||
|
||
<Grid item md={6} xs={12}> | ||
<EntityCatalogGraphCard variant="gridItem" maxHeight={400} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i saw some vertical jumping in the demo video; i still think these might be best to have with a fixed height, and possibly below the fold (under some other stuff) so it can load in peace and maybe even does its first render out of sight. That way it has a bit more vertical and horizontal space to play with too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, fixed height is better. About the jumping inside the diagram: I wonder if that is something we can fix in the dependency graph. There is a debounce that where the timeout could be reduced to make it more responsive. But maybe we have to switch to another library under the hood anyway, as dagre seems to be kind of dead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fox32 do we have an issue for the switch?
plugins/catalog-graph/api-report.md
Outdated
kinds, | ||
relations, | ||
direction, | ||
maxHeight, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it worth having something like cardStyles
or whatnot, that has the proper css type or similar? Or even, taking it farther, essentially cardProps: InfoCardProps
? This is one of those components that's such a thin wrapper, and immediately somebody comes along and asks "what if i want to change the title of the card". So, not to rant too much, but sometimes I'm not sure what the right "abstraction level" is when we make components, and perhaps especially so for cards
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think a lot of people might want to customize the card. For now I hoped making the card a very tiny wrapper would be sufficient and people can just copy it. On the other hand, where do you stop. Would it be better to just pass all card properties through? What about the ones that I modify in my card, like deepLink
or noPadding
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's a complicated subject. I hope we'll get the time soon to work on clarifying the app-plugin contract so to speak
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I worked with mui 5 lately for another project, maybe they have some patterns we can take over. Like having the xs
property on all components.
plugins/catalog-graph/src/components/CatalogGraphPage/useCatalogGraphPage.test.ts
Outdated
Show resolved
Hide resolved
/** | ||
* Optional kind of the entity. | ||
*/ | ||
kind?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would type?: string
fit well in here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
especially if that together with kind could be used to draw custom icons in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not used right now, but yeah, could be added later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also pass the full entity in and make the nodes more customizable. But that is maybe also something for later.
plugins/catalog-graph/src/components/EntityRelationsGraph/useEntityStore.ts
Outdated
Show resolved
Hide resolved
plugins/catalog-graph/src/components/EntityRelationsGraph/useEntityStore.ts
Outdated
Show resolved
Hide resolved
a8ab0d3
to
ae0446c
Compare
Signed-off-by: Oliver Sand <oliver.sand@sda-se.com>
ae0446c
to
0758089
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's ship this!
Welcome to the catalog graph plugin! The catalog graph visualizes the relations
between entities, like ownership, grouping or API relationships.
The plugin comes with these features:
EntityCatalogGraphCard
:A card that displays the directly related entities to the current entity.
This card is for use on the entity page.
The card can be customized, for example filtering for specific relations.
CatalogGraphPage
:A standalone page that can be added to your application providing a viewer for your entities and their relations.
The viewer can be used to navigate through the entities and filter for specific relations.
You can access it from the
EntityCatalogGraphCard
.EntityRelationsGraph
:A react component that can be used to build own customized entity relation graphs.
It's similar to the system diagram and requests like #1204 and is based on suggestions from here.
Quick Demo
Entity Card:
CatalogGraphCard.mov
Standalone Viewer:
CatalogGraphStandaloneViewerV2.mov
✔️ Checklist
Signed-off-by
line in the message. (more info)