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

2. Обо мне
• Первую строчку JS написал в 1998 году
• Nodejs только вышел - делал R&D применимости. Верил в JS, когда еще никто не верил
• Свой аналог GraphQL сделал в 2009
• Верил в то, что фронт займет большую долю, чем слайдеры на JQuery
• Поэтому сделал фреймворк, где запросы к бизнес логике можно было делать из JS, из
микросервисов

3. Изучая и применяя
GraphQL,
чего вы хотите?

4. GraphQL. А в чем суть?
• Values? Декларируемые
• Экономия на байтах?
• понимание
• cost function
• N+1? Удобно? Кому?
• Выгодополучатели / Бенефициары?

5. «каждый кто скажет про не получать поля,
которые не запрашивал и он не работает в
Facebook, просто случайно попал в айти»

6. Выгоды простыми словами
Фронт +1 Бек -2 (не мои проблемы)
Реальный результат для average бизнеса -1
если у него нет бабла, чтобы это покрыть, я пойду работать к тем, у кого есть

7. почему кроме мира
js/mongodb не все
побежали делать graphql?

8. Важны ли вообще аргументы
бекендеров?
(GraphQL is a NIGHTMARE или просто ад)
+1 -2 = -1

9. А кто считал цену и ценность
этой технологии? Вот реально
взял калькулятор и посчитал?
да, да, неудобные вопросы

10. Бек и фронт
• а что его определяет? А что если все приложение в
SPA? Где бек?
• nodejs на беке
• ts, elm на фронте

11. Две культуры
разработки
не важно где бизнес логика - в беке или на фронте

12. Всегда ли бек и
фронт равны?
Оба ли могут быть важнее другого в части проектов?
Приложений, где море бизнес логики на беке и сотня
экранов на фронте в SPA - единицы.

13. Профессиональные отношения
• С кого бизнес спрашивает за ошибки в логике?
• Хочется делать мутации с фронта? А если это деньги,
документы, юридическая информация? Есть
готовность за это финансово отвечать? (Ой)
• Есть зрелые практики работы - покрытие тестами
всего кода? TS вместо JS хотя бы?

14. Зрелые практики
возможны и с JS
Но это скучно, не молодежно, не хайпово

15. Кросс функциональная
команда
Разделение вместо сотрудничества

16. Личные отношения
• Разные ценности личные
• Разная ментальность
• Разные критерии успеха с позиции бизнеса
• Кейс с аплодисментами
• УВАЖАЙТЕ ДРУГ ДРУГА

17. АРХИТЕКТУРА И
БАБЛО

18. Prisma raises $4.5M to
build the GraphQL data
layer for all databases
The upcoming Prisma 2.0 seems to combine Prisma Client and Prisma Server
and add an Admin UI feature. Making it a direct Hasura equivalent/competitor.

20. Hasura. The company
got $1.6 million in seed
funding in April.
“Our focus from the beginning has been making the
application development super fast.”

21. that’s the way that
business works
сила темной стороны огромна

22. А ты с какой
стороны денег?
А мы покупаем или продаем?
Измеримое влияние на TCO?
Какие бизнес преимущества?
«у меня все хорошо, мой дом в сайдбаре»

23. MVP круд приложенек
для инвестора?
• А что если то же самое можно получить проще? Что
если даже клиент об этом знает, а разработчики нет?
• Внезапно - Oracle APEX, XYZ?
• Low code! Цель не кодить, цель быстро получить
решение, ведь graphql про скорость разработки?

24. 1ая, 2ая и 3я космические
скорости
• Скорость выхода MV(!!!)P проекта на рынок
• Скорость разработки
• Скорость карьерного роста разработчика

25. Любая технология важна не сама по
себе. Сколько не ускоряй часть работы,
никого не интересует только часть.
+1 - 2 = -1

26. Бизнес устает от
разделения и no value
added code
Крупный бизнес делит (ради эффективности и там не забалуешь),
средний хочет фулстек (Lean, Kanban, Scrum - каждый по своему)

27. Карьерный рост
быстро
В компании никто не отрубает твоих недостатков.
Много требуют? Идешь туда, где требуют меньше,
а платят больше.
Не мешают расти карьерно.
Непрофессионалы сами.
Сами себе враги, а ты им в этом союзник

28. Профессиональный
рост быстро
все четко понимают твой уровень, на карьерный
рост еще пахать и пахать. Но помогают расти,
потому что более профессиональны.
От требования о повышении раньше, чем через 2
года в первый раз смеются, во второй увольняют

29. Анализ ценности GraphQL
с поэзии архитектуры
• functional correctness ?
• performance, scalability (на фронт можно вынести
нагрузку, но слабый grahql бекенд бьет) - +
• compatibility +
• usability ?
• reliability: - maturity - availability - fault
tolerance - recoverability -
• security -
• maintainability +

30. Темное прошлое
• МОСТЫ между беком и фронтом:
• HTTP
• AJAX
• WebSocket
• X Window - реверсная архитектура, когда gui - это
сервер, а бизнес логика в клиентах.
• MVVM Binder. Declarative (1 Vendor, растаскали, нет
полной поддержки, MVC не пошатнулся)

31. Rich фронт
Flash, Silverlight, jQuery слайдеры bells & whistles,
GMail (+ desktop notify), SPA (React etc)

32. Временно vs в нише
vs истинно
(широкая поддержка, переживет 10 лет)

33. • SOAP
• XML
• REST
• OPENAPI
• ODATA
• OTHER (gRPC, Protobuf, who cares?)
• Все это имело активный маркетинг и было идеальным (как GraphQL) решением для всех
проблем
• Кто-то думает что GraphQL просуществует вечно или в такой же позиции сияния в рассветных
лучах?
• Кто будет это legacy переписывать и как скоро?
По каким часам живем? Если по часам JS мира, то скоро.

34. Светлое будущее
• Светлое будущее у RICH фронтенда, а не у JS.
• AR интерфейсы, «как в кино» Так фронтенд это про JS
или про ФРОНТ - ЕНД и язык тут не при чем?
• Unreal Engine, C++ / BluePrint (hardcode / no code)

35. Сумерки
Риски. webasm. Chrome = IE, Smth new
(React VR - подстраховка)

36. Закат
Сначала важно быстро во что-то входить. Но отрасль становится
более зрелой и становится важна сумма опыта. А если все вчерашнее
отбрасывается, а не суммируется, то цена опыта - 0.
Ваше место займут другие люди

37. Пока GraphQL только
выбирает данные, рассвет
безоблачный. Но мутации...
Software Architecture

38. GraphQL - хорошо,
больше нет кусков
логики во фронте
А правда больше нет? Ни одной?
«I want to believe»

39. "You could implement a Workflow
on the client side -- have the UI
orchestrate all the necessary
basic commands"

40. А в чем проблема
иметь логику на
фронте?

41. Есть взрослые дома?
• А на нее (бизнес логику) есть тесты?
• Которые можно без браузера запустить?
• Она в идеальном порядке?
• Она не засунута в какой-то react компонент?
• (который MVC сам по себе, а в модели с Rx, Redux он
часть замороченной системы)
• Как вообще инициировать эту логику? Есть ли команда
или она по клику запускается?

42. Допустим…
• Есть страница и она показывает что решил сервер.
Может ли страница сама начать решать, что ей делать
и отправлять команды обратно на сервер?
• CRUD - это команды или нет? CQRS - command !=
p.title = x, p.save
• Ну, бывает… Dashboard - как и GraphQL - крути в
любой комбинации заданные элементы.

43. GraphQL - еще один rest,
openapi, больше свободы в
разработке, но ничего нового в
результате
Sorry, friends :(

44. Другой способ -
синхронизация данных
Например, CouchDB

45. Кто принимал решение
осознанно и взвесив
все альтернативы?
У кого хватало опыта для такого решения?
А кому мы верим?
КОМУ ВЫГОДНО?

46. недоCQRS
Anemic, через данные, а не через смыслы

47. Жизненный цикл
До релиза не трогаем бекенда
А после релиза?

48. Persisted query
а мы кажется начинали с другого? Перепутали
ЦА или интрумент?

49. Сложность задачи и
ценность инструмента
Кривые не сходятся
В начале не выгодно в разработке, потом

50. GraphQL - это взятие на себя
ответсвенности за бизнес
процессы, те и за бекенд

51. Лень и откладывание
проектирования на
потом
А мы покупаем или продаем?

52. Почему мы здесь
оказались?
Слишком много людей делает код, который не
доживает до продакшена

53. МЫ ПОКУПАЕМ
ИЛИ ПРОДАЕМ?

54. Есть два пути

55. Спасибо
Давайте уважать тех, кто покупает и кто за это все платит