mirrors/bonfire-app
1
0
Fork 0
mirror of https://github.com/bonfire-networks/bonfire-app.git synced 2024-04-28 23:38:44 +00:00
Code Issues Projects Releases Wiki Activity

doc

Browse source
This commit is contained in:
Mayel de Borniol 2023-12-31 10:28:36 +00:00
parent e1a9e44894
commit d6785fe914
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/ARCHITECTURE.md
View file

@ -53,7 +53,7 @@ The code is broadly composed namespaces such as these, many of which are package
Contexts are were we put any core logic. A context often is circumscribed to providing logic for a particular object type (e. g. `Bonfire.Posts` implements `Bonfire.Data.Social.Post`).
All Bonfire objects use an ULID as their primary key. We use the `Needle` library (with extra logic in `Bonfire.Common.Needle`) to reference any object by its primary key without knowing what type it is beforehand. This is very useful as it allows for example following or liking many different types of objects (as opposed to say only a user or a post) and this approach allows us to store the context of the like/follow by only storing its primary key (see `Bonfire.Data.Social.Follow`) for an example.
All Bonfire objects use an ULID as their primary key. We use the `Needle` library (with extra logic in `Bonfire.Common.Needles`) to reference any object by its primary key without knowing what type it is beforehand. This is very useful as it allows for example following or liking many different types of objects (as opposed to say only a user or a post) and this approach allows us to store the context of the like/follow by only storing its primary key (see `Bonfire.Data.Social.Follow`) for an example.
Context modules usually have `one/2`, `many/2`, and `many_paginated/1` functions for fetching objects, which in turn call a `query/2` function. These take a keyword list as filters (and an optional `opts` argument) allowing objects to be fetched by arbitrary criteria.