...
These are changes to the existing EdgeX microservices or system at-large to address concerns of scalability, flexibility, reliability, maintainability, or otherwise improve the existing system that is otherwise considered inferior design, buggy or otherwise poor quality code. Technical debt may be thought of simply as "areas of the existing code base we need to fix".
- Improve/additional testing
- Scale testing
- Soak testing
- Platform/OS Testing
- Different configuration testing
- Automate generation of API documentation. The RAML that provides developers with an understanding of the microservice REST calls is maintained by hand. How can the generation and maintenance of the API documentation be more automated and therefore allow the documentation to be more reflective and consistent with the code base?
- Device Service SDK improvements (to levels of Java device service SDK)
- Device discovery & provisioning - allow a device service to provide its own implementation for dynamic and automatic device discover (example - discover any new BLE devices in proximity and automatically provision them in EdgeX)
- Cache fairly static information (device profiles, device information, etc.)
- Allow for easier device removal
- Create simple and complex virtual device services
- A simple virtual device service should simply push out "readings" as static or random numbers
- A complex virtual device service should be similar in the database driven approach supported by the current virtual device service in Java.
- Hide, abstract and/or remove database IDs from EdgeX REST APIs. Database IDs should not be used to identify anything (devices, services, profiles, etc.) in EdgeX directly.
- Educational Assistance
- Deeper documentation - especially around on-boarding
- Provide more example code (Device Services, Export Services, etc)
- Meetup support
- Hackathon kits/support