Storage paradigm: plugin store vs proper db types

[kalnode]

NOTE: This is basically a discussion, however it's posted here as an issue for better visibility.

This post is just a reminder to re-scrutinize the plugin's storage paradigm specifically for indexes and mappings definitions.

Note: The plugins' tasks (indexing tasks pending) and logs (indexing tasks completed) are defined as actual Strapi types and have their own db tables. These types may easily get 100's of records, have need to use regular DB behaviours as well an end-user may want to actually see these exposed in other areas of the Strapi dashboard (outside of the plugin), ie the "Content Manager".

Paradigm 1: Plugin store

Currently plugin data for indexes and mappings is stored in the plugin store (alongside general plugin settings).

The plugin store is initialized & cached on Strapi boot, and

Advantages

• Simple JSON object
• Agnostic across Strapi versions
• Performance advantage as a cached object is made on Strapi boot; so actions during operation use the DB less, in theory
• Most end-use cases will involve minimal amount of records (for indexes and mappings), and not much need for database interaction beyond the features of the UI

Disadvantages

• No inherent type protections
• No inherent query api

Paradigm 2: Proper database types

Proper Strapi data types for: Index and Mapping

Note: Earlier in dev, this was implemented.

Advantages

• Inherent type protections
• Inherent query api
• May be useful if we expand scope... e.g. support multiple technologies
• May be useful for end-use cases involving 100-10000s of records?

Disadvantages

• Less performance: DB is hit more often
• Overengineered
• Risk of breaking changes across Strapi versions
• Extraneous db tables