## TLDR

For the past two weeks I worked on a big refactoring, to be able to support newer fork upgrades. I abstracted away the Header structs which are different in each fork, so that the other structs like Update or Bootstrap can stay the same, and not have to have a struct for each version.

I also continued working on Selene, the dart light client package and was not able to submit it for the hackathon in time.

## Recap of last week
In week 11 I finished up the work for the lc updates database, and started to work on the`GetLightClientUpdatesByRange` to have it use the db.

## What happened this week
During weeks 12 and 13, I saw the need to pause the work on the API and start working on refactoring the lc data structures.
The problem was that, I saw that we were moving in the direction to have each of the structs for each version. which would have resulted in A LOT of structs. which might not be so bad, but I thought that we might be able to do this in a better and cleaner way.
So I tried to abstract away the changes in the forks to the least difference in the structs as I could. Since the difference was only in the `LightClientHeader` structs, I created a `LightClientHeaderContainer` interface which could contain any Headers that implements it. That way, we only have to add a new header struct for each fork, and all the structs like `LightClientBootstrap` or `LightClientUpdate` or others could stay the same and just use a `LightClientHeaderContainer` as their fields.
After that I refactored all the usages of those structs to use the new structure.

Also for the API struct, the decision was to use `Json.RawMessage` for the header field types, so that we can put any of the headers in them.
I personally believe that defining an interface like we did for the main structs would have been better, since it makes it syntactically clear that what types can be passed to the fields, but since the `json.RawMessage` pattern was used before in the API structs, Radek suggested that we should keep using the same pattern and not solve a problem using different solutions in different places to keep the code coherent.

The [PR](https://github.com/prysmaticlabs/prysm/pull/14376) got merged this week.

I also minimally worked on Selene, since most of my time was spent on the refactor.

## What's next

Now, I will get back to fixing the`GetLightClientUpdatesByRange` API, so that it reads from the DB.
But before that I'm going to [make sure](https://github.com/prysmaticlabs/prysm/pull/14432) that the DB works with all the different forks, and writing more precise tests for it.
I also found several oversights in the tests written for the already implemented functions that I think would possibly cause bugs. So I will also try to improve the test coverage for the light client functions.

## Other notes