Уже обуждали в чате неста, graphql и serverless говно связка

По крайней мере в текущей реализации serverless (она +- одинаковая у всех)

Ну и хй с ним)

Pavel за даклад 5+ очень понятно

Блин жаль что воркшопы без онлайна, или хотя бы записей

На сколько глубоко программист должен знать ту или иную технологию, чтобы успешно выполнять работу?! Вопрос общий, но как пример можно взять GraphQL. Заранее спасибо за ответы)

зависит от того что от него требуется, и чего он сам хочет достичь

А можно пожалуйста какие-то примеры, чтоб я хоть какое-то представление получил?

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

А что делать , если новому разработчику нужно пилить много новых фич в готовом проекте в монопере без тестов, основываясь на частях уже готового большого проекта? на готовой архитектуре. Без документаций и налаженных ci / cd процессах.

прислушиваться к тех/тим лиду и кодить в темпе тимы

Всем привет! Есть уже задефайненые в sequelize ORM схемы, можно ли их как-то частично переиспользовать в typeDefs для apollo-server-express ?

Можно если заюзаешь graphql-compose. Точнее если запилишь плагин graphql-compose-sequileze.

Который возьмет схему сиквалайза, пробежиться по полям и создаст необходимые graphql типы. Например я так для себя запилил https://github.com/graphql-compose/graphql-compose-mongoose

Готового я пока ничего не встречал. Найдешь - поделись ссылкой.

Но тебе прям должно быть очень больно (либо схема большая, либо часто меняется), чтоб заморочиться на такую штуку.

понял, спасибо большое что за быстрый ответ.

https://github.com/nodkz/graphql-compose тебе понадобиться для того, чтобы редактировать сгенерированные типы из ORM. Например, ты же не захочешь хэши паролей отдавать в схему. Или всякие там хитрые поля и данные, которые не должны быть на клиенте.

А удалять поля из типов и модифицировать их пока может только graphql-compose в мире NodeJS.

Ждал уведомление и понял, что видимо не дождусь) Цены у вас одни, а у бизнеса другие. В стеке React Native + AWS Amplify  один человек может поднимать стартапы создавая MVP, а это то, под что стартапам дают деньги. Поэтому какие цены и законодательство, если можно в  Штатах поднимать в разы больше)))

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

Понятно дело, Амазон грамотно разработал маркетинговую стратегию и отразил ее в ценообразовании.

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

Маркетинг тут дело десятое. У них хорошие цены, если в стартапе некому заниматься своим железом, ДЦ и прочими прелистями хостинга и администрирования.

Вот к примеру Дропбокс, перехал в свои ДЦ и на свое железо, когда стал получать по 2 ляма баксов в месяц от Амазона. А до этого было просто экономически нецелесообразно свою инфру поднимать.