По мере того как наш программный бизнес углублялся в экосистему GraphQL API, мы попутно переняли несколько ценных передовых практик. Язык запросов с открытым исходным кодом — это будущее API, но чтобы заставить его работать (и масштабироваться), требуется определенная стратегия.
В сочетании с устаревшей технологией REST API GraphQL обеспечивает преобразующие преимущества, позволяя приложениям собирать все необходимые данные с помощью одного запроса API и напрямую управлять этими данными, не полагаясь на подключение к серверу.
Эти ключевые различия позволяют группам разработчиков создавать более стабильные приложения, причем делать это быстрее и с меньшими трудностями. Организации, использующие GraphQL, могут значительно улучшить качество как своих приложений, так и опыта разработчиков (что могут подтвердить наши собственные разработчики).
Но внедрение GraphQL имеет несколько подводных камней, которые могут привести к тому, что реализации не достигнут своих целей. А именно, масштабируемость, видимость и безопасность GraphQL не заданы. Они требуют хорошо продуманных стратегий, соответствующих современной передовой практике.
Вот что мы узнали. Эти стратегии должны помочь сделать ваш путь модернизации API GraphQL более плавным.
Поддержка масштабируемости GraphQL с самого начала
Хотя GraphQL достаточно прост, чтобы несколько разработчиков могли быстро запустить сервер, создание стабильной и масштабируемой реализации, которая потребуется вашей компании для раскрытия его больших преимуществ, требует больше инвестиций. Крайне важно, чтобы руководство полностью поддержало внедрение GraphQL, в идеале с первого дня.
С GraphQL все будет проще, если вы все сделаете правильно с первого раза. Многие компании совершают стратегическую ошибку, позволяя GraphQL разрастаться внутри своих организаций, в результате чего он практически не поддерживается и плохо защищен. Некоторые заинтересованные стороны неизбежно поверят, что, если развертывание GraphQL еще не масштабировано, оно еще не требует поддержки корпоративного уровня. Однако с точки зрения эксплуатации и безопасности такой подход означает, что GraphQL останется технологическим форпостом, которым владеет горстка разработчиков и который уязвим для проблем с производительностью и нежелательных проникновений.
Когда использование GraphQL действительно превышает тот порог, который имеют в виду эти стратеги, и приходит время привести развертывания уже существующих GraphQL в соответствие с лучшими практиками, команды обнаруживают, что отмена этих плохих фундаментальных решений — это все равно, что выбирать изюм из полностью испеченного пирога. Слишком распространенный пример: разработчики, действующие непредусмотрительно, часто из соображений удобства жестко запрограммировали элементы управления доступом на серверах и преобразователях GraphQL. Это снижает производительность и безопасность в масштабе, пока команды не вернутся и тщательно не удалят этот код.
Гораздо лучшая стратегия — полностью посвятить себя GraphQL и правильно реализовать его с самого начала. Представление новой среды GraphQL, основанной на лучших практиках, — это подарок для вашей будущей организации. Его легче эксплуатировать и обеспечивать безопасность как сейчас, так и в будущем, он приносит немедленные дивиденды за усилия, а также значительно упрощает и ускоряет масштабирование и достижение целей дорожной карты.
Поддержка GraphQL с помощью глубокой аналитики
Организации совершают ошибку, объединяя традиционный мониторинг с GraphQL: стандартные подходы упускают ценную информацию о запросах и бизнес-аналитику. Инструменты, адаптированные к поведению, специфичному для GraphQL, необходимы для сбора глубокой аналитики и столь же глубокого понимания состояния сервера и проблем, возникающих на уровне запросов.
Если ваша организация внедрила GraphQL, но еще не внедрила эффективные инструменты визуализации, вы боретесь со временем, чтобы сделать это, прежде чем ваша реализация масштабируется и будет полагаться на интегрированный граф. При использовании объединенного графа API предоставляют единый граф данных, который объединяет (и скрывает) несколько подграфов.
Платформенные команды, оснащенные только традиционными инструментами, не смогут понять, какой подграф с каким трафиком связан. Проблемы с производительностью и нерациональное использование ресурсов станут очень сложными для решения, поскольку они скрыты за этой федеративной архитектурой. Вот почему крайне важно обеспечить полную видимость ресурсов, данных и рабочих нагрузок GraphQL в рамках развертывания вашей организации — если это возможно, с самого начала.
Иметь стратегию безопасности, специфичную для GraphQL.
GraphQL имеет собственный профиль безопасности и требует подхода к безопасности, способного нейтрализовать угрозы, специально разработанные для использования уязвимостей GraphQL. Организации, которые полагаются на традиционные API и шлюзы веб-приложений, не могут эффективно защитить код API, выявить аномалии трафика, которые могут представлять собой угрозу, или обеспечить безопасный и эффективный контроль доступа. Чтобы защитить GraphQL, организации должен вместо этого используйте современные методы, способные обнаруживать трафик GraphQL и обеспечивающие глубокую видимость, позволяющую принимать меры безопасности в режиме реального времени.
Я приведу пример инцидента безопасности, с которым мы недавно столкнулись. В последние выходные мы получили предупреждение о том, что через наш слой GraphQL проходит аномально большой объем запросов. К счастью, до этого инцидента мы развернули платформу управления Inigo GraphQL для защиты наших рабочих серверов GraphQL. Мы использовали наши показатели мониторинга производительности приложений (APM), чтобы определить временной диапазон и решить проблему обслуживания рассматриваемой нагрузки. С помощью инструментов безопасности и аналитики Inigo мы смогли идентифицировать пользователя и рабочее пространство, вызывающее трафик.
«Угроза» оказалась законным пользователем, что заставило всех нас вздохнуть с облегчением. Это мероприятие также оказалось ценным для выявления части нашего приложения, нуждающейся в оптимизации. Однако без нашей стратегии безопасности, специфичной для GraphQL, у нас не было бы возможности понять, какого пользователя затронула эта проблема, или как решить ее столь решительно.
Убедитесь, что все находятся на одной волне
В организациях, внедряющих GraphQL, разработчикам слишком легко оказаться впереди всех в реализации преимуществ GraphQL, но некоторым заинтересованным сторонам приходится тормозить, когда дело доходит до внедрения надлежащей поддержки корпоративного уровня. Сторонники GraphQL в вашей организации должны учитывать эти тенденции и сплотить более широкую команду, чтобы двигаться вперед как единое целое.
Поддержка недавно развернутой реализации GraphQL с помощью правильных стратегий и лучших практик открывает огромный потенциал для повышения операционной эффективности и ведущего опыта разработчиков. Рецепт успеха модернизации API — внедрение индивидуального управления, аналитики и безопасности наряду с развертыванием GraphQL.
Уилл Гуэдес — соучредитель и технический директор компании разбросанныйкоторая предоставляет малым предприятиям, предоставляющим услуги, программные инструменты для бронирования клиентов, CRM, платежей и многого другого.
—
Форум новых технологий предоставляет место для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор является субъективным и основан на выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговую информацию для публикации и оставляет за собой право редактировать весь предоставленный контент. Все вопросы отправляйте по адресу newtechforum@infoworld.com.
