@jg10 I guess it depends on the use-case, but for the most part, I do see Pods as databases 😅.
For example, for Media Kraken I have "documents" or "pages" for Movies. But really, when I'm using them in the app, I could browse the data by release year, by director, by genre, etc. Each movie document doesn't have any inherent meaning for me. I could as well have all the movies in a single document, and the app would be the same. The only reason I don't is performance and practicality.
@noeldemartin I also agree with Ruben's post, but probably focusing on different parts 🤣
"If anything, there will be more document interfaces instead of less. What changes is the role document-centric interfaces play: they are views of an underlying, richer, graph-centric model. Use cases can choose the particular views on the pod’s data that reflect their context and constraints."
Atm users or apps manually create the view - that means we can already manually create future views too
@noeldemartin I would agree that your apps provide an example of how the document model can be effectively used in a database-centric way.
Each active record lends itself to be a human-sized page, and the local first pattern means you build a local database of all the pages.
It seems the automatic view that would be most useful would be an index page, e.g. a list of movies with labels and image links that could be browsed before or without having loaded all the individual movie pages.
@jg10 Honestly, I still agree with Ruben's post about Pods: https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/
At the time I said that I'd rather have a document-centric approach that works, instead of a theoretical database-centric approach we'll never have. And I still believe that. But when it comes to vision, I do prefer the database-centric approach.
If I want to have the concept of a "document" or "page" in my data, I'd rather have triples that say so.