у нас бэк это группа сервисов.

окей)

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

как я понимаю писать импортеры из учетных систем не сильно интересное дело.  отклика пока мало.

уповаю на данный чат )

как мне кажется, тут дело в ошибочном выборе архитектуры, golang/python - имхо лучше бы подошел для такой задачи

да, вы правы. но нам выживательно пока на ларе это реализовывть.

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

уже делал.пока отклика не нашел. опытные ларавельщики не откликнулись. были ответи типа с рест апи еще не работал но попробую.

Хм. Может стоимость маленькая заявлена. Часто сталкивался с тем, что люди хотят за 50к на ларе "аналог bitrix24". Я просто такие предложения на fl игнорировал.
И ещё, по опыту, зачастую (но не всегда) легче нанять в штат разработчика и дать задачу, чем дать фрилансеру т.з. и получить то, что описано, но не то, что нужно

agile в этом плане бесценен

Суть в чём.
Почти всегда задача требует уточнения до "сферического Т.З. в вакууме" иначе велика вероятность, что человек сделает не то, что нужно.
Если делать маленькими шажками и с постоянным сотрудником:
1. Сотрудник думает о проекте, не как о разовой работе, может предложить более изящные решения
2. Сотрудник способен обслуживать систему.
3. У команды и руководства не тратится время на согласование всего т.з. в целом и на споры о несоответствии пунктов Т.З.
4. Если что-то изменилось, не надо "строить глазки" и просить на этом этапе остановиться, потому что "теперь делаем иначе"

Есть одно НО(!) коммуницировать с ним должен человек адекватный, а не с "синдромом вахтёра"

от бюджета надо плясать, если есть условные 50к на фичу то никого ты не наймешь

да тут скорее проблема в выборе технологии, писал я эти парсеры и работал с crm. Сегодня у тебя данных чуть-чуть php справится нормально, завтра вообще борода будет, тащить огромный веб фреймворк ради прослойки между 2 rest серверами и обработки этих данных на php такое себе. Особенно если учесть что человек говорит, что у него микро сервисная архитектура, можно взять абсолютно любой ЯП ( ну кроме php ) и сделать сказочно, да даже пускай и на php но написать тогда демона на php а не лару тащить

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

пхпшного гошника еще можно найти

Я бы поспорил.
На старте стек не важен. Особенно, если у руководства есть предпочтения.

Главное чтобы это начало приносить пользы (равно как и прибыль). Потом, при понимании важности и полезности задачи можно получить больше времени и денег на реализацию "быстрого и нормального".

Потому что сделаешь ты на go всё. А обслуживать некому, а исполнитель может и пропасть.
До нормальной полезности это не дорастёт и будет библиотека без обслуживания страдать и лагать. А следовательно и бизнесу от этого пользы нет

только его рейт будет значительно выше

.👍

ну тут как говорится "скупой платит дважды" но опять же, сегодня они хотят обслуживать 1 срм, завтра 2, послезавтра данных уже будет слишком много и у них не будет варианта, кроме как переписывать все с нуля и заново платить и хорошо, если столько же, а то и больше