Спробую більше деталізувати своє питання.

1. Є у тебе ХМЛ файл з контекстом. Як цей файл самий перший раз завантажити в AI? Просто у вигляді тексту ти йому кидаєш ХМЛ і даєш якусь інструкцію типу «це ось ХМЛ, коли я пишу ХМЛ селектори, то шукай в ньому»?

2. Ти просиш AI згенерувати тобі якийсь код. Воно ж генерує цей код прямо у чаті. Після цього тобі потрібно скопіювати шо воно нагенерувало і розкидати його по файлах на комп’ютері. Після того, як ти створив якийсь файл у себе на компі, потрібно ж якось оновити контекст для AI, щоб воно знало, що умовно для компонента А є папка src\components\A з файлами a1.ts, a2.ts, a3.ts. І мабуть же йому варто знати вміст цих файлів. Тут є пару питань:
а. чи додаєш ти в контекст вміст файлів? Якщо так, можеш навести приклад як це виглядає в твоєму ХМЛ. Якщо ні, то як AI розуміє де і що потрібно оновити в коді під якісь нові вимоги або для виправлення якихось помилок?
б. як потім оновити контекст для AI? Просто знову кидаєш йому сирий ХМЛ і кажеш, щоб воно вже шукало в ньому ХМЛ селектори?

Дякую за відповідь! А скажи ще, будь ласка, як «згодовувати» AI свій XML файл? Його ж потрібно постійно згодовувати, т.я. він постійно оновлюється. Просто типу завантажуєш йому файл з інструкцією накшталт «ось тобі ХМЛ файл, коли я пишу ХМЛ селектори, то шукай відповідності у цьому файлі»?

Привіт!
Я не дуже вловив ідею з xml і посиланням на певні вузли в ньому. Якщо не важко, ти би не міг цей момент трішки детальніше розкрити?

Як обирається БД.
В теорії. Аналізуємо доступні типи даних, що там по транзакціях, типи індексів, реплікації/шардинги, вартість обслуговування...
В житті. Хтось працював з Postgre? Ну то вирішили тоді.

Нічого кардинально нового для себе не дізнався, але стаття, як на мене, вийшла хороша. Були моменти, де можна було би подискутувати, але то мабуть суб’єктивні моменти. Автор молодець.

наприклад якщо у вас в команді купа JS розробників

Якщо в команді купа JS розробників, то вибір наче очевидний. Але у нас в команді не купа розробників JS, у нас в команді «інженери, що володіють кількома мовами програмування». Нехай це буде JS, Python, .NET, Java. Яку мову обрати для

невеличкий сервіс, або прототип MVP в якому нема heavy cpu utilisation

(з аргументами на користь кожної з мов, будь-ласка)

Допустим ми обрали, як ти сказав, node.js.

Далі вже можна прийняти рішення про масштабування цього сервісу в умовах реального життя — реалізувати на мові зі статичним рантаймом та/або багатопоточністю, канкаренсі etc.

Як ти приймаєш рішення, що треба щось переробити «на мові зі статичним рантаймом». Доречі, що таке «мова зі статичним рантаймом»?
Багатопоточність. Я не знаюся на ноді, але хіба не можна на ноді зробити «багатопоточну» обробку. «Багатопоточну» взяв у лапки, тому що навіть якщо сама нода однопоточна, то можна ж сам додаток змаштабувати до потрібної кількості екземплярів, або щось накшталт того.
Якщо сервіс великий, яку мову обрати (доречі, як зрозуміти великий сервіс чи ні)?

Звісно тут без фанатизму — бо неможливо гарно знати всі мови та рантайми

В мене не сходиться «повинен володіти кількома мовами програмування» і «неможливо гарно знати всі мови та рантайми». Який сенс в такому «володінні» мовами?

Я вважаю, що інженер повинен володіти кількома мовами програмування та вміти обирати відповідну залежно від задачі

Можеш, будь-ласка, навести приклади задач з аргументами на користь обраної мови?

В чому саме складність розробки?

Прямо зараз є проблема, яку я не можу вирішити нормальним (в мому розумінні нормальності) шляхом. Є запит, який повертає об’єкт Т. У моєму коді я повертаю IQueryable в методі. Маючи це, я можу використовувати where у цьому запиті і фільтрувати по властивостям об’єкта Т.

Також, у Т є властивість Х з кількома властивостями. Ця властивість Х заповнюється за допомогою DataLoader-а.

Що мені потрібно. Мені потрібно додати можливість задавати певний додатковий фільтр, зберігаючи можливість фільтрації, яка була до цього. Тобто додати в where додаткове MyFilter. Поля MyFilter в вихідному об’єкту Т немає. Це додаткове поле я сам повинен опрацювати в запиті і в DataLoader-і.

Проблема 1: як для цього конкретного запита розширити where, додавши туди своє поле зі своїми варіантами фільтрації (eq, neq) і як отримати його значення в методі запиту і дата лоадері?

Проблема 2: проблему 1 частково можна обійти, просто додавши вхідний параметр до методу запита. В такому випадку я можу опрацювати його і повернути потрібний IQueryable. Але наразі я не знаю як цей вхідний параметр я можу отримати в дата лоадері.

Дякую за статтю!
А можна якось подивитись що конкретно (який набір команд) виконується для того чи іншого SDK?

Перш за все дуже тобі дякую за те, що знайшов час зробити наглядний приклад!

Все, що буде сказано далі, це не критика, а лише мій суб’єктивний погляд і, вірогідно, не дуже добре концептуальне розуміння GQL як такого.
Не дивлячись на простий сценарій, для мене особисто код виглядає доволі складним і дуже багато (як для доволі простого сценарію) ручної роботи. Якщо нам потрібно якось більш гнучніше фільтрувати (по декільком полям, in, not in, >, <, contains, any...) або сортувати, я боюсь уявити у що перетвориться код. У запитах ти маєш сталий список колонок для вибору, що буде не зовсім ефективно. Ти вище писав:

Це можна оптимізувати. В HotChocolate є всі необхідні штуки для цього. Просто не хотілось ускладнювати реалізаацію.

Але ж трясця, це доволі простий сценарій, а нам стільки всього потрібно робити і так складно воно в результаті виглядає. І це саме те, що для мене означає «складність його розробки».

І можна ще пару питань, будь-ласка:

1. По структурі даних. Я хотів, щоб загальна кількість розширень була на рівні процесів, а Extensions був список об’єктів:
[ { id: 1, Name: word.exe, Count: 2, Extentions: [ { extension: doc, count: 1 }, { extension: docx, count: 1 } ] } ]
В твоему прикладі ти зробив трохи іншу структуру. В даному випадку може це і не сильно важливо, але тим не менше, якщо б потрібно було саме так, то можна було б це зробити наступним чином: отримуємо список вибраних полів для процеса (типу як ти це робиш в GetExtensions) і якщо там є кількість, то робимо відповідний запит і заповнюємо поле?

2. А можна якось отримати список полів, які ми вказуємо у стандартному where і у стандартному order? По типу як ти це робиш для вибраних полів?

3. Для GetExtensions резолвера ти визначив where параметр де можна задати поле filter, яке завжди працюе по eq. А як (чи можна?) зробити, щоб:
a) був стандартний фильтр where. Я пробував зробити щось таке:
public class ExtensionQueryNodeType : ObjectType<ExtensionQueryNode> {     protected override void Configure(IObjectTypeDescriptor<ExtensionQueryNode> descriptor)     {         descriptor.Field(o => o.Extensions).UseFiltering();         base.Configure(descriptor);     } }
Але чомусь .UseFiltering() метода тут немає. Хоча у мене в проекті таке використовується і працює.
b) поле filter працювало з варіантами eq, neq, in, nin?
c) був стандартний фильтр where + свій filter з варіантами eq, neq, in, nin?

Дякую! Я подивлюсь найближчим часом і потім ще відповім.

Я правильно тебе зрозумів, ти пропонуєш отримувати extenstions за допомогою DataLoader-а? Якщо так, то можеш, будь-ласка, додати деталей по наступним пунктам:
1. Не зовсім зрозумів твій SQL запит. Якщо ми говоримо про DataLoader для extensions, то він прийматимиме список ID процесів і на виході повертатимиме щось типу IReadOnlyDictionary<int, List<MyExtension>>, де ключом є ід процеса. Так от, що таке select count(*) as Count (перша строка запиту) в твоєму SQL запиті? Виглядає як Count на рівні процеса. Але нащо він нам в DataLoader-і для extensions?
2.

Додатково можна глянути що саме юзер вибрав із ExtentionsQueryNode і вирубати частину sql квері якщо вона не потрібна

Можна детальніше куди саме глянути і як саме вирубити?
3.

Ну і сортування тут можна запроста запихнути в inner select

Як в DataLoader-і отримати встановлене клієнтом сортування для extentions?
Давай так, потрібно підтримати наступний GQL запит:
query { processes( where: { extentions: { some: {} } } ) { count, extentions( where: {...}, order: {...}, take: 3, skip: 2 ) { extensions count } } }
Як таке зробити, якщо ми використовуємо DataLoader і щоб при цьому на SQL запит впливали встановленні фільтри, сортування, пагінація?

Такий приклад. Приклад не ідеальний, місцями не логічний, але нам важлива структура даних і як робити GQL запити на подібній структурі даних під певні вимоги.
Є у нас список якихось процесів: Id, Name. Є сторінка, де нам їх треба показати. Є GQL запит, який їх повертає у такому вигляді:
[ { id: 1, Name: "word.exe" }, { id: 2, Name: "openofficeword.exe" } ]

Для цього пишемо простенький запит через EF:
return context.Select(p => new Process{...});

Є у нас також список дозволених розширень файлів для процесу. Табличка БД має приблизно наступний вигляд: Id | ProcessId | Extension
І допустим в нас там є такі записи:
100, 1, doc
101, 1, docx
102, 2, doc
103, 2, docx

З’являється сторінка, де нам потрібно показати список типу такого: процес, кількість дозволених розширень.

Process, Extensions count
word.exe, 2
openofficeword.exe, 2

Також повинна бути опція показувати цей список в розгорнутому виді з розширеннями:

Process, Extensions count
word.exe, 2
doc, 1
docx, 1
openofficeword.exe, 2
doc, 1
docx, 1

Отже для нової сторінки нам потрібно повертати для різних сценаріїв наступний джсон:

Раз:
[ { id: 1, Name: word.exe, Count: 2 } ]

Два:
[ { id: 1, Name: word.exe, Count: 2, Extentions: [ { extension: doc, count: 1 }, { extension: docx, count: 1 } ] } ]

Також є наступні вимоги:
— фільтрувати по Extensions count. Наприклад: показати лише ті процеси, у яких загальний Extensions count > X; показати лише ті процеси всередині яких є розширення з count > X; показувати всередені лише розширення із заданого списку;
— сортувати по Extensions count. Сортувати процеси по count; сортувати розширення всередині процеса по count;

У мене є 2 вариінти як це можна зробити:
1. Розширити існуючий GQL запит (тип), додавши туда відповідні властивості та заповняти їх за допомогою DataLoader-ів. При цьому певно прийдеться самому реалізовувати щось для сортування та фільтрування. Не впевнений, що це можна реалізувати, тому що я такого взагалі не робив.
2. Створити новий GQL запит з іншим SQL запитом.

Другий варіант мені здається легшим в реалізації. В першому я просто не впевнений чи то взагалі вийде. Що би ви запропонували в такому випадку (3, 4 вариінта також можна пропонувать)?

Маю нагоду деякий час працювати з GQL зробленому з HotChocolate. Не виходить в мене полюбити GQL. Сам для себе досі не можу зрозуміти, коли варто було б обирати GQL для розробки АПІ, щоб дійсно отримати від цього помітну вигоду. Можу погодитись с автором, що можливо GQL допоможе зекономити за рахунок пропускної спроможності мережі. Але.

На прикладі з ролями, ми завжди виберемо з бази ід і ім’я, навіть якщо клієнт запитує лише ід або лише ім’я. Це можна було би вирішити, але в прикладі вище буде саме так. Інша проблема виникає якщо ми хочемо для поточного користувача отримати не всі ролі, а лише перші 3, ім’я яких починається з «adm». Не жорстко перші 3, ім’я яких починається з «adm», а з можливістю вказувати якийсь фільтр та сортування. Можливо і можна зробити, щоб при цьому генерувався відповідний оптимальний запит до БД, але я сходу навіть не знаю як. І приклад з ролями — це дуже простий приклад. Коли ваша бізнес логіка і структура даних складніша, запити до БД будуть неоптимальнішими і неоптимальнішими. Зрештою, неоптимальні запити до БД можуть невілювати економію на пропускній спроможності.

Інший мінус GQL (для мене) — складність його розробки і підтримки, порівнюючи с REST, значно вища в проектах складніших за хелоу ворлд. Робота з файлами там також певний біль.

Особисто мені зрозуміло, коли «просів» з початком війни. Було дійсно дуже багато невідомих, які впливали на всі аспекти життя. Було зрозуміло, коли «просів» восени та взимку 2022-2023. І роботодавці, які платили гроші попри це, дійсно заслуговують поваги. Але на 20й місяць війни твій «перформанс» повинен би стати нормальним (якщо ти не знаходишся поряд з лінією фронту). Але добре, люди різні, може хтось не може оговтатись і за 20 місяців.

Трохи інша ситуація. Весна 2023. Сидить дядько десь у Львові. В дядька «просідає перформанс». Місяць просідає, три просідає. Вже літо. «Перформанс просідає». Роботодавець такий «це ж зараз війна, важко людині, можливо вночі недосипає із-за постійних сирен, стрес, хвилювання, страждання». Наче ж не складно одне до другого додати і зробити висновок, що наврядчи ця «просадка» пов’язана з війною. Чи складно?

Питання перше: а чи дійсно просів перформанс?
Якщо відповідь на перше питання позитивна, тоді питання друге: а до війни такого явища, як працювати на двох роботах хіба не було? Але ж всеодно таких працівників тримають, жаліються що обкрадає та дурить, але ж тримають. Дивина та й годі.

Не знаю хто всі ці люди, які говорять про «обкрадає», «дурить», «недопрацьовує», але якщо вас, як роботодавців, щось не влаштовує, чого ви тримаєте таких співробітників? Чи договір з ФОПом не дозволяє припинити співпрацю?

Порада: ідеально, коли на одній з робіт не потрібно 100% вашої уваги. Це має бути стабільна робота зі сталими процесами та зрозумілими завданнями.

Дозвольте віддати вам честь, капітане.

І загалом я людина досить чесна, тому мені непросто морально приховувати додаткове навантаження.

Потрібно або труси вдіти, або хрестик зняти.

Дякую за статтю!
Було б цікаво про розшифровку TLS трафіка почитати. Не http трафіка (це, здається, Fiddler вміє без якихось додаткових зусиль), а сирого tcp, коли комунікація проходить по протоколу, відмінному від http.

Скоріше пішли просто нахєр