Just to add some small touches via templating :)

I keep nitpicking NC because of my initial GeoJSON screw up during testing, but let's say someone lives on this street: https://www.google.com/maps/place/203+Kit+Creek+Rd,+Morrisville,+NC+27560/@35.8678067,-78.8545718,20z/data=!4m5!3m4!1s0x89acee315bff907f:0x35db388ef4dc738b!8m2!3d35.8678203!4d-78.8542112

Well using the Census Bureau API, we're f*cked because there's no good street normalizer out there and I'm not gonna try to budge. We're gonna use Mapbox instead... because I can't deal with this..........

I noticed that there were only 435 values when there are 441 districts. Turns out, the data does indeed include 441 districts, but all non-voting districts have geojson that has shapely say [None None None], and there are a few voting ones that are part of a voting district that fails to load completely (i.e. shapely doesn't even bother putting them into the Pandas series).

invalid_geojson_objs =  {'MP-0', 'WV-3', 'WY-0', 'GU-0', 'PR-0', 'WV-2', 'VI-0', 'WI-7', 'WV-1', 'DC-0', 'AS-0', 'WI-8'} # {set: 12}

# Ordered
['AS-0', 'DC-0', 'GU-0', 'MP-0', 'PR-0', 'VI-0', 'WI-7', 'WI-8', 'WV-1', 'WV-2', 'WV-3', 'WY-0']


nonvoting = [12, 87, 130, 231, 346, 417]  # {list: 6}

poor West Virginia. All invalid lol.

Anyway

the current server will pull a Jim Crow law and simply say the user is not in a valid district to vote. I'd much rather fix the GeoJSON somehow (never done this before, but how hard could it be? Plus GitHub renders these districts perfectly fine :P)

We should save each feature with a hash. For each district, we should save a hash so that, in the returned JSON, the user can validate if the current representative is the same as before. If not, then we should update. On app startup, this should be validated every single time. This also gives great traffic analytics into how often our app is opened and closed. Obviously, it can be pretty bad if some bot spam attacks it. Not looking forward to adding an IP throttle, but it will be done if necessary (in which case, the vote server already includes a caching functionality with Redis, so it's not difficult to implement either).

We can also use Cloudflare to protect ourselves from DOS attacks as an extra security measure if necessary. Hopefully, it's not necessary.

But the main point of this is for the user to know when they need to update. We can do that OR we can send a web hook to our server using a rotating key style SHA 512 hash saved on GitHub actions to hit our voting server to let users of district, state, and year blah to update by hitting the starlet server. I actually like that better. The voting Django backend can then let the user know on the next API request (regardless of path) to hit this starlet server.

Now, I don't particularly like the idea of "analytics" or "distributed internal throttling" (this excludes Cloudflare) since that ruins the integrity of privacy for our clients when it comes to exact location. On our backend server, we use django-ratelimit, but we only throttle based on user id, not on IP address (all our endpoints, except for our authorization endpoint obviously, require authorization. A better way of throttling would be to use the normalized user ID at our scale; in a larger scale, to catch a malicious actor trying to attack us via multiple actors, that's when Cloudflare or our internal throttling mechanism is necessary where django-ratelimit's user_or_ip turns into our own user_and_ip key).