aadamz5 / hddmond Goto Github PK

The old stack used a separate NodeJS application for the GraphQL API. This was because I was learning how to do GraphQL and followed a tutorial that stepped through making a common GraphQL database shim.

Now with more advanced knowledge, the GraphQL API endpoint should be integrated into the app itself. This way separate stacks don't have to be deployed alongside this backend, regardless of the simplicity of the backend. Additionally, we can then unify the web-app's data transmission relying only on GraphQL in the far future.

• Research GraphQL python libraries (strawberry looks great!)
• Backend refactor
• Class layout
• GraphQL server in python backend
• Use GraphQL for real-time updates
• Abolish legacy websocket endpoint

Proper unit testing should be done, automated with GitHub actions to ensure the reliability and repeatability of the application.

• Research application test-suites
• Develop HDD testing interface
• Create suite of tests

The remote HDD function is currently unstable, largely do to the low-level nature and my lazy implementation of TCP/IP sockets. After the switch to asyncio (see #2), this should be rewritten using the websockets module.

The code needs better comments!

This backend currently uses a handful of threads to do the multiple concurrent operations it does. More efficiency can be had out of switching to an async style application.

With asyncio's ability to still execute legacy code or blocking calls as asynchronous, there is great reason to put forth effort and rewrite major parts of the code.

Additionally, with a better async-centric application, the implementation of "Remote HDDs" can be better incorperated.

• Convert all API calls in ListModel to async
• Convert Application functions to async
• Implement async signal handlers
• Safe-gaurd all possible child-thread callback routes into main-thread

The current data-service is heavily tailored to Apache's CouchDB with no real generic implementation. The database service should be database-agnostic with the ability to allow users to chose which database to use, simplifying docker setups.

Implementing this should give insight into what databases are widely used, and additionally, what databases are small and portable, in the case of a minimal setup.

• Define generic database interface
• Implement CouchDB interface implementation
• Implement TestDB / MemoryDB interface implementation
• Research other databases to initially support
• Implement configuration options for different databases, with a proper schema-file

The application initially had provisions for applying images to HDDs. This functionality was furloughed because of complexities with the current implementation. Currently, the ImageTask uses clonezilla commands to run the functionality. Unfortunately, clonezilla is not fully reliable as a scriptable utility.

• Research image cloning methods
• Revamp image-collection and parsing methods
• Implement basic Image application task

The current primitive implementation of logging using print is easily unsuitable in todays advanced architecture of containerization. Support for proper file, stdout, and network logging must be done.

• Research common logging mechanics
• stdout logging
• File logging
• Network logging - Not necessary for primary implementation.