Comments 18
Спасибо! Полезная статья! Можно сервер собрать в докер образ, и тогда развертка будет делом пары минут.
Да, у нас нынче весь деплой на новых проектах через докер идет, тебе ли не знать)
Сами данные можно генерировать с помощью fake (https://github.com/marak/Faker.js/)
Так же расстраивает, чтодля ангуляра нет пока ничего похожего как Mirage для ember (https://github.com/samselikoff/ember-cli-mirage/)
нет, это решение не пробовал, вроде слышал о нем. Оно полностью соответствует поставленной задаче, спасибо. Посмотрю размеры, я так думаю json-server окажется более легковесным, тогда можно перейти на него.
JSON-Server еще можно поднимать в CI-джобе для интеграционного тестирования вашего приложения. Благо, у него куча настроек.
Мы пробовали его использовать. На старте было хорошо, когда начали появляться хитрые кейсы, POST запросы с бизнес логикой, начали мокать эррор хэндлинг и т.д., поддержка стала очень дорогой и всё перевели на экспресс. Я бы советовал джейсон-сервер только на самом старте и только для crud операций, либо сферического RESTfull апа.
У ангуляр-кли есть конфигуратор проксей для локальной разработки. Я бы посоветовал использовать его вместо самописного интерсептора, который замусоривает код. Пример использования (все ваши кейсы он отлично покроет):
github.com/angular/angular-cli/blob/master/docs/documentation/stories/proxy.md
Запилить api, и, согласно оговоренным контрактам, возвращать захардкоженные данные

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


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

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

Делать require внутри функции обработчика это самая большая жесть которую только можно сделать в NodeJS. Лучше обьявите books в начало модуля.

const books = require('./books');
Хотелось бы увидеть результаты с инт-тестами. Очень интересно увидеть ваш подход. Конечно решение на докерах будет очень и очень…
Постараюсь в ближайшее время подготовить статью на эту тему, к сожалению, пока работа не дает отвлечься на подготовку материала.

Вариант с express, и даже с json-server не очень хорош, поскольку тесты для CI не напишешь, для демонстрации работоспособности невозможно воспользоватся онлайн редакторами, типа StackBlitz или codepen и т.д., а для демонстрации даже коллеге со своей команды (например, тестировщику), нужно усложнение в виде контейнера какого-то...


В этом плане, конечно же, лучше использовать in-memory-web-api, но этот модуль подойдет только для совсем простых API.


Есть еще вариант с @ng-stack/api-mock (я являюсь его автором), но он еще сырой...

Only those users with full accounts are able to leave comments. Log in, please.