[contnr] A Case For A Single (universal) Data Type

Established approach to app development in bubble.io is to define custom data structures like data types, fields, field types, etc., followed by custom UI and custom workflows… Needless to say, all of these custom implementations ought to be custom maintained, over time.

There is an alternative. It starts with a single “universal data type” like.
contnr structure

We call this type of structure contnr, pronounced “container”. “Topic” is just a common placeholder for user data.

Asside from bubble.io’s default field types, contnr’s specific field types are:

  1. label - In the most straightforward contnr implementation (and there are certainly others), label can be related to “field name”.
  2. content - Actual field content. Type and be any bubble.io existing field type processed in their native format, but persisted as text.
  3. property - Any list of key/value pairs further describing either contnr’s or content’s desired behaviour. Most common property is key as “content type” with value as “text”, “text list”, “number”…
  4. feature - A list of pointers to other contnrs holding further detail. For example, if a particular container is correspondent to bubble.io data type, than its features would correspond to fields with their own types and any additional detail.
  5. context - A list of pointers to other contnrs indicating all contexts in which a particular contnr is a feature. In most cases if contnr B is a feature of contnr A, than A is the context of B.

In bubble.io implementation, mandatory User data type would need only one additional field. In our current and planned projects, most of the time that field is a list of pointers to account contnrs.

Couple of key perspectives:

  1. Contnr is a universal, standardized container for content. It does correspond to, say, a standard shipping container. From the outside, all standard containers are handled in the same manner, thus efficiencies of scale. Only when opened, they offer their custom content.
  2. Through features and contexts, contnr is effectively a node in a graph network and can connect to any other node, subject to security limitations and one cardinal rule: NO RECURSIVE REFERENCES! A contnr cannot be a context nor feature of itself anywhere in a graph chain!

Key question? Can contnr structure emulate any combination of custom “data types” and their properties? The simple answer is, yes by all means!

Key benefits?

  1. Contnr structures are fully reusable and transferable from apps to apps, including their UI and workflows. Switching templates anyone? :slight_smile:
  2. Not just the data, but even data structures are fully programmable.
  3. All contnrs are potentially multilingual and, for the first time (in bubble.io), that includes data type and field names.
  4. Data versioning. When a data type’s structure changes, the “old data type” becomes obsolete. Contnrs can, at the same time, manage any number of versions of the same “data type”.
  5. Since contnr is a node in a graph network, once fetched (a.i. brought into focus), it provides a convenient index (features and contexts) to all all other related data, so the workflows are one direct step away from anything directly relevant.
  6. Contnr can persist structures as simple as an equivalent of single instance of a single bubble.io “field”, to equivalent of a “thing”, to equivalent of “data type”, all the way to virtually infinitely complex structures of content, properties and their relationships.

Key challenge? Potential novelty.

Our objective with this post is to assess a potential level of interest for the idea. If that interest does exist, we will post more information on topics (pun intended) like: types of content, impact on workflows, adjustments to development methodology, apps vs. skills, workflows vs. rules, extensive scripting, etc.

CAVEAT: Implementing contnr in bubble.io has been a months long ongoing process and it may take another month or two to develop all key components. To all interested parties, patience required!

Why not just directly implement an edges table and bypass the performance limitations of large lists? In a social network the graph is rarely static. Rather the edges are transient, and thus best represented with to and from vertexes, and to and from dates representing when the edge was active, along with the usual weights and labels.