Criteria for cartography 1.0.0

[achantavy]

1.0.0 is when a software project thinks of itself as stable and mature. I want to use this discussion thread to gather these ideas.

There are 2 things on my wishlist for cartography 1.0.0:

All modules refactored to the data model

I've wanted this for a long time. The data model makes module authoring less error prone so we should finish refactoring the whole project to use it.

There are some cases where we do need to write a raw Neo4j query instead of using the data model (kind of like using inline assembly instead of C for very specialized situations), but we should try to minimize those as much as possible.

This is a prerequisite for being able to support database backends other than Neo4j if we ever want to do that.

Versioned schemas

This is an idea from @kunaals.
Each node schema and rel schema should have a schema_version field. When a node or relationship's properties are updated over time, the module author will update the schema_version field. This way, programs that query the graph will have guarantees about what version of the data they have to work with as the schema evolves over time.

This field could be managed using semantic versioning. Automated tools that pull data from the graph will be able to say things like "we only support schema_version 3.x.y of an EC2Instance". A breaking change would be something like removing a field from a data type.

Perhaps the database layer is not the right place to put versioning logic. Rather, an API on top of the database (protobuf or otherwise) might be a more appropriate place. I'm concerned about overengineering things at the wrong layer of abstraction, but I do think this idea is still worth considering.

---

Please share your own thoughts too.

[chandanchowdhury]

Automated build and release

• Development builds are automatically released for each PR merged into main branch.
• For production/stable versions, maintainers create a Git tag using semantic versioning, automation takes care of the rest of the steps of build and release.

SBOM

• Use Pipfile or similar framework to declare packages we depend on.
• Helps with automatic SBOM generation which in turns find any package vulnerabilities we should know about and fix.

Related to: #1016

Configuration file

• Makes it easier to deploy in production.
• Configuration file with sensitive information can be stored in docker secret.

Related to: #1072

Logging config

• Ability to provide a logging config file to control the verbosity and destination of logs

Related to: #1213