Может кому будет интересно для развития.
Недавно по работе столкнулся с таким зверем как GraphQL. Занимательная скажу вам штука и очень интересная замена REST. Даже возникла мысль написать что-то подобное под сам Salesforce. И только подумал - бац. Наткнулся на готовое решение.
Кстати изначально хотел поделиться ссылкой на сам сайт https://www.apexhours.com. Очень интересные статьи на данном ресурсе!
Отличный доклад про опыт использования GraphQL
Рекоммендую послушать еще альтернативное мнение https://radio-t.com/p/2020/12/12/podcast-732/
Никогда не любил это радио-Т но чисто из любопытства прослушал до конца раздел про GraphQL.
И ничего кроме у кого писька больше не услышал. Может это формат такой, но мне не заходит. Ничего кроме перетягивания одеяла, плюс хейт в сторону фронтендщиков постоянный (там одни бэкендщики собрались - белая кость). Короче бред, слушать не рекомендую, полезной инфы ноль, только время потратить.
А за GraphQL поясню тоже, но уже с точки зрения full-stack разраба который любит frontend тоже 
.
Мне GraphQL зашел. Вот типичная ситуация при разработке обычного Web App с тем же Ангуляром на фронте. Тебе нужна инфа с бэкенда - ты идешь на бэкенд и делаешь там новый REST endpoint где собираешь данные и возвращаешь в json на фронт. Кажется не сложно, но надо каждый раз придумывать url для endpoint, править router, делать handler где разбирать и валидировать входные данные. Мрак. И про то что есть всякие best practices и стандарты RESTfull именования эндпоинтов можно забыть. Оно есть в теории, а как начинаешь кодить как там только не начинаешь извращаться. Хорошо если ты все пилишь в одно лице, а когда у тебя отдельный бэкендшик, а ты фронтендщик вот тут начинается реальное мракобесие - каждый эндпоинт дается с огромной болью. РЕАЛЬНЫЙ ПРИМЕР - был у меня один проект где я был чисто фронтендщиком и мне поставил задачу запилить админ панель для работы с логами одного приложения. Так вот мне дали всего ОДИН ендпоинт который умел делать search по критериям и возвращал результаты в каком-то странном формате не подходящем для анализа вообще. Но добиться чего-то вразумительного от бэкендщиков было совсем сложно - ответ "там вся инфа есть, сам разбирайся". А итоге путем различных вариантов поиска, группировки данных из ответа, сортировки, анализа пришли данные из одной группы или многих получилось сделать прекраснейший тул от которого все в восторге. Но по уму все эти "вариантов поиска, группировки данных из ответа, сортировки, анализа пришли данные из одной группы" нужно было делать на бэкенде и отдавать разными эндпоинтами типа list, details.
Так вот GraphQL и призван решать такие проблемы как я описал. Был бы GraphQL на этом проекте что я описал, то бэкендщик должен был только описать данные (которые он мне тупо скидывал в raw виде) как resource. А я уже путем составления нужных мне GraphQL Query доставал только то что мне надо и в том формате который мне нужен.
Что я увидел в GraphQL:
- избавление то endoint URLs hell
- валидация входящих данных из коробки
- документация из коробки. Причет описание метадаты можно достать через обычный query (SF разрабы понимают как полезно уметь доставать и использовать метадату на примере тех же SObject когда надо что-то делать динамически)
- фронтед сам решает какие данные нужно вернуть (если появились новые поля не надо просить бэкенд добавить их в REST обработчик)
- возможность послать несколько query в одном запросе
- возможность запросить любой уровень вложенности ресурсов и фильтрами по ним.
И вся эта мощь появляется стоит лишь правильно один раз описать GraphQL ресурсы на бэкенде.
Из минусов, которые можно услышать если смотреть нормальные доклады а не детский сад из радио-Т
- разграничение права доступа к ресурсам. С REST все просто - дал доступ к endpoint только пользователям с нужными правами и все. В GraphQL я пока не вникал как например разграничить доступ к некоторым Resouces и Fields для Regular/Admin пользователей.
- из коробки GraphQL позволяет создавать сколь угодно сложные запросы и это может тупо положить ресурс по лимитам. Для этого надо внедрять какой-то предварительный анализ входящего запроса (уровни вложенности к примеру или что посерьезнее).
- ну и проблема N+1 запросов если вы к примеру запросили Account + его Contacts. Тоже решается путем внедрения более сложных обработчиков для ресурсов.
И расскажу про мой положительный опыт использования GraphQL. Опять же с точки зрения Frohfphf разраба.
У нас есть проект который работает с базой типа бэкапа Salesforce. И в случае каких-то трабл инвестигейшенов надо тупо идти в базу с помощью какого-нибудь DB клиента и смотреть все ручками или SQL запросами. И это реальная попа-боль. У нас нет Standard Layouts как в Salesforce, а вместо SOQL references у нас JOINs (которые я бля так и не могу до сих пор написать по памяти).
Была поставлена задача запилить что-то типа Standard List Layout + Standard Layout как в SF только на Ангуляре. Сперва думал решить это дело с помощью составления динамических SQL но благо посоветовали глянуть на GraphQL. И это было просто чудо. Единственный затык был с правильным описанием resources на основе базы данных, но и тут оказывается все придумано до нас. В итоге весь код занял от силы несколько десяток строк (правда с некоторыми хаками которые пришлось долго гуглить и отлаживать). И вся работа перенеслась на frontend. Но и там ничего сложного. GraphQL возвращает метадату всех ресурсов которые он может вернуть. На основании этой метадаты генерится не сложный GraphQL Query который сразу может вернуть массив записей определенного ресурса с выбранными полями и дальше фронт строит таблицу или запрашивает ресурс по ID со всеми полями и related объектами и строит record view с правильным отображением полей по типам (даже с работающими lookups) и related lists.
Все как в любимом SF. Кодинга практически 0. GraphQL сохранил наверное 70% времени потому что мои прогнозы по работе с динамическими SQL были совсем не оптимистичные.
Конечно такой GraphQL ендпоинт скорее для внутренних нужд и отдавать его клиентам я бы побоялся (хрен его знает что они за запрос могут составить (это касается минусов из предыдущего сообщения)), но в компании уже ходят мысли сделать GraphQL эндпоинт для клиентов публичным.
Я что-то потерялся. Что за проблемы? У меня 1 endpoint. Клиент сам запрашивает какие поля он хочет получает правда всегда одну и туже структуру. Этот же endpoint обрабатывает и metadata естетвенно структура возвтращается другая, отладка уже добавлена в протокол общения. Ни разу не использовал GraphQL, может он и крут, не знаю.
А мы не про Salesforce сейчас.
В Salesforce я бы такое быстро запилил. Даже с 0 enpoint (я про кастом). Хватило бы просто API.
А вот когда у тебя голый Postgres?
Ты ж не забывай что я уже 3 года на другой стороне барикад. Пишу в "Интеграции со сторонними сервисами", но наверное даже эта тема не подходит. Сейчас перепиливаю потиху форум на новый движек, как запущу сделаю отдельные для себя ветку "Совсем не Salesforce" чтобы не смущать.
Для Salesforce соглашусь что GraphQL штука избыточная со всем его API. НО я уже замечал что в SF разрабы уже на каких-то проектах используют какую-то APEX либу под GraphQL.
А так то проблем нет, просто изучаем новые технологии. Если писать только когда проблемы, то и писать то никто не будет, только начинающие про тестовое задание и будут писать
Ахахаха! Блин. сам же в первом сообщении написал про GraphQL + Salesforce и про либу, и уже забыл.
Блин, совсем голова уже не варит - Старею 
. Тут технологии и темы с такой скоростью проносятся, что Salesforce уже выглядит как очередная тула изученная на выходных
