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