Vahman16 июл 2019 в 06:10

Angular: когда надо пилить приложение, а backend еще не готов

4 мин

13K

Angular * JavaScript * TypeScript * Программирование *

Комментарии 18

sudoroot 16 июл 2019 в 06:43

Спасибо! Полезная статья! Можно сервер собрать в докер образ, и тогда развертка будет делом пары минут.

Vahman 16 июл 2019 в 06:53

Да, у нас нынче весь деплой на новых проектах через докер идет, тебе ли не знать)

Soupbreak 16 июл 2019 в 08:15

Сами данные можно генерировать с помощью fake (https://github.com/marak/Faker.js/)
Так же расстраивает, чтодля ангуляра нет пока ничего похожего как Mirage для ember (https://github.com/samselikoff/ember-cli-mirage/)

Toori 16 июл 2019 в 08:15

Скажите, а вы пробовали вот это решение?
github.com/typicode/json-server

Vahman 16 июл 2019 в 08:18

нет, это решение не пробовал, вроде слышал о нем. Оно полностью соответствует поставленной задаче, спасибо. Посмотрю размеры, я так думаю json-server окажется более легковесным, тогда можно перейти на него.

Toori 16 июл 2019 в 08:42

JSON-Server еще можно поднимать в CI-джобе для интеграционного тестирования вашего приложения. Благо, у него куча настроек.

Raspy 16 июл 2019 в 20:39

Мы пробовали его использовать. На старте было хорошо, когда начали появляться хитрые кейсы, POST запросы с бизнес логикой, начали мокать эррор хэндлинг и т.д., поддержка стала очень дорогой и всё перевели на экспресс. Я бы советовал джейсон-сервер только на самом старте и только для crud операций, либо сферического RESTfull апа.

hudson 16 июл 2019 в 12:47

Имеется вот такой пакет github.com/angular/in-memory-web-api

Попробуйте, может то что нужно.

Vahman 16 июл 2019 в 13:10

спасибо, посмотрю

Raspy 16 июл 2019 в 20:48

У ангуляр-кли есть конфигуратор проксей для локальной разработки. Я бы посоветовал использовать его вместо самописного интерсептора, который замусоривает код. Пример использования (все ваши кейсы он отлично покроет):
github.com/angular/angular-cli/blob/master/docs/documentation/stories/proxy.md

White_Scorpion 17 июл 2019 в 06:39

Запилить api, и, согласно оговоренным контрактам, возвращать захардкоженные данные

Эээээ… А как насчёт

Запилить тестовый api и прошить линки ссылок в приложении на конфиг, который поменять, когда выйдет "боевой" api, не?

Vahman 17 июл 2019 в 06:57

Если я вас правильно понял, то так и получилось в итоге. Но фейковый апи хотелось иметь в доступе, если боевой готов не полностью, оставалась возможность продолжать разрабатывать фронт с опережением. Во вторых тесты гонять на нем удобнее, поэтому нужна была параллельная конфигурация на фейк апи, а не просто замена линки одной на другую.

White_Scorpion 17 июл 2019 в 07:44

Если подключён аналог репозитория с DI только не на базу данных, а на ссылки api то вам боевой — вообще не нужен. Как собственно и должно быть по фен-шую разработки :). Если вам для вашей разработки нужны "реальные данные" — то что-то сдохло у вас в Датском королевстве и от этого надо отходить.
Вам же главное знать, что api вызывается и возвращает результаты, котоыре вы можете отработать.