Ask AI: How to convert data operations to unstorage adaptation?

Ask AI: How about converting data manipulation to unstorage adaptation?

Background#

I am a programmer. I have come up with an idea. There is a library called unjs/unstorage on GitHub, which encapsulates data operations into hasItem, getItem, setItem, and removeItem by integrating different driver adapters. It maps the concept of front-end localStorage.

I am thinking that this approach is quite good for adapting front-end data manipulation scenarios. It is not difficult technically and can easily achieve results, simplifying the learning cost. For example, if I have a WordPress API, I can use unstorage-wp-site to update website information without learning the specific usage. If I want to reply to comments, I can use unstorage-wp-comments.setItem. Similarly, using the encapsulation approach of get/post/put/delete, we can reuse existing concepts. What do you think?

Conversation with AI#

Claude3Opus replied as follows:

This is a great idea! Abstracting different data operations into a common interface similar to localStorage can greatly simplify the learning and usage costs for developers. I have some thoughts and suggestions on your approach for your reference:

The interface design should be as simple and understandable as possible, close to the developers' existing knowledge concepts. The methods you mentioned, such as get/set/remove/has, are good, and their purposes can be understood just by their names.

Consider asynchronous operations. Many storage calls are asynchronous and need to return a Promise. You can refer to the asynchronous interface design of IndexedDB.

Error handling is crucial. Interface calls should handle and propagate errors gracefully, providing clear error messages and codes.

Version management and data migration. If there are changes in the storage schema, consider compatibility between old and new versions and data migration.

Flexibility and configurability. Provide good configurability so that users can customize behaviors, such as custom key prefixes, data expiration, and caching strategies.

Excellent documentation. Write clear and comprehensive documentation and usage examples to reduce the learning curve for developers.

Unit testing. Write comprehensive unit tests for each storage adapter to ensure stability.

TypeScript support. If the project is written in TypeScript, consider providing complete type declaration files.

Someone objected, saying, "It seems more troublesome. unstorage-wp-xxx.setItem, this xxx is a learning cost. It just shifts the cost from one place to another. It adds another layer and makes the system more complex [旺柴]."

Claude3Opus replied as follows:

This objection raises a good point. Introducing the intermediate layer of unstorage does indeed shift the learning cost from the underlying API to the unstorage adapter layer to some extent. Developers need to understand the concepts and usage of unstorage and each adapter. This undoubtedly increases the learning burden and system complexity to some extent.

However, I believe that in the long run, the unstorage solution still has value, mainly for the following reasons:

Unified interface. Different storage solutions have their own interfaces and usages. By providing a unified interface through unstorage, the learning cost for developers to switch between different storage solutions can be reduced.

Encapsulation of complexity. Some storage solutions have complex interfaces with many parameters. Unstorage can encapsulate this complexity and provide simpler and easier-to-use interfaces.

Can precipitate common modules at the business level. Business-level adapter modules such as unstorage-wp-site and unstorage-wp-comments can be precipitated as the infrastructure of the project and reused in multiple functional modules.

Facilitates unified error handling, monitoring, and other infrastructure. With a unified interface, error handling, log monitoring, etc., can be unified at the unstorage layer.

Better testability. Through the unstorage adapter layer, storage interfaces can be easily mocked for unit testing.

I think that if there are multiple driver adapters, it can further form an ecosystem and a plugin market. However, this may bring new problems. Different SDKs may have different ideas, which may result in inconsistent APIs. Please continue to challenge me as the opposing party and raise your objections.

Okay, I will continue to play the role of the opposing party and raise questions and challenges to your ideas:

Inconsistency in APIs. As you mentioned, different SDKs may have different ideas, which may result in different API design styles. For example, some SDKs may prefer to use get/set/remove, while others may prefer read/write/delete, with different parameter names and types. This may require developers to frequently consult the documentation when using different unstorage adapters, increasing development costs.

