1. для проекта уровня "интернет магазин"  будет  "ок" юзать express для апишки или лучше на чистой ноде сделать?
2. стоит ли человека, который не трогал TS садить изучать loopback и TS?

Зависит от размера интернет магазина

Почему не нест? :)

А личное предпочтение чему отдаете для апишек? (если речь идет о JS)

зависит от задач

https://medium.com/@onufrienkos/express-vs-fastify-performance-4dd5d73e08e2#:~:text=Fastify%20is%20around%2020%25%20faster,just%20out%20of%20the%20box.

Имхо я бы апишки не писал на js.

1. в 99% случаев тормозить будет БД
2. fastify очень огорчает в отдельных аспектах DX :)

3. Если вы гонитесь за попугаями - надо брать uwebsockets :)

Я не то чтобы "бурчу", но в таких вот вопросах всё js(node.js) сообщество. Как мне кажется проект уровня "интернет-магазин" требует хорошего планирования и проектирования. И так же не помешают некие правила по организации кодовой базы. Если вы напишете его на "чистой ноде" или express (что почти одно и тоже) то через пол года поддерживать и расширять написанное будет сложновато. Конечно же это лишь моё мнение и многое будет зависеть от уровня разработчиков. Но сколько мне не встречалось проектов на express - это был каждый раз ноый велосипед.

В таких случая мне кажется вполне резонным брать решения которые будут диктовать некие правила и хотя бы в документации описывать хорошие подходы к реализации кода. Тот же предложенный Ильёй nest вполне себе подходит (и loppback мне кажется тоже, но порог входа там повыше)

А по поводу TS - всё зависит от уровня программиста.

скажем так - не имея опыта (судя по вопросу) написать масштабируемую архитектуру на fastify/express в разы сложнее чем на nest/loopback

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

Слово рельсы вызывает у меня кровавые слёзы

из-за магии )

ну, ведь всегда есть общие момент, вроде авторизации, проверки прав, валидацции данных и т.д. Уверен что кто-то это набил кучу шишек и давно придумал формулу как правильно варить это дело. "Мол вот так рекомендую для всех" (или почти всех)

честно - почти что я видел все очень problematic

Из опыта работы в ecomerce могу сказать уверенно - для им нет лучших практик! Начиная от модели хранения данных, заканчивая архитектурой. Про апи все же могу сказать что лучше смотреть в сторону других языков. Например go.

Мне кажется наиболее важны "глобальные лучшие практики" типа архитектуры проекта, написать поддерживаемый и расширяемый продукт, продумать взаимодействие сервисов, потоки данных. А конкретные для магазинов, или е-commerce или ещё чего либо это лишь частные случаи.

Я имел ввиду про другое, но с "глобальные лучшие практики" соглашусь

Какие киллер-фичи предоставит Go для API?
(я не троллю)

Я понимаю какие фичи готовы предоставить Python/Ruby/PHP/Java/.Net - зрелые фреймворки вида Django/RoR/Symfony-Laravel/Spring/ASP.NET MVC и т.д. где на 90% вопросов уже есть готовый ответ

В случае с Go я на горизонте не вижу подобных решений