О системных и полусистемных коллекциях

[Гимаев Наиль]

Хранить всякую системную информацию удобно в коллекциях. Это позволяет пользоваться одинаковыми инструментами для всех задач. На данный момент OData используется только на фронтенде. Но со временем будет обязательно использоваться и на бэкенде. К примеру, перед добавлением нужно проверить, что в коллекции не более 3-х записей такого же типа. Проверить это можно только с помощью запроса. И совершенно логично использовать на бэкенде для этого тот же механизм, что и на фронтенде. И совершено логично, что проверки связанные с файлами удобно проводить обращением к коллекциям, а не с использованием отдельного API для API.

Тут приходим к тому, что коллекции бывают трёх типов:

Обычные, системные и полу-системные.

Обычные - это те коллекции, которые есть в databoom сейчас.

Системные - которые создаются системой (не разработчиком) и не доступны на фроненде.

Полу-системные - коллекции созданные разработчиком, доступные на фронтеде. Но имеющие ограничения или особенности накладываемые системой.

Чтобы отличать системные коллекции от обычных нужно использовать префиксы. Например $ - для полу-системных, и _ - для системных.

Естественно создавать коллекции с именами начинающимися на префиксы разработчик не может, во избежание проблем.

Тогда путь к системной коллекции файлов будет иметь путь

/api1/dbname/collections/_files

и будет доступен доступен только для бэкенда.

Гораздо интереснее полу-системные коллекции.

К примеру, пусть разработчик создаёт коллекцию коллег пользователя:

/api1/dbname/user/collections/coworkers

обратите внимание на /user/ в пути - это особый путь для коллекций имеющих отношение к пользователю. В таких коллекциях хранятся данные влияющие на права доступа.

Если обращаться по этому пути, то это обыкновенная коллекция с данными имеющими только к текущему пользователю.

Если же обратиться по пути

/api1/dbname/collections/$user_coworkers

то получим то же самое, но с дополнительным полем _user_id, только если обращаться со стороны фронтенда, это будут данные текущего пользователя, а если обращаться со стороны бэкенда, то данные всех пользователей.

Все это в комплексе позволяет описывать правила авторизации любой сложности.