Comments 14
WUBBA LUBBA DUB DUBS!!!
Ух! Синхронизация, как же много в этом слове…
Совсем не ясно как обстоят дела с консенсусом (Raft / Paxos) и CRDT структурами для консистентности в конечном счёте (Strong eventual consistency — SEC).
SEC в рамках распределённых хранилищ с кэшированием, довольно очень таки сложен, я очень сомневаюсь что он был решён в рамках предлагаемого решения. Особенно когда речь идёт о сегрегации моделей чтения и записи.
Я не понимаю чем этот Theron лучше того же Firebase, у которого нынче довольно привлекательная ценовая политика и поддержка Google.
Совсем не ясно как обстоят дела с консенсусом (Raft / Paxos) и CRDT структурами для консистентности в конечном счёте (Strong eventual consistency — SEC).
SEC в рамках распределённых хранилищ с кэшированием, довольно очень таки сложен, я очень сомневаюсь что он был решён в рамках предлагаемого решения. Особенно когда речь идёт о сегрегации моделей чтения и записи.
Я не понимаю чем этот Theron лучше того же Firebase, у которого нынче довольно привлекательная ценовая политика и поддержка Google.
Здравствуйте. Да, термин завораживает.
1. Следующая статья будет об архитектуре и алгоритмах, из который можно будет сделать выводы. Я считаю, что для цельного ответа на ваш вопрос нужно видеть всю картину устройства сервиса целиком и взаимодействие ее компонентов между собой. Также мы будем плавно открывать исходный код.
2. Приятно слышать, что вы сравниваете Theron и Firebase. Мне нравится Firebase (создание прототипа приложения происходит со скоростью света), и я продолжу его использовать там, где это имеет смысл. Я придерживаюсь идеи того, что серебряной пули не существует: для каждой индивидуальной ситуации наиболее подходящие инструменты различны. Недавно у Firebase было major-обновление, и я не успел на практике его изучить, поэтому ниже привожу основные моменты сравнения из опыта работы до обновления.
a) Я вижу, как Google выстраивает беcсерверную инфраструктуру для создания приложений в связке Angular и Firebase. Firebase — это не только хранилище, синхронизация данных, аутентификация, но и — после обновления — аналитика, хостинг файлов, монетизация и прочее. При использовании Firebase возникает полная зависимость приложения от него, но в начале статьи я написал, что одним из принципов Theron было отсутствие «вендор локинга». Eсли приложение простое и некритичное — все в порядке. В обратном случае я предпочту стек, состоящий из множества сервисов, которые могут быть заменены при необходимости так же, как Theron может быть легко заменен другой более подходящий технологией.
b) Cтруктурирование данных в Firebase происходит совсем иначе, чем в SQL и NoSQL базах данных. Особенно это хорошо видно при join-запросах: в Firebase данные нужно нормализировать (что правильно) и создавать join-узлы. Запрос таких структур сложнее, например, Figure изначально использовал Firebase, но стало очевидным, что некоторые моменты (ссылка на github) будут реализованы гораздо легче с использованием Postgres или Mongo. В Theron возможно использовать SQL запрос с подзапросом (ссылка на github), который будет содержать количество элементов из другой таблицы, и Theron будет отправлять новые инструкции, если количество этих элементов изменилось.
с) Про экономику и поддержку Google согласен: это Google, а не пара разработчиков-экспериментаторов. Но разве не так появляется что-то новое и в самом Google?
Вы мне подсказали идею составить таблицу Pros & Cons для Theron и Firebase — в список. Спасибо! Еще раз повторюсь, мне нравится Firebase и то, что они делают — это здорово.
1. Следующая статья будет об архитектуре и алгоритмах, из который можно будет сделать выводы. Я считаю, что для цельного ответа на ваш вопрос нужно видеть всю картину устройства сервиса целиком и взаимодействие ее компонентов между собой. Также мы будем плавно открывать исходный код.
2. Приятно слышать, что вы сравниваете Theron и Firebase. Мне нравится Firebase (создание прототипа приложения происходит со скоростью света), и я продолжу его использовать там, где это имеет смысл. Я придерживаюсь идеи того, что серебряной пули не существует: для каждой индивидуальной ситуации наиболее подходящие инструменты различны. Недавно у Firebase было major-обновление, и я не успел на практике его изучить, поэтому ниже привожу основные моменты сравнения из опыта работы до обновления.
a) Я вижу, как Google выстраивает беcсерверную инфраструктуру для создания приложений в связке Angular и Firebase. Firebase — это не только хранилище, синхронизация данных, аутентификация, но и — после обновления — аналитика, хостинг файлов, монетизация и прочее. При использовании Firebase возникает полная зависимость приложения от него, но в начале статьи я написал, что одним из принципов Theron было отсутствие «вендор локинга». Eсли приложение простое и некритичное — все в порядке. В обратном случае я предпочту стек, состоящий из множества сервисов, которые могут быть заменены при необходимости так же, как Theron может быть легко заменен другой более подходящий технологией.
b) Cтруктурирование данных в Firebase происходит совсем иначе, чем в SQL и NoSQL базах данных. Особенно это хорошо видно при join-запросах: в Firebase данные нужно нормализировать (что правильно) и создавать join-узлы. Запрос таких структур сложнее, например, Figure изначально использовал Firebase, но стало очевидным, что некоторые моменты (ссылка на github) будут реализованы гораздо легче с использованием Postgres или Mongo. В Theron возможно использовать SQL запрос с подзапросом (ссылка на github), который будет содержать количество элементов из другой таблицы, и Theron будет отправлять новые инструкции, если количество этих элементов изменилось.
с) Про экономику и поддержку Google согласен: это Google, а не пара разработчиков-экспериментаторов. Но разве не так появляется что-то новое и в самом Google?
Вы мне подсказали идею составить таблицу Pros & Cons для Theron и Firebase — в список. Спасибо! Еще раз повторюсь, мне нравится Firebase и то, что они делают — это здорово.
В сторону GraphQL не смотрели?
По-моему, схожие задачи решаете с Apollo
По-моему, схожие задачи решаете с Apollo
Здравствуйте. Есть ветка GraphQL в проекте. Я не знаком с Apollo: видимо Meteor начал работать над ним в феврале, когда мы над Theron. Спасибо, будем изучать.
Вы уже использовали Apollo? Есть моменты, на которые стоит сразу обратить внимание?
P.S. Я слежу за обсуждением синхронизации в реальном времени в Relay, и есть интересная заметка в блоге GraphQL/Relay.
Вы уже использовали Apollo? Есть моменты, на которые стоит сразу обратить внимание?
P.S. Я слежу за обсуждением синхронизации в реальном времени в Relay, и есть интересная заметка в блоге GraphQL/Relay.
Добрый день! В реальных проектах Apollo пока не использовал. Планирую в сентябре сделать GraphQL-backend к нашему сервису, тогда смогу написать ревью.
P.S. Разработчики из MDG ссылаются вот на эту статью (раздел Future Puzzles) как на один из источников вдохновения. Пока они не планируют делать реактивный GraphQL сервер — по крайней мере, не на первом этапе.
P.S. Разработчики из MDG ссылаются вот на эту статью (раздел Future Puzzles) как на один из источников вдохновения. Пока они не планируют делать реактивный GraphQL сервер — по крайней мере, не на первом этапе.
В реальных проектах Apollo использовал, полностью отказался в пользу Firebase. Основная цель проекта — предоставить решение для быстрой разработки стартапов на основе MongoDB. Использование любых других СУБД нецелесообразно для авторов проекта, потому что проекту важно срубить инвестиций, сначала для Apollo, потом для Meteor, а потом и для MongoDB… Важен полный Vendor Lock-in на этих решениях, просто потому что они им принадлежат.
О производительности, уместности и/или эффективности речь не идёт, главное обрисовать всё в розовых понях, и используя существующие проекты Fb, типа express-graphql, создать иллюзию вундервафли и сгрести ещё 30 лям вечнозелёных, как это уже было с Meteor пару лет назад, и как это уже было с MongoDB в 2009ом.
Я не говорю что GraphQL это плохо, я говорю что разработчики Apollo просто хотят огрести бабла за обёртку поверх решений Fb.
Что будет потом — покрыто туманом войны, и никаких гарантий поддержки/работоспособности сейчас нет.
О производительности, уместности и/или эффективности речь не идёт, главное обрисовать всё в розовых понях, и используя существующие проекты Fb, типа express-graphql, создать иллюзию вундервафли и сгрести ещё 30 лям вечнозелёных, как это уже было с Meteor пару лет назад, и как это уже было с MongoDB в 2009ом.
Я не говорю что GraphQL это плохо, я говорю что разработчики Apollo просто хотят огрести бабла за обёртку поверх решений Fb.
Что будет потом — покрыто туманом войны, и никаких гарантий поддержки/работоспособности сейчас нет.
блин, 21 век на дворе. Типизация пришла в каждый дом. Пора избавляться уже от костылей redux:
Чоб это не заменить на настоящий вызов метода с декоратором или создать целый объект для обработки?
switch (action.type) {
case ROW_ADDED:
Чоб это не заменить на настоящий вызов метода с декоратором или создать целый объект для обработки?
Можете вставить пример того, как вы это видите?
Человек наверняка предлагает использовать TypeScript/Flow из-за своих личных предпочтений и религии «что всё остальное — ерунда».
Хотя на самом деле у самого практики разработки не хватает, что бы понимать недостатки этих решений в действительно больших проектах, или «почему в MS/Fb ещё не всё переписано на TypeScript/Flow, и, быстрее всего, никогда и не будет переписываться ?».
Хотя на самом деле у самого практики разработки не хватает, что бы понимать недостатки этих решений в действительно больших проектах, или «почему в MS/Fb ещё не всё переписано на TypeScript/Flow, и, быстрее всего, никогда и не будет переписываться ?».
Так не костыли это вовсе, а нормальный функциональный подход. Другое дело, что ни js, ни ts не предоставляют нормальных конструкций под это дело, когда все элегантно решается через pattern-matching. А вообще при знакомстве с redux перед глазами упорно маячил gen_server из erlang/otp.
Sign up to leave a comment.
Синхронизация данных в приложениях реального времени c Theron