Refactor repo to do validation in a separate backend provider

[C-Loftus]

As this application grows and we get more users it might make sense to switch the validation to a separate backend service instead of doing it in the frontend. That way it is modular and we can call it more easily from other services as an API. The frontend also limits our ability to check CSVs. If the target server does not provide the proper CORS headers, the request can fail even if the URL is valid and has valid data.

This service is probably done best in express, go chi, FastAPI, or Django depending on how much functionality we want and the long term goals of the service.

[C-Loftus]

Thinking about different ideas for backend providers. Think it might make iteration on the frontend a bit quicker once the CSV validation is extracted to a separate service for better separation of concerns

• Express (or another flask-like TS backend framework) -> easiest to transfer existing code and we can instantly reuse all the CSV tests and TS types between frontend/backend; TS type system is nice

• golang (chi) -> more work porting our existing code; fastest and best for CPU bound concurrency. Would integrate nicely with gleaner / nabu if we need to call other golang code

• FastAPI -> quick to set up, have to port some code, have nice helpers for openapi generation, but probably best to avoid dynamic backend languages like Python

• Django -> same as above, but nice helpers for auth / ORM. Clear patterns for growing a bigger codebase.

Not opposed to other frameworks but seems like these are the best options for our team's skillset / technical goals.

[C-Loftus]

@webb-ben do you have any preferences/opinions on this? Once again this discussion might not be relevant for a bit later but I feel like it would be good to align on things and what you prefer

[webb-ben]

golang (chi) -> more work porting our existing code; fastest and best for CPU bound concurrency. Would integrate nicely with gleaner / nabu if we need to call other golang code

Could be interesting if we plan on building more tooling around the current offerings of gleaner/nabu services