Дело в том, что при таком подходе для изменения API ты должен вносить не связанные изменения и на стороне клиента и на стороне сервера.
Да это плохо, этого нельзя было допускать с самого начала. Фронтенд и бэкенд должны жить независимо друг от друга. У них есть связующее звено — спецификация протокола и документация — API. Они не должны залазить во внутреннюю кухню другой стороны, а лишь соответствовать текущей документации. Вносить правки в документацию API можно только по согласованию. Все. Если вам нужна защита от дурака или случайно ошибки можно написать везде тестов. Тесты фронтенда должны проходить проверку соответствия внутренней структуры моделей и текущей документации, а тесты бэкенда аналогично проходят по своей внутренней структуре.
Мне всегда казалось что это какие-то капитанские вещи.
Плюс, как я писал некоторые разработчики меняя модель данных на сервере не всегда меняли модель данных на мираже.
Ну вот это и есть рука лицо и отсутствие культуры. Как один разработчик может внести изменения в что-то что затрагивает другие части системы без элементарного уведомления, не говоря уже об согласовании. Ну вот поменял бэкендер api и структуру в mirage, а правки в бизнес логику кто вносить будет?
Поправьте меня если я не все понял, но думаю у вас было бы значительно меньше проблем, если бы:
1. В начале 2017, начиная новый проект, вы вызяли бы не архаичный REST, a JSONAPI, который более строгий и при этом имеет больше возможностей.
2. За место fuxtures использовали mirage, поддержкой которого занималась фронтенд сторона.
3. Имели бы четкую документацию API, изменения в которую разрешалось только после ревью и согласования всех кто с ней работает.
4. Писали бы тесты которые выявляют все ошибки API как на бэкенде так и на фронтенде.
И вообще судя по описанию проблемы у вас скорее беда с культурой разработки в команде, а не трудностью согласовывать API, так как это скорее следствие, а не причина.
Как раз в Ember.js кастомизируется если не все, то почти все, через extend и reopen.
У ember-data по сути только и есть единственная существенная проблема это нет отслеживания изменений связи из коробки, и то отказаться от этого были причины.
Недавно покупал ноутбук MSI, специально звонил на их линию узнавал, пломба у них на корпусе есть, но ее можно сорвать это никак не повлияет на гарантию, к тому же ноутбук можно модернизировать например добавив памяти (что я и делал) или ssd диск.
Спасибо за перевод.
Фанатам рекомендую к просмотру замечательный ролик по KOTOR — https://www.youtube.com/watch?v=pdyNxpYqGxA
У меня напоминания:
Да это плохо, этого нельзя было допускать с самого начала. Фронтенд и бэкенд должны жить независимо друг от друга. У них есть связующее звено — спецификация протокола и документация — API. Они не должны залазить во внутреннюю кухню другой стороны, а лишь соответствовать текущей документации. Вносить правки в документацию API можно только по согласованию. Все. Если вам нужна защита от дурака или случайно ошибки можно написать везде тестов. Тесты фронтенда должны проходить проверку соответствия внутренней структуры моделей и текущей документации, а тесты бэкенда аналогично проходят по своей внутренней структуре.
Мне всегда казалось что это какие-то капитанские вещи.
Ну вот это и есть рука лицо и отсутствие культуры. Как один разработчик может внести изменения в что-то что затрагивает другие части системы без элементарного уведомления, не говоря уже об согласовании. Ну вот поменял бэкендер api и структуру в mirage, а правки в бизнес логику кто вносить будет?
1. В начале 2017, начиная новый проект, вы вызяли бы не архаичный REST, a JSONAPI, который более строгий и при этом имеет больше возможностей.
2. За место fuxtures использовали mirage, поддержкой которого занималась фронтенд сторона.
3. Имели бы четкую документацию API, изменения в которую разрешалось только после ревью и согласования всех кто с ней работает.
4. Писали бы тесты которые выявляют все ошибки API как на бэкенде так и на фронтенде.
И вообще судя по описанию проблемы у вас скорее беда с культурой разработки в команде, а не трудностью согласовывать API, так как это скорее следствие, а не причина.
У ember-data по сути только и есть единственная существенная проблема это нет отслеживания изменений связи из коробки, и то отказаться от этого были причины.
Действительно будут небольшие отличия если использовать Ecto 2, например валидация в changeset