@xanf_ua буду рад если ответите) у нас есть команда, бекенд на руби, фронт реакт на нексте. Общаются по ресту. Команда довольно большая, около 20 человек, часто выходит ситуация, бекенд работает вперёд фронта, чтобы ему было с чем работать позже. И на стадии фронта часто выходит, что эндпоинты некорректные и возвращают назад бекенду, как можно проконтролировать или какие вообще есть способы когда команда из отдельных фронтов и бекендов нормально взаимодействовала без огромного количества коммуникации и выдавала корректные требованиям эндпоинты и не увеличивала итерации?

Введите итерацию проектирования АПИ
Где будете вместе бэк+фронт наваливать
Дальше разбегайтесь хоть по разным галактикам)
Вперед работать не обялзательно, есть разные инструменты для мокания АПИ

что-то вроде api-first подхода. Ни разу не применял на практике, но звучит интересно!

Вот вроде обсуждаем, но выходит снова часто так( И часто и в других командах так, что мне кажется либо чтобы все фулстеками были или брать графкьюэль, хотя врдя ли он спасет, там можно тоже напартачить
А у вас выходят нормлаьные процессы для отдельных команд или всё равно всё сваливается в бесконечную коммункацию и доработки?

Кто отошел от оговоренной спеки без уведомления - переделывает.
Пару раз переделают и все выровняется)

Но сначала тесты

Сваггер не используете?

Это для тестирования API? Вроде пишутся интеграционные тесты на своих технологиях(я просто не оч в курсе на какой либе, думаю, аналог supertest в ноде)

Это документирование всего api и в какой-то мере тестирование, если на фронте что-то упало, то в свагерре можно пойти и посмотреть, что поменялось и там же потестировать

Вот хочу попробовать PACT...
Кто-нибудь может пробовал и может что-нибудь сказать?

сделал хеш объект из массива (ключ: значение).
но возникает проблема как теперь удалить оттуда значение. приходиться всем другим ключам заменять key. не знаете есть ли какое-то готовое решение для такой задачи?

код примера для понимания, был массив:

{arr: [{value: 'a'}, {value: b}]}

сделали хеш объект:

 {'arr[0]': {value: 'a'}, 'arr[1]': value: b}

И теперь проблема как удалить из хэш объекта 'arr[0]', потому что все последующие ключи должны убавить индекс в ключах.

{arr: [{value: 'a'}, {value: b}]}

 {'arr[0]': {value: 'a'}, 'arr[1]': value: b}

Если важен порядок элементов, то храните в массиве, хешмапа не даст никаких преимуществ в этом случае

да в тмо и проблема. что хеш мап дает массу преимуществ в моем случае. но вот как дело коснулось удаления так получилась проблема.
на ум приходит только вернуться к начальному объекту и потом уже в массиве удалять..

{arr: [{value: 'a'}, {value: b}]}

 {'arr[0]': {value: 'a'}, 'arr[1]': value: b}

Кажется вы решаете проблему, которую сами же создали. Вернитесь на шаг назад, на два, чтобы переосмыслить структуру данных.

Вам нужно нормализовывать данные в таком случае. Сущности хранить в хешмапе по ид, а порядок в отдельном массиве с айдишниками

когда говорят о нормализации что обычно имеют ввиду

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

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

В массиве порядок сущностей, в объекте сами сущности. В этой схеме нет ничего необычного. Удалили из массива и если нужно(!) без труда удалили из хешмапы, что в этом сложного?

вот что