The developer community is actively discussing eserde, a new Rust library that promises to improve API development by reporting multiple deserialization errors simultaneously. While this approach offers clear benefits for API consumers, the discussions reveal both enthusiasm and practical concerns about its implementation.
Performance Trade-offs in Error Handling
The community has highlighted a significant technical consideration in eserde's approach. When encountering errors, the library performs two passes over the input data - first using serde_json's deserializer, then its own if an error occurs. While the happy path remains as fast as traditional serde_json implementation, error cases will take at least twice as long to process. This design choice prioritizes compatibility and reliability over raw performance in error scenarios.
Key Considerations for eserde:
- Double-pass deserialization on error cases
- Compatible with existing serde_json implementation
- Higher compilation times (approximately 2x more generated code)
- Limited support for custom error formatting
- No support for deserialization from non-replayable readers
Real-world API Development Challenges
Developers have shared compelling use cases where multiple error reporting could significantly improve the development experience. One particularly striking example comes from the community:
I once worked on a project where the BE dev had a fundamental issue understanding types, such that a json array would change its type when empty, e.g. from an array to an empty object.
Such real-world scenarios demonstrate why having comprehensive error feedback could save considerable development time and frustration.
Integration and Implementation Concerns
The community has raised several practical concerns about eserde's implementation. A notable limitation involves error formatting capabilities. Some developers point out that while libraries like serde_json and toml provide detailed error information for custom formatting (similar to rustc's output), eserde currently simplifies this by converting errors to strings, potentially limiting flexibility in error handling and presentation.
The Optional Fields Debate
An interesting discussion has emerged around handling partial deserialization results. While some developers advocate for returning partial results alongside errors, others emphasize the importance of maintaining strict type safety. The community points out that existing serde features, such as optional fields and default values, already provide mechanisms for handling missing or partial data when appropriate.
Future Implications
Despite some limitations, the community generally views eserde as a promising development for API design. The library's approach to comprehensive error reporting could significantly reduce the back-and-forth typically required when debugging API payloads, though developers should carefully consider the performance implications and use cases before adoption.
Reference: eserde: Don't stop at the first deserialization error.