Хранилище JSONов от VK API

TL;DR

Для разработчиков, хорошо знакомых с VK API, здесь не будет ничего нового, просто я не так много и плотно с ним работал =)

---

Два принципа, которым я не изменяю:

1. писать в блог раз в месяц (но это если не забуду)
2. исследовать какой-нибудь вопрос, пока билдится приложение

Вот и сегодняшний день — не исключение, причем сошлись коса и камень.

Вспомнил тут, что однажды занимал меня вот такой вопрос — допустим, есть у меня некое веб-приложение, для которого мне нужно где-нибудь хранить пользовательские данные.

Как пример такого приложения — как-то очень давно делал очень простой таскер, который все задачи хранит в локальном хранилище браузера. Поскольку никакой авторизации там нет, то весь процесс по задачкам справедлив только для конкретного браузера конкретного устройства. Но у меня была тогда цель как-то вести свои рабочие таски, а написать своё было сильно интереснее, чем пользоваться готовым.

Однако, нормальное веб-приложение должно пользовательские данные синхронизировать, поскольку это удобно и в целом правильно.

Но вот полноценное API с базой данных и всякими штуками для такого маленького проекта пилить очень не хотелось (и сейчас не хочется, есть работа интереснее). Максимум — аутентификация пользователя, а вот сами данные хранить где-нибудь ещё. Тем более, что у меня там JSON’ы.

Есть и ещё одно условие, которое хотелось соблюсти — хранение данных должно быть на российском сервисе. Поэтому Firebase как очевидный вариант сразу отпадает =)

И буквально сегодня, пока приложение деплоится на сервер, а обед — в меня, решил порыскать в интернете. И нашёл интересный вариант — это использование методов Storage в VK API.

Они предназначены в первую очередь для того, чтобы разработчики могли пользоваться облачным хранилищем данных для мини-приложений VK, но… Нам нужно только авторизоваться с токеном доступа (причём, подойдёт даже сервисный ключ от приложения) и знать id пользователя.

Оффтоп: если интересно почитать про авторизацию в VK, дайте мне знать (в Telegram, VK или TenChat), там есть интересного.

Нам доступны три метода:

1. storage.getKeys — получение всех пользовательских ключей
2. storage.get — получение конкретного ключа (или нескольких ключей) пользователя по названию
3. storage.set — задаёт / обновляет / удаляет переменную

Конечно, как у любого условно-бесплатного API здесь есть ряд ограничений.

Во-первых, это длина значения переменной, всего 4 096 байт, всё, что будет дальше, обрежется.

Во-вторых, метод storage.set можно вызвать не более 1 000 раз в час на каждого пользователя.

И количество переменных у пользователя не может быть более 1 000 штук.

В целом, прям не густо, но если пошаманить с данными и их хранением, то что-то получить можно. Хотя это во мне говорит оптимист, а реалист предлагает уже поднять свою базу и не придумывать велосипеды. Но как же без них?

В целом, данное решение отлично подойдёт, если приложению нужно совсем немного специфических пользовательских данных (например, игра какая-нибудь). Прям на донышке. А для более масштабного количества данных такой вариант не подойдёт.

Надеюсь, моя заметка была полезна.