Highload++ 2017 завершён!

Профессиональная конференция разработчиков высоконагруженных систем

СКОЛКОВО, Москва 7 и 8 ноября

11-я ежегодная конференция для разработчиков highload-систем, которая соберет   2 700 участников из разных регионов России и мира. Мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать многие тысячи и миллионы пользователей.

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

GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога
Архитектуры и масштабируемость

Доклад принят в Программу конференции
ecom.tech

Руководит разработкой направления мерчантских продуктов в компании Ecom.tech.
Более 20 лет посвятил веб-разработке, сделав более 100 различных сайтов. Например, делал сайт аэропорта Пулково в Санкт-Петербурге. Если приходилось сидеть там в ожидании рейса и прокручивать сайт, чтобы найти информацию — то вы уже взаимодействовали с работой Олега.
Работал в таких компаниях, как студия Лебедева, Яндекс.Деньги и Одноклассники. Писал код на C, PHP, Java, Kotlin. Приходилось работать даже с Internet Explorer 6, который в свое время был испытанием для любого разработчика. Знает, как запустить React в Java, хотя, если честно, не рекомендует пробовать это без подготовительного кофе. Об этом даже есть статья на Хабре.
В течение многих лет неоднократно выступал на различных мероприятиях, конференциях и воркшопах, делясь своим опытом и знаниями. Надеется, что его рассказы и сегодня принесут вам пользу.

Тезисы

Наверное, все слышали про GraphQL и задумывались о том, стоит или не стоит брать, а какие есть трудности его внедрения.


Я хочу честно сравнить GQL и OpenApi, показать, что GQL — это не какая-то магия и что это не панацея, а технология со своими плюсами и минусами. Я выведу повествование на рассказ о технологии Apollo Federation, чтобы на ее примере показать, где эффект от использования GQL в больших компаниях с большим количеством микросервисов и клиентов, вроде нашей, становится по-настоящему значимым за счет экономии на разработке сервисов гейтвеев и более развитом тулинге. Я покажу, как мы в итоге решили запускать экосистему GQL применительно к топологии наших сервисов.



Мы перед внедрением GQL много общались с ИБ и Эксплуатацией, и они проговорили нам набор проблем, без решения которых ехать в прод мы не смогли бы (ddos, overfetching, batch и пр.). Мы потратили время на то, чтобы найти решение этих проблем или осознать, как они решаются на уровне написания кода сами. И только когда все блокеры со стороны ИБ были закрыты, мы поехали в прод.

Я расскажу о каждом кейсе отдельно с объяснением того, что за проблема и как мы ее решали: как тюнили федерацию и CI/CD, как пилили ландшафт по продуктам, как делали загрузку файлов и пр
.

Фреймворки
,
API
,
Архитектуры / другое
,
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
,
Микросервисы

Другие доклады секции
Архитектуры и масштабируемость

Rambler's Top100