- n/a
- We think that we don't have a good defaults catalog, requiring a lot of configuration. Our core value is to be able to enable features without any additional configuration.
- We don't know what directory structure this should be.
- Build required some metadata field that was not clearly explained in documentation.
- Even when build has errors, the build status shows as green.
- The relations were tricky even when we copied config from documentation:
- Webview was down almost for the whole training session.
- Relations with domains are not displayed on main table even when configured correctly.
- We don't see what service depends on what on this screen (which is most important). We believe we should at least display some arrows or numbers from 0 to ♾️.
Relations Complexity: The relations are too complicated for us. We don't really know how this could be configured. In this case, having options adds unnecessary overthinking.
Automatic Recognition Proposal: What we found is that one entity type has only one possible relation type with another entity type, so the catalog should automatically recognize it:
user → team(this will always be "member of")service → team(this will always be "ownership")
Concerns About Current Approach: Going deeper in this way, I think we unnecessarily assume how entities will be used by our clients. We have types like services, users, domains, etc., but customers may want to have:
- Offices
- Departments
- Countries
- Whatever works for their domain
Alternative Vision: What I saw in previous training when we discover catalogs is that the idea of having entities is that entities can be whatever you want. For me, it would be easier to configure what an entity is instead of lerning and adding it to some predefined type.
Proposed Solution: Similar to how tasks on Slack work - you can extend entities by adding properties to them like email time comments numbers etc . If we want to have validation, we can allow users to write schemas and validation rules for their own use.
Benefits: This way we will give tools that our customers can use as they want, instead of asking us to: Extend types and add exceptions just for them if they have unusual domain
Development Impact: I also think that thinking of entities as generic objects could save development time as well.