FEAT: rebuild legacy rank and store #45
Conversation
kynrai
commented
Jun 11, 2024
kynrai
commented
- Move legacy rank to checks
- Create stores and legacy rank in memory store
- Only initialise the data once, the first time the handler is called, not on each call
Codecov ReportAttention: Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
|
kynrai
force-pushed
the
feat/rebuild_legacy_rank_stores
branch
from
39dcefe to
0dd4ead
Compare
| var data map[string]int //map of domain to rank | ||
|
|
||
| func NewInMemoryStore() *InMemoryStore { | ||
| return &InMemoryStore{} |
There was a problem hiding this comment.
Why would we return the actual InMemoryStore, instead of a pointer to it? Or would that just be unnecessary here?
There was a problem hiding this comment.
Pointer was as i intended to originally to have the data inside the struct. but then moved it to a package with a global for the one off load, either would work here, the difference is negligible although strictly speaking non pointer would be a tiny bit faster
| type InMemoryStore struct{} | ||
|
|
||
| var once sync.Once | ||
| var data map[string]int //map of domain to rank |
There was a problem hiding this comment.
Could this be encapsulated in the InMemoryStore?
There was a problem hiding this comment.
This could but the once download would be per instance of memory store instead of once when the module is imported, the data would need to be at the handler level and as this is just a temporary solution, i didnt want to put it at handler level
| return rank, nil | ||
| } | ||
|
|
||
| func load() (map[string]int, error) { |
There was a problem hiding this comment.
This might be able to be split up a bit smaller
There was a problem hiding this comment.
yeah i dont like the the fact it needs to be loaded into memory first, difference of taking in a Reader and ReaderAt with the zip reader, its possible to stream a zip file. but not with the native APIs
| return rank, nil | ||
| } | ||
|
|
||
| func load() (map[string]int, error) { |
There was a problem hiding this comment.
And maybe around error handling too. As it's beeing logged but looks like it's not returned to the caller.
Maybe error handling is something i can think about at a more global level, I'm not sure how that typically works with Go, I'd need to look into it. In the JS world, I'd have a reusable error class/function, which is called whenever there's an error. So that error handling is consistent and observability/monitoring can just be implemented in one place.
There was a problem hiding this comment.
Erros in golang are handled when the happen not at global level.
Errors are always bubbled up. here errors are returned to the caller which in this case logs the error.
