lssssssssssl

https://svelte.dev/
https://handlebarsjs.com/

Есть подозрение, что вы работаете в Live-режиме.

При устройстве самозанятым четко проговорите с работодателем:
1. Отпуск - условия, оплату, и т.п.
2. Больничные - сколько дней можно болеть без больничного, требуются ли вообще больничные, в каком размере оплачиваются
3. Налоги (Вам должны перечислять дополнительные 6%, которые отдадите в налоговую)
4. Так как работодатель не платит за Вас отчисления в пенсионный и т.п. фонды - он экономит примерно 30% от Вашей зарплаты. Обычно в такой схеме предлагают зарплату чуть-чуть выше рынка. Плохо ли это? Решайте сами.

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

По поводу трудового кодекса и гарантий - могу рассказать немало историй про увольнение неугодных сотрудников одним днем. Из полностью белых компаний с официальным трудоустройством. И про отсутствие отпусков, и про отсутствие обещанных при трудоустройстве премий.

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

В общем, нравится работа - способ трудоустройства не слишком важен. Захотят кинуть - кинут в любом случае.

Можно сделать это через n (https://www.npmjs.com/package/n)

npm i n -g
sudo n 8.12

const arr = [
  {name: 'Василий', surname: 'Пупкин', lastName: 'Васильевич', contacts: Array(3), id: '1635409636499', …}
  {name: 'Денис', surname: 'Скворцов', lastName: 'Юрьевич', contacts: Array(3), id: '1635409753266', …}
  {name: 'Анастасия', surname: 'Волобуева', lastName: 'Андреевна', contacts: Array(3), id: '1635409776678', …}
  {name: 'Антон', surname: 'Козлов', lastName: 'Сергеевич', contacts: Array(3), id: '1635409790584', …}
  {name: 'Юлия', surname: 'Каюмова', lastName: 'Дмитриевна', contacts: Array(3), id: '1635409821938', …}
];

const newArray = arr.map(item => {
  return {
    ...item
    fullname: `${item.name} ${item.lastName} ${item.surname}`
  };
});

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

API разрабатывает бэк, но не по дизайну, а по аналитике от ТЗ.
Если есть только дизайн, то всё равно надо посадить аналитика который по пунктам распишет весь функционал. Иначе будет сказка про лебедя, рака и щуку. Страшная.

Далее разработка выглядит примерно так:

Параллельно:
Фронт начинает пилить визуальную часть без привязки к бэку.
Бэк исходя из аналитики думает архитектуру и кидает примерный json(а не точный свагер, лишняя трата времени).

Совместно:
Фронт смотрит этот json и если видит, что чего-то не хватает - запускает обсуждение с бэком.

Параллельно:
Бэк пилит по очереди сервисы\эндпоинты с автогенерацией свагера из кода.
Фронт пилит на основе простых json-моков из предыдущего шага и по готовности подключает эндпоинты с автогенерацией клиента из свагера.

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

P.S. Привязывать API к UI - безумие. UI - это мимолётная штука, как сумочка у дамы. Сегодня одна, завтра другая. API же опирается на архитектуру приложения, от которой зависит всё: и бизнес-логика, и тупо скорость работы, и многое другое.

Кто должен начать разрабатывать API: фронтенд или бекенд?

Совместно, исходя из требований.
Какие данные нужны для бизнес-процесса, и как эти данные будет использовать фронт.
Исходя из этого можно договориться об API.
Реализацией заниматься должны только бэкендеры

Конечно, есть Open API и Swagger которые прекрасно работают на небольших проектах. И вопрос, не в том, что Swagger плох, а его просто не удобно редактировать и поддерживать в будущем.

Большинство фреймворков умеют генерировать OpenAPI спецификацию по исходникам, либо наоборот - реализацию по спецификации.

Кто-нибудь видел Swagger в стиле Google Docs или Notion с доступом по ссылке?

Зачем в стиле гуглодоков, когда есть swaggerUI? А доступ по ссылке можно реализовать буквально в пару строчек.

Так же к Swagger хотелось бы фичу по привязке областей дизайна к API. Типа выделил область и сказал, тут вызывается /cities?q= и главное, всегда известно какие ендпойнты в какой части приложения дергаются.

Накидали небольшой скетч идеи. Что скажите? Может быть полезно?

Лично мне кажется, что это фича ради фичи.
Какие ендпоинты где дёргаются - это фронты и так хорошо знают.
Бэкендеру знать о том, как работает фронт не обязательно.
Дизайнеру также не нужно думать о деталях реализации.