Lets say one could have 3 collections: articles, blogs and comments.
Creating queries for all of them would be simple same as creating indexes.
Now, what i wonder is what instead of articles, blogs and comments there would be just one collection called for example items.
Each item in items would have type like {type:blog-post} or {type:article}.
I don’t know if that’s efficient or is it anti-pattern.
Why one would do such thing?
Mainly it would be convenient for creating newsfeeds and adding new types of content in the future.
It wouldn’t require (re)creating indexes when new type of content is introduced that also can be followed. (Like you can follow your friend on Facebook but also a Page)
I think this is something that Fauna absolutely excels at!
It’s not compatible with the GraphQL API, since it lacks Interface/union support, which bums me out…
But sometimes discriminated unions are a very appropriate data structure in an application.
So I would say, use which ever pattern works well for your application. In your case, maybe comments could stay separate? I don’t know! So that’s why I hesitate to suggest which one you go with. But you shouldn’t be afraid to consider the union-type collection.
@ptpaterson answered this perfectly, so I don’t have a lot to add besides confirming what he said.
FaunaDB collections should scale perfectly so what you are doing is therefore imo not an anti-pattern. Sometimes that’s just a convenient way to model things and FaunaDB is flexible allowing you to model in many ways.