Uneven quality. The open ecosystem and plugin market mean that anyone can contribute unstorage adapters. However, the code quality, completeness of documentation, and responsiveness of maintenance from different contributors are unknown. This may make it difficult for developers to evaluate and receive support when integrating and encountering issues.

Version compatibility. If there are changes in the core unstorage interface, some adapters may not be compatible with the new version. Developers may need to wait for the adapter authors to update or modify the adapter code themselves. This dependency relationship may affect project progress.

Risk of excessive abstraction. Some storage solutions may already provide good interfaces. Adding an additional layer of abstraction through unstorage may be excessive and increase complexity and performance overhead.

Learning cost. Although unstorage provides a unified interface, developers still need to understand the specific storage solutions corresponding to each adapter. For example, the usage scenarios of unstorage-redis and unstorage-fs are different. Developers need to understand these differences to make the right choices. This learning cost is inevitable.

Fragmentation of the ecosystem. Different projects and teams may choose different unstorage adapters. This may lead to fragmentation of the community ecosystem and make it difficult to reuse code between different projects. It may be better to directly use native storage solutions for collaboration between different projects.

Performance issues. Unstorage as an intermediate layer may introduce some performance overhead. Especially in high-concurrency and large-scale data scenarios, this overhead may become a bottleneck of the system.

Not conducive to learning underlying knowledge. Over-reliance on the abstraction of unstorage may cause developers to overlook the principles and best practices of underlying storage solutions, which is not conducive to developers' growth.

Of course, these are just possible issues and do not mean that unstorage is necessarily a bad choice. However, when deciding whether to introduce unstorage, you need to carefully evaluate these potential risks and challenges, weigh the pros and cons, and choose the solution that best suits your project.

Then I throw my statement to GPT4.

GPT4 replied as follows:

From the perspective of the opposing party, I can raise the following potential concerns and objections:

1. Transfer of learning costs rather than reduction
   Although encapsulating operations through unjs/unstorage can simplify the usage of APIs, this simplification may be superficial. Users still need to learn how to use the unstorage library and its drivers correctly. If a project requires multiple different data sources, users may need to understand the different APIs and concepts of multiple drivers. This may result in the transfer of learning costs from one place to another rather than a true reduction.

2. Consistency and predictability issues
   If there are multiple drivers, maintaining consistency in API style and behavior will be a challenge. Different developers may have different implementation approaches, which may result in inconsistent behavior of APIs between different drivers, increasing the difficulty of understanding and debugging.

3. Performance and complexity
   Adding an additional abstraction layer may introduce performance overhead. Each layer of encapsulation may introduce delays and resource consumption. In addition, system complexity may increase, and when problems occur, debugging and resolving them may become more difficult due to the additional abstraction layer.

4. Quality and security of drivers
   Relying on community-driven plugins and adapters means that the quality and security of the project may be affected. Not all developers will follow best practices, and insufficient auditing and testing may lead to security issues and defects.

5. Version compatibility and upgrade issues
   Maintaining version compatibility among multiple drivers over time can become complex. If there are changes in the underlying API, all adapters need to be updated, and users may face frequent upgrade and migration issues.

6. Lock-in effect
   If "unstorage" and its adapters become popular, users may become overly dependent on this ecosystem, leading to technological lock-in. Once there is a need to change the technology stack or a better solution emerges, migration may become difficult.

In response, the solutions you proposed from different perspectives can indeed alleviate these issues. Quality control, version compatibility strategies, and positive interactions with upstream are indeed key to ensuring long-term success of the project. However, it is crucial to ensure that the participation and contributions of the developer community are conducted in a high-standard and transparent environment to maintain the health of the entire ecosystem.

Conclusion#

I believe it is feasible. When multiple libraries are put together to form a scale effect, it will have a greater impact.

For me personally, transitioning from an ordinary user to a power user, a potential maintainer, and a raiser of edge issues has contributed to my technical growth.