Про это есть в статье) Речь же ещё была про попытку заюзать уже готовый северный код на Go.
Про размер: гигабайты (возможно десятки их). Совершенно легко может быть кейс — выгрузить локально весь ящик за последние N лет со всеми аттачами и файлами в письме. Нам не нравилась история с загрузкой всего этого добра в браузер и перекладка в IndexedDB и обратно (Хотя, в статье я пишу, что это возможно конечно).
Я сам готов бесконечно евангилировать за PWA и весь веб-стэк.
Но наш эксперимент пошёл по-другому пути и я много уделяю внимания в тексте, чем мы руководствовались. Я вообще не претендую на то, что выбранные технологии — это самый лучший выбор из возможных. Это больше "вот мы взяли это, попробовали сделать PoC, вот что у нас получилось и к каким выводам мы пришли".
Я пишу, почему нельзя было сделать PWA в статье. Проблема именно в том, что один из основных запросов клиентов – выгрузка части писем локально (не в базу, а прям файлом) и взаимодействие с ними. Собственно поэтому и нужен толстый клиент и полноценная работа с файловой системой.
Да сервер, в данном случае тот же самый сервер, который отдаёт данные для web-версии и мобильных приложений. У нас аля REST API.
По поводу синхронизации, попробуйте покопаться вглубь CQRS (Command and Query Responsibility Segregation) — обычно этот паттерн используется в offline first системах. Предупреждаю, это на самом деле все очень непросто :)
У нас было только одно write действие, поэтому мы сделали очень просто: при наличии интернета мы сразу идём на сервер, а при отсутсвии изменяем локально + добавляем в специальную очередь событий пользователя, которая процессится при появлении интернета. Мы не сильно беспокоились о всех возможных кейсах, так как делали просто прототип.
Возможно вам интересен момент: "Что делать, если на сервере, пока на клиенте не было интернета, произошло что-то еще?" и всякие такие подобные колизии. Если кратко — то всегда доверять серверу, но лучше почитать непосредственно про подобные приложения отдельно, на том же хабре. Таких приложений много, особенно в мобильной и десктопной разработке.
не эксперт в Qt и не буду спорить (скорее всего Вы правы!), информацию брал из открытых источников (может ошибся). В статье она нужна больше для сравнительного порядка, чем для точной цифры, поэтому тщательно не проверял :)
Думали о решениях с нативным WebView тоже. Там нас немного отталкивали потенциальные проблемы с разными ОС и их версиями (WebView API не везде одинаковый, и там много раз нюансов есть).
Взяли пока Электрон как раз по той причине, что казалось, что поскольку там хромиум внутри — мы уверены, что наше приложение точно будет работать везде и именно так, как мы ожидаем. НО да, расплата — его объём.
В целом, в будущем, может быть погрузимся в эту тему глубже, спасибо за комментарий :)
Flutter рассматривали, да. Для нас он был в одной категории с Qt примерно. Переиспользовать существующий UI нельзя, но вариант привлекательный. Возможно, в дальнейшем попробуем провести R&D с ним уже :)
Цель была как раз проверить наши гипотезы в R&D и поделиться опытом. А теперь этот прототип пойдёт в UX тестирование, чтобы получить фидбек от тестовых групп, затем будут приниматься дальнейшие решения.
Про это есть в статье) Речь же ещё была про попытку заюзать уже готовый северный код на Go.
Про размер: гигабайты (возможно десятки их). Совершенно легко может быть кейс — выгрузить локально весь ящик за последние N лет со всеми аттачами и файлами в письме. Нам не нравилась история с загрузкой всего этого добра в браузер и перекладка в IndexedDB и обратно (Хотя, в статье я пишу, что это возможно конечно).
Я сам готов бесконечно евангилировать за PWA и весь веб-стэк.
Но наш эксперимент пошёл по-другому пути и я много уделяю внимания в тексте, чем мы руководствовались. Я вообще не претендую на то, что выбранные технологии — это самый лучший выбор из возможных. Это больше "вот мы взяли это, попробовали сделать PoC, вот что у нас получилось и к каким выводам мы пришли".
Я пишу, почему нельзя было сделать PWA в статье. Проблема именно в том, что один из основных запросов клиентов – выгрузка части писем локально (не в базу, а прям файлом) и взаимодействие с ними. Собственно поэтому и нужен толстый клиент и полноценная работа с файловой системой.
Да сервер, в данном случае тот же самый сервер, который отдаёт данные для web-версии и мобильных приложений. У нас аля REST API.
По поводу синхронизации, попробуйте покопаться вглубь CQRS (Command and Query Responsibility Segregation) — обычно этот паттерн используется в offline first системах. Предупреждаю, это на самом деле все очень непросто :)
У нас было только одно write действие, поэтому мы сделали очень просто: при наличии интернета мы сразу идём на сервер, а при отсутсвии изменяем локально + добавляем в специальную очередь событий пользователя, которая процессится при появлении интернета. Мы не сильно беспокоились о всех возможных кейсах, так как делали просто прототип.
Возможно вам интересен момент: "Что делать, если на сервере, пока на клиенте не было интернета, произошло что-то еще?" и всякие такие подобные колизии. Если кратко — то всегда доверять серверу, но лучше почитать непосредственно про подобные приложения отдельно, на том же хабре. Таких приложений много, особенно в мобильной и десктопной разработке.
не эксперт в Qt и не буду спорить (скорее всего Вы правы!), информацию брал из открытых источников (может ошибся). В статье она нужна больше для сравнительного порядка, чем для точной цифры, поэтому тщательно не проверял :)
Думали о решениях с нативным WebView тоже. Там нас немного отталкивали потенциальные проблемы с разными ОС и их версиями (WebView API не везде одинаковый, и там много раз нюансов есть).
Взяли пока Электрон как раз по той причине, что казалось, что поскольку там хромиум внутри — мы уверены, что наше приложение точно будет работать везде и именно так, как мы ожидаем. НО да, расплата — его объём.
В целом, в будущем, может быть погрузимся в эту тему глубже, спасибо за комментарий :)
Flutter рассматривали, да. Для нас он был в одной категории с Qt примерно. Переиспользовать существующий UI нельзя, но вариант привлекательный. Возможно, в дальнейшем попробуем провести R&D с ним уже :)
Никто на пользователей же ничего не запускал :)
Цель была как раз проверить наши гипотезы в R&D и поделиться опытом.
А теперь этот прототип пойдёт в UX тестирование, чтобы получить фидбек от тестовых групп, затем будут приниматься дальнейшие решения.