Size: a a a

GraphQL — русскоговорящее сообщество

2019 July 13

D

Dmitry in GraphQL — русскоговорящее сообщество
Подскажите, кто-то юзал GraphQLScalarType в express-graphql. Что-то не заходит ни как.
источник

A

Artur in GraphQL — русскоговорящее сообщество
Pavel @nodkz
1. По вашему опыту, почему стоит изучать JS?

JavaScript в последние годы стал набирать безумные обороты.
На это была простая причина: клиенты стали более требовательны к скорости работы и отзывчивости интерфейсов. Ставя лайк посетители хотят сразу увидеть +1, а не ждать пол секунды пока сервер ответит. Нажал кнопку, моментально получил реакцию. И это можно сделать, если избавиться от сетевых задержек между сервером и клиентом - перенести исполняемый код, который дает результат максимально близко к клиенту, т.е. в его браузер. А в браузерах обосновался "старичек" JavaScript. Причем если лет 5-10 назад было стыдно говорить, что ты программируешь на JavaScript, т.к. его было сложно считать "удобным" и "производительный" языком. То после выхода ES6 "удобство" резко возрасло и продолжает рости благадоря работе комитета TC39 (куда входят куча спецов из больших компаний), который развивает сиснтаксис языка. "Производительность" языка постоянно увеличивается. Но благодаря большому комьюнити интересу больших интернет гигантов к языку, неклонно растет количетво инструментария, которые сильно облегчает разработку - eslint (проверка стайил гайда кода), prettier - автоформатирование кода, babel - для транспилинга кода и напиcанию всяких AST-трансформеров, JIT-компиляторов. Но что не может радовать, так это TypeScript, который позволяет писать статически типизированный код (Flowtype проиграл для меня войну). Статическая типизация, позволяет писать более стабильный и качественный код, дает плюшки автоподстановки в IDE. Вобщем корпоративный сектор все больше задач может доверить миру JavaScript. Современный джаваскрипт с классами, декораторами, интерфейсами, типизацией все больше и больше становится похожим на Java, в хорошем смысле этого слова. А если учесть, что JavaScript сейчас работает как на клиенте (в браузере), так и на сервере (NodeJS), то это это для бизнеса открывает возможность писать изоморфные приложения.

2. Будет ли этот язык востребован в будущем?

За пару лет популярность JS должна будет только вырасти. Ведь столько еще "ушлепских" интерфейсов вокруг, столько мертвых страниц сгенерированных сервером. JS будет теснить PHP и Ruby.

Так или иначе JavaScript еще будет востребован как минимум лет 10, дальше спрогнозировать сложно.

Что угрожает JavaScript/TypeScript:
- WebAssembly моячит на горизонте, но он пока еще незрелый. Если проблемы с доступным функционалом и инструментарием. Со временем он отберет часть задач на себя, но убить JS не сможет.
- Страшнее всего для JS разработчика, это если сменится способ потребления контента. Допустим мы откажемся от браузеров, перейдем на голосовых помощников, или нам вставят электрод в голову, или приклеят хитрую линзу на роговицу. Тут может оказаться, что JS будет не тем языком, который будет использоваться в этих каналах передачи информации. Хотя поживем, увидим.

В любом случаем надо постоянно учиться и развиваться, чтоб соответствовать текущему времени. Но к бабке не ходи, лет через 10 надо точно будет чему-то сильно переучиваться.

3. Каковы перспективы разработчика JS на рынке труда?

Сейчас есть некий перекос в сторону фронтенд разработчиков, который производят wow-эффект на клиентов. К примеру, на Украине сейчас активно ищутся React/Vue/Angular разработчики. И нередко зарплата таких фронтенд специалистов с опытом 1-2 года по зарплате соизмерима со среднестатистическим Java бэкендером с опытом 6-8 лет. Нужны легкие деньги после универа?! Вперед в JS!

4. Почему новичку стоит обратить внимание на JS

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

A

Artur in GraphQL — русскоговорящее сообщество
Pavel @nodkz
Как в эти буквы засунуть GraphQL? 🤣
Я не сильно компетентен в других языках, но мб graphql имеет большее комьюнити/экосистему именно в жиес мире, можно об этом сказать
источник

К

Кирилл in GraphQL — русскоговорящее сообщество
Pavel @nodkz
Как в эти буквы засунуть GraphQL? 🤣
GraphQL сейчас как концепция слишком сыр, но безумно расхайплен.
Такое было уже много раз в IT:
с NoSQL
с MVC
с <любой популярный сейчас JS фремворк>

Спустя время все эти технологии взрослеют и находят свою нишу. И хотя сейчас все начинают пропагандировать "волосатый" бэк API, потому что у всех проблемы с описанием потоков данных на странице, но это всего лишь маскировка проблемы.  
Достаточно взять концепцию RBAC. Как только нужно будет начать её реализовывать, то вся простота работы с данными с GraphQL сведется к станадртным REST решениям для работы с данными.
При этом так как GraphQL говорит о том, что строго контракта для получения данных нет, то в не элементарных приложениях, вы теряете "волосатость". Короче говоря ждем пока хайп пройдет.
источник

R

Ray in GraphQL — русскоговорящее сообщество
Dmitry
Подскажите, кто-то юзал GraphQLScalarType в express-graphql. Что-то не заходит ни как.
Привет) я использовал, делал скалярный тип Number  и Timestamp) А в чем именно проблема?может смогу помочь)
источник

D

Dmitry in GraphQL — русскоговорящее сообщество
Ray
Привет) я использовал, делал скалярный тип Number  и Timestamp) А в чем именно проблема?может смогу помочь)
Спасибо, уже разобрался.)))
источник

r

rtme in GraphQL — русскоговорящее сообщество
третюю неделю пытаюсь осилить фулстек на ноде и чем дальше в лес тем больше путаницы.

в качестве пациента сервис с ориентацией на мобильную аудиторию.

Сейчас на стадии когда нужно писать и получать данные с базы (в качестве базы mongoDB)

Скажем интерфейс сейчас генерирует данные которые уже надо сохранять в базу (фронт на vue + nuxt)

Тут не понятно сразу напрямую писать в базу или использовать api + будет несколько групп юзеров с разными привелегиями что тоже добавляет путаницы

В качестве api выбрал
graphQl + apollo (аргумент в пользу мобильных устройств)

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

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

Начинаешь гуглить получаешь ещё пачку новых фреймворков и зависимостей 🙈 каждый пишет на чём хочет и как хочет

сейчас видимо у меня сложность с пониманием взаимосвязей  api+база+юзер+привелегии и с чего начинается разработка этой части с таким стеком. полез в apollo ещё больше запутался.
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
Не используй монгу. Это первый совет. Postgresql
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
Лучше уверен на все сто.
источник

AD

Avaz Dev in GraphQL — русскоговорящее сообщество
Andrii Los
Не используй монгу. Это первый совет. Postgresql
+
источник

e

egoarka in GraphQL — русскоговорящее сообщество
Andrii Los
Не используй монгу. Это первый совет. Postgresql
что за совет такой, что с монгой не так
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
Да 90% задач
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
Для*
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
С ней все в порядке, только она предназначена для узких кейсов.
источник

e

egoarka in GraphQL — русскоговорящее сообщество
например?

атомарность и транзакции уже появились
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
И брать её вместо реляционной базы - днище.

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

AL

Andrii Los in GraphQL — русскоговорящее сообщество
И ничего удобнее SQL, или как минимум, знакомее, чем SQL нет на свете пожалуй. А в монге сразу же будет либо избыточность, либо инконсистентность, либо костыль и хранение нормальных данных в базе, в которой это не особо предусматривается.
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
Всякие костыли сейчас для этого конечно предлагают, но в 95% случаев всем понятный postgres + JSON fields хватает с головой.
источник

AL

Andrii Los in GraphQL — русскоговорящее сообщество
Да и перф отличный и специалистов вагон.
источник

e

egoarka in GraphQL — русскоговорящее сообщество
что-то весомых аргументов не видно
источник