Комментарии 7
Вроде очевидные вещи, что нужен класс для работы с api, и что программа должна не зависеть от доступности интернета. Врядли разработчики такие глупые, чтоб самим не догадаться. Скорее всего корни проблемы идут от кучи стартапов, в которых пишут все за вечер, чтобы поскорее получить инвестиции, потом начинают переделывать, понимают какую лажу они написали, переписывают, а потом уже на конференции выступают с докладами.
+1
Сам давно использую где есть необходимость. Для тех, кто делает сайты на Django, могу порекомендовать django-pipeline + manifesto (они от одного автора) для удобного создания AppCache манифестов.
+1
Подход offline first предполагает перемещение всего стека MVC на сторону клиента. На стороне сервера остаётся только лёгкий JSON API для доступа к БД. Благодаря этому серверный код становится намного меньше, проще, и его легче тестировать.
Сомнительный плюс. Тестировать клиентский код на js, мне кажется, ничуть не легче. А если оставить большую часть кода (притом самую важную и самую кастомную) не покрытой тестами — что это за покемон получится?
Я, возможно, безбожно устарел и просто не поспеваю за современными реалиями, но почему-то мне кажется, что оффлайн-подход к web-приложениям — это оксюморон.
То есть, сами по себе пункты про JSON и API звучат неплохо, но в целом непонятно что получается. Предполагается, что надо написать одинаковую кучу кода на клиенте и на сервере: на клиенте, чтобы это все круто работало с LocalStorage, а на сервере — чтобы это все вообще хоть как-то работало. И потом это все покрыть разными тестами. И еще я представить боюсь, что там с функциональными тестами будет для такого приложения. Где я неправ, подскажите, пожалуйста?
+4
Для приложений да, самый раз.
Тоже к этому варианту пришли, т.к не нужно завязывать пользователя на серверной БД
Тоже к этому варианту пришли, т.к не нужно завязывать пользователя на серверной БД
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Offline first» подход к созданию веб-приложений