Здравствуйте. Есть ветка GraphQL в проекте. Я не знаком с Apollo: видимо Meteor начал работать над ним в феврале, когда мы над Theron. Спасибо, будем изучать.
Вы уже использовали Apollo? Есть моменты, на которые стоит сразу обратить внимание?
P.S. Я слежу за обсуждением синхронизации в реальном времени в Relay, и есть интересная заметка в блоге GraphQL/Relay.
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 и то, что они делают — это здорово.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Вы уже использовали Apollo? Есть моменты, на которые стоит сразу обратить внимание?
P.S. Я слежу за обсуждением синхронизации в реальном времени в Relay, и есть интересная заметка в блоге GraphQL/Relay.
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 и то, что они делают — это здорово.