You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had an thought about how claircore's data moves around in a program: the results of functions like (*Libindex).IndexReport and (*Libvuln).Scan return types that could be seen variously as large documents or small databases.
So, what if we treated them as databases?
There's already some of this style of handling being done with the current "document" approach, but what if we pushed this further and returned unserializable types that delayed reading from the database as long as possible?
I think some notable benefits emerge:
Memory reduction (in theory)
Currently the core types are pointer-heavy and "complete."
For example, there's no way to ask a question like, "is package X present?" without loading all packages, repositories, environments, etc. into memory first.
The current types also make the memory allocated harder for the GC to handle.
Externalization of serialization
By no longer returning a record type with members, we have greater leeway to make changes to claircore internals and the claircore interfaces.
Our internal domain types and return types wouldn't have to be 1-to-1 any more.
Callers would have to take a more active role in any serialization they wish to do, as the return type would not be able to just get passed to json.Marshal, for example.
Should the return type be an interface that the underlying database driver implements? Or should there be a concrete type returned, with some sort of interface into the database driver?
Where should the concrete types live? In the libindex/libvuln package, or in a driver-ish package?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I had an thought about how claircore's data moves around in a program: the results of functions like
(*Libindex).IndexReport
and(*Libvuln).Scan
return types that could be seen variously as large documents or small databases.So, what if we treated them as databases?
There's already some of this style of handling being done with the current "document" approach, but what if we pushed this further and returned unserializable types that delayed reading from the database as long as possible?
I think some notable benefits emerge:
Currently the core types are pointer-heavy and "complete."
For example, there's no way to ask a question like, "is package X present?" without loading all packages, repositories, environments, etc. into memory first.
The current types also make the memory allocated harder for the GC to handle.
By no longer returning a record type with members, we have greater leeway to make changes to claircore internals and the claircore interfaces.
Our internal domain types and return types wouldn't have to be 1-to-1 any more.
Callers would have to take a more active role in any serialization they wish to do, as the return type would not be able to just get passed to
json.Marshal
, for example.I wrote a little bit of Go to play with the idea:
Some additional design considerations:
libindex
/libvuln
package, or in adriver
-ish package?Beta Was this translation helpful? Give feedback.
All reactions