The plan so far has been that the backend (this app) manages challenges it pulls from a source such as git or a plain directory.
For a variety of reasons, it might be nicer to extract this logic to a different service:
backend focuses on managing games rather than reading, validating, updating challenges
external service can be used from other contexts:
we could use it to validate challenges submitted to our challenge repository
other projects that want to make use of open challenge repos could include it.
work on a separate challenge service can be easily parallelised with backend development
The new challenge microservice should essentially do the following:
Allow configuration of a "challenge source" - directory with challenges in them (future work: possibly allow multiple sources)
Upon start up, parse all available challenges and build an index for quick access, containing file names (or some other sort of ID), title, tags, difficulty.
Watch those directories for changes - when a new challenge is added, add it to the index, when a previous one is updated or deleted, update the index accordingly.
Provide at least the following endpoints:
validate challenge: Takes a challenge as input (including a solution file) and performs the following validation steps:
run json schema validation (schema is configurable)
validate language and license fields (not very important, can be skipped for now)
send the provided solution (if any) and the test case inputs to the code execution server and verify that the solution actually produces the expected results
send the test case and example inputs together with the inputFormat field (if present) to the templatespiler server for validation
get random challenge: pick a random challenge from the index and send the complete data over.
Additional endpoints that could be useful in the future, but aren't a priority:
get challenge index (paginated?): get an overview of the available challenges
get challenge by ID
search challenges by different criteria
give challenge feedback: server additionally maintains a persistent storage of feedback for each challenge, containing things like a quality rating, difficulty rating, general comments)
How to ID challenges is still somewhat of an open question when multiple sources are involved. I would just focus on a single-source implementation for now and use file names as IDs.
The new project should probably be AGPL-3.0-or-later, like this one.
The plan so far has been that the backend (this app) manages challenges it pulls from a source such as git or a plain directory. For a variety of reasons, it might be nicer to extract this logic to a different service:
The new challenge microservice should essentially do the following:
Additional endpoints that could be useful in the future, but aren't a priority:
How to ID challenges is still somewhat of an open question when multiple sources are involved. I would just focus on a single-source implementation for now and use file names as IDs.
The new project should probably be AGPL-3.0-or-later, like this one.