Comments 15
- Написать фреймворк для списка дел.
- Зачеркнуть первый пункт.
- ???
- Прибыль!
Привет. Звучит вкусно. Для коллаборейтива, получается, нужно только добавить другие типы данных? Архитектурно этому ничего не мешает? Ну да, ещё нужно, чтобы компоненты генерировали правильные операции над данными. И тогда уже получается полный аналог стека Derby/Racer/Share. Помимо оффлайна получаем ещё промисы и, я так понимаю, отсутствие необходимости мучительно пихать все подписки в контроллер. Вкууусно. В дерби даже последние два пункта при моей жизни, видимо, не сделают.
От этих проекций толку мало, на мой взгляд. Один только юзкейс с пользователями и паролями. Я в Share использую filter и "вырезаю" ненужное динамически, в зависимости от того, откуда идёт запрос (клиент или сервер) и от прав доступа.
В preHook можно менять операцию? Всё-таки при создании документа дату хотелось бы сохранять именно так, а не через пост-хук. Чтобы получить атомарность в таких простейших случаях. В рейсере, я так и не понял, можно это делать или нет.
У дмаппера есть большие планы на проект?=)
Желаю успехов. Мне кажется, что проект имеет очень большие шансы выстрелить. Особенно, если ангуляр2 не пошатнет позиции реакта.
От этих проекций толку мало, на мой взгляд. Один только юзкейс с пользователями и паролями. Я в Share использую filter и "вырезаю" ненужное динамически, в зависимости от того, откуда идёт запрос (клиент или сервер) и от прав доступа.
В preHook можно менять операцию? Всё-таки при создании документа дату хотелось бы сохранять именно так, а не через пост-хук. Чтобы получить атомарность в таких простейших случаях. В рейсере, я так и не понял, можно это делать или нет.
У дмаппера есть большие планы на проект?=)
Желаю успехов. Мне кажется, что проект имеет очень большие шансы выстрелить. Особенно, если ангуляр2 не пошатнет позиции реакта.
И еще: не думал над тем, чтобы такие пути "users.2.name" заменить на такие: "users[2].name"?
Другие типы данных теоретически можно добавить, но это не в ближайших планах. К тому же я еще не придумал как лучше это сделать. Можно, например, попробовать сделать общий JSON тип данных, как в ShareJS, который включает операции над объектами, массивами, строками и числами, но это не просто. Другой вариант, сделать, документы с типом "строка". То есть у документа как бы нету полей и он является строкой. Такое сделать проще и, вообщем, достаточно для коллаборационного редактирования текста.
Поправь меня, если я не прав, в фильтре можно убирать не нужные поля при чтении, но нельзя ограничивать их редактирование. Вообще, мне надо глянуть на это, спасибо за наводку. Просто по какой-то причине, я, наоборот, использую проекции и не использую фильтры.
В preHook операцию менять нельзя, также как и в Racer. Ибо тот кто, тебе эту операцию послал ничего об этом изменении не узнает и у него останется старая версия операции. Тут в любом случае нужна еще одна операция. По поводу атомарности можно подумать, потому что в Amelisa состояние и oplog хранятся в одном документе и по идее, если применять несколько операций на сервере синхронно, то можно сделать, что они должны сохраниться либо все вместе, либо ни одна из них.
По поводу путей. Сейчас можно писать так
Пилим мобильное приложение на Amelisa. Надеюсь стабилизировать до релиза :-)
Спасибо за пожелания.
Поправь меня, если я не прав, в фильтре можно убирать не нужные поля при чтении, но нельзя ограничивать их редактирование. Вообще, мне надо глянуть на это, спасибо за наводку. Просто по какой-то причине, я, наоборот, использую проекции и не использую фильтры.
В preHook операцию менять нельзя, также как и в Racer. Ибо тот кто, тебе эту операцию послал ничего об этом изменении не узнает и у него останется старая версия операции. Тут в любом случае нужна еще одна операция. По поводу атомарности можно подумать, потому что в Amelisa состояние и oplog хранятся в одном документе и по идее, если применять несколько операций на сервере синхронно, то можно сделать, что они должны сохраниться либо все вместе, либо ни одна из них.
По поводу путей. Сейчас можно писать так
model.get('users.2.name') и так model.get('users', 2, 'name'). Твой вариант со скобочками — это отсылка к динамическим свойствам js?Пилим мобильное приложение на Amelisa. Надеюсь стабилизировать до релиза :-)
Спасибо за пожелания.
Поправь меня, если я не прав, в фильтре можно убирать не нужные поля при чтении, но нельзя ограничивать их редактирование.
Да, конечно. Но инструмент гораздо более гибкий. На мой вгляд, запрет на редактирование должен осуществляться по-другому. Ближе всего к этому заброшенный racer-access. Нужно прописывать этакие правила, как в фаерволе, для всего, что разрешено. Всё остальное запрещено. От racer-access мне только чуть не хватает высокоуровневости. Чтобы одновременно описывать и создание, и редактирование документа. А то часто DRY из-за этого нарушается. В общем, над этой темой надо покумекать, но пока времени нет. Хочется server-query, racer-access, share-scheme и фильтры как-то скомбинировать.
В preHook операцию менять нельзя, также как и в Racer. Ибо тот кто, тебе эту операцию послал ничего об этом изменении не узнает и у него останется старая версия операции.
Да, тупанул. Иначе же никакого оффлайна не выйдет, действительно. Хотя вот racer мог бы заменять свою операцию на ту, что вернётся с сервера. Хоть это и геморрой. Транзакции были бы вообще бомбой, но с оффлайном, наверное, всё равно возникнут проблемы.
По поводу путей.
Нет, это отсылка к массивам.) Просто с дерби получается, что биндинг мы делаем так: {{ user.names[1] }}, а операцию делаем через 'user.names.1'. И я вот не понимаю, зачем вообще ввели эту нотацию. Плюс к этому, я использую lodash, который тоже поддерживает нотацию с квадратными скобками. И получается, что $user.get('names.1'), но _.get($user.get(), 'names[1]'). А ещё один раз я хотел получить объект, у которого ключи начинались с цифры. И фиг. Но это, конечно, не самое страшное.
Пилим мобильное приложение на Amelisa.
Это не большие планы.) Заменить derby на amelisa — большие планы.)
Спасибо за пожелания.
Да, какой там. Этож в моих интересах.) Так что спасибо за проект. Вселяет надежды.
В racer-access можно было ограничить доступ к документу целиком, но не к конкретным полям. По этому и появились проекции.
Если придумаешь какой-то красивый интерфейс для access control, дай знать. Тут определенно что-то нужно сделать.
По путям. В Amelisa нет темлейтов, по этому такой путаницы не будет. Но при желании можно добавить нотацию с квадратными скобками.
В Derby для ключей из цифр нужно добавлять
Если придумаешь какой-то красивый интерфейс для access control, дай знать. Тут определенно что-то нужно сделать.
По путям. В Amelisa нет темлейтов, по этому такой путаницы не будет. Но при желании можно добавить нотацию с квадратными скобками.
В Derby для ключей из цифр нужно добавлять
_ перед ним в пути. Где-то в доках это есть. Дело в том, что если он видит цифру в пути, то подразумевает, что это должен быть массив. В Amelisa нет операций массивами, соответственно, нет таких проблем :-)Ты путаешь с share-access скорее всего. Racer-access позволял сделать так:
store.allow 'remove', 'users.*.names', (userId, index, howMany, doc, session) -> session.user.id == userId
Щаблон для пути можно указать любой. Но чего-то мне всё ещё не хватает. В ближайшее время надеюсь его переписать. Буду думать над этим. Если что дельное придумаю, дам знать.
store.allow 'remove', 'users.*.names', (userId, index, howMany, doc, session) -> session.user.id == userId
Щаблон для пути можно указать любой. Но чего-то мне всё ещё не хватает. В ближайшее время надеюсь его переписать. Буду думать над этим. Если что дельное придумаю, дам знать.
Однозначно в избранное и звезду на github. Есть у меня один проект, который сейчас в стадии "уже надо рефакторить" и ваша разработка очень кстати.
- Для меня главной характеристикой CRDT/OT-подобных систем является ограничение на выбор бэкенда. Ни одно существующее решение невозможно встроить в имеющийся бэкенд, только начинать с нуля. Это очень грустно. А Swarm так вообще заменяет собой бэкенд, и всю бизнес-логику приходится писать в подобии хранимых процедур.
Amelisa каждый документ — это обычный key-value (операции над объектами).
Не понятно, о каком типе данных идет речь. В моем JS-понимании "объект" подразумевает JSON.
- Совсем не понимаю, зачем нужно делать привязку к React в качестве требования. Это же слой модели, почему он должен быть жестко завязан на одну реализацию вьюхи? На крайняк же можно сделать абстрактный слой модели и адаптер под вьюху, типа,
amelisa,amelisa-react,amelisa-angular, etc.
- Это правда. Объясняется это наличием метаданных (oplog, версии документов и тп), что делает практически невозможным изменять данные в БД, в обход движка. К тому же обычно на сервере нужна NodeJS. Выбор баз данных тоже ограничен. Встроить это в существующую систему практически невозможно. По крайней мере, потребует кардинального изменения архитектуры, где, например, Mongo будет хранилищем данных, которые интересны фронт-энду, и остальной бэк-енд будет в нее складывать результаты каких-нибудь вычислений/преобразований.
- Здесь имеется ввиду, что в Amelisa есть только операции подобные key-value хранилищу: можно записать значение в поле объекта и удалить поле из объекта. В JSON существуют еще массивы, числа, строки, каждый из которых имеет свои операции. Например, можно добавить элемент в конец массива (даже не зная сколько там уже элементов) или, например, инкрементировать число (не зная его текущего значения). Полноценная JSON-реализация есть в ShareJS.
- Всё правильно говоришь. Жесткой привязки к вьюхе нету. Просто для начала взят React, как одна из популярных вьюх, к которой довольно легко привязаться, для чего написано пару хэлперов. В будущем добавятся другие вьюхи/фреймворки и логично будет разнести это по модулям, как ты и написал. Просто на данный момент не хочется распыляться. К тому же можно будет попробовать посмотреть на другие базы данных, например, RethinkDB выглядит интересной.
5) Как насчет ACL (гибкой настройки прав доступа — на уровне документа, на уровне поля)?
Так как движок документо-ориентированный и минимальной сущностью, на которую можно подписаться, является документ, с ограничениями прав на уровне документа нету проблем. Есть серверный хук
preHook, через который проходят все операции и там можно выбросить ошибку, если нет доступа. Хочется добавить, конечно, какой-нибудь декларативный способ это делать в будущем. С полями чуть сложно. Самое лучшее решение, что я знаю — это концепция проекций в ShareJS. Проекция — это виртуальная коллекция, документы, которой содержат только часть полей. С проекцией можно работать так же, как и с обычной коллекцией. Если ты из нее что-то читаешь, то у документов "обрезаются" лишние поля. Если ты в нее пишешь, то идёт проверка, на то, чтобы операции были только в разрешенные поля, иначе ошибка. Ровно в таком же виде, проекции есть в Amelisa.
довольно успешно использовал на одном проект решение, построенное с использованием Dexie.js — на клиенте использовал аддоны, идущие в поставке с Dexie, бекенд реализовал взяв за основу заготовку, также предоставляемую в примерах Dexie.js
Sign up to leave a comment.
Amelisa. Оффлайн и реалтайм движок для React и Mongo