Google Firebase - переформатировать JSON вывод - PullRequest
Новая
       2

Google Firebase - переформатировать JSON вывод

1 голос
/ 27 января 2020

Я использую Google Firebase, который генерирует JSON с такими данными: 

{
    "tasks": {
        "-LzH6kQjS_nY4P97EONB": {
            "createdBy": "Andrew",
            "date": "\"2020-01-23T11:17:24.213Z\"",
            "description": "Some task description.",
            "done": false
        }
    }
}

Я хотел бы преобразовать его в этот формат: 

[
    {
        "id": "-LzH6kQjS_nY4P97EONB",
        "createdBy": "Andrew",
        "date": "\"2020-01-23T11:17:24.213Z\"",
        "description": "Some task description.",
        "done": false
    }
]

Я думаю Я могу обработать часть преобразования (если вы, ребята, не видите здесь ничего невозможного), но я не могу придумать способ «возврата» преобразованного файла JSON, поэтому он всегда доступен по ссылке. Есть ли способ сделать это без особых хлопот и без риска для безопасности Firebase?

1 Ответ

1 голос
/ 27 января 2020

Вот несколько возможных решений:

  1. Создайте Функцию облачного хранилища, запускаемого из базы данных , которая будет запускаться каждый раз, когда задача добавляется по вашему пути tasks. Эта функция должна использовать вновь добавленные данные для обновления массива по другому пути, например tasksAsArray. Вы можете использовать транзакцию , чтобы прочитать существующий массив, добавить новый элемент и сохранить новый массив. Затем используйте этот путь в URL-адресе ". json" для Qlik.

  2. Создайте вызываемую HTTP-функцию , которая будет считывать ваш tasks из базы данных и возвратите массив в нужном формате в качестве ответа.

  3. Измените код клиента, чтобы записывать данные непосредственно в нужном формате.

С решением 1 с годами и ростом данных производительность транзакции начнет падать, но, вероятно, не заметно. Если вам не нужны очень старые данные в вашем ответе, вместо добавления задач в массив, вы также можете удалить из них старые данные, чтобы ограничить размер массива.

С решением 2, вы можете Limit Queries включать только задачи последних нескольких месяцев или лет.

Решение 3 требует, чтобы клиенты точно знали, сколько уже существует задач *, поэтому что они добавят новую задачу по правильному индексу. Вы сказали, что одновременно будет 20 пользователей, поэтому существует риск, что несколько клиентов будут писать по одному пути, и произойдут перезаписи.

Чтобы предотвратить перезаписи, вы можете использовать правило базы данных, например this один и обработайте ошибки на клиенте (повторите попытку с правильным индексом).

Вы также можете выполнять транзакции базы данных от клиентов, но это может замедлить добавление задач, так как ваш массив становится большим. Облачная функция не заботится о том, что для ее выполнения требуется несколько секунд, но пользователю важно:)

* Чтобы узнать, сколько задач уже существует, вы можете прочитать весь массив и сосчитать элементы. Вместо этого вы можете создать фоновую облачную функцию, которая будет поддерживать путь taskCount, который будет просто количеством задач. Тогда клиенты могут просто прочитать этот номер.

...