¿How to structure Hasura’s data model post the transition to Ceramic?

[dysbulic]

I am in the process of converting MyMeta from being backed by Postgres by way of Hasura to being data backed by Ceramic with Hasura acting as a cache.

The IDX basicProfile is currently retrieved by Ceramic on profile page load (stale while revalidating) or every four days at least. It is stored in player.profile_cache.* as:

• backgroundImageURL
• countryCode
• description
• emoji
• gender
• imageURL
• lastCheckedAt
• location
• name
• website

I'm in the process of adding an additional schema to hold some additional profile fields. They will be stored in a new type of Tile conforming to an extendedProfle (schema). The basicProfile is actually open-ended and new fields can be added to the basicProfile stream, but since performance degrades in proportion to the number of writes to the stream, a separate stream for the extended fields will be more performant. The question is how should they be stored in the cache.

To start out with, the fields being stored are:

• username: name in the basicProfile allows the storage of an arbitrarily spaced, capitalized, and punctuated text-based identifier for someone. username is primarily for use in interfaces, either as something short to type, or as part of a URL.
• pageBackgroundURL: basicProfile stores a profile image and a header banner (recommended 3:1 image ratio). This is an image to be used as the background image for the page.
• pronouns: A users preferred way of designating themselves pronominally. Generally specified as the singlular and possessive forms separated by a slash. I.e. "he / his" or "they / their".
• magicDisposition: Magic: The Gathering uses a five color character alignment matrix. Players may have any, all, or none of the five colors: white, blue, black, red, and green. Each color represents a valuation of certain priorities over others.
  
  The string is simply the first letter of each present color in the player except for blue which uses a “U” to avoid conflicting with black.
• availableHours: The number of hours the user is avaiable each week for work projects.
• playerType: A descriptor that signifies in which aspect of the development process, from initial exploration to final maintenance, the user is most comfortable.
• skills: Skills will refer to a separate stream which will store an array of skill / category objects. Users will be able to create arbitrary skills and order them according to preference.

So, I have three primary options for how to store the extended profile:

1. Remove the profile_cache portion of the schema and list all cached properties off of the root: player.name, player.username, player.description, etc.
2. Rename profile_cache to basic_profile and store the extended profile in a corresponding extended_profile: player.basic_profile.name, player.extended_profile.username, etc.
3. Use profile_cache for the storage of both types of profiles: player.profile.name, player,profile.username, etc.

I'm pretty sure I either want #​1 or #​3. #​1 seems cleaner code-wise, but runs the risk of overcrowding the namespace. #​3 keeps all of the information cached from Ceramic in one table and joins it to the player table. I think that's the way I want to go.

¿Anyone have any feedback on the fields I'm saving or the mechanisms for persistence?