я хотел сказать что не вижу в растовой либе поддержки этого

Кто нибудь сталкивался с ошибкой пакета "sql" too many SQL variables ? в моём случае - овер 1000. Хотелось бы понять - а сколько можно по максимуму?

проблема со специализированными endpoint'ами в tight-coupling'е. Т.е. как только меняются требования клиента (например дизайн изменили, теперь на дашборде оборажается X,Y,Z а не как прежде Y,M,C,A) - нужно переписывать backend для оптимизации, и так постоянно... а что если у вас не один клиент ещё в добавок? RPC очень быстро может превратиться в maintenance катастрофу. Из-за этого и появились раньше такие вещи как SQL, которые позволили решать разные проблемы не переписывая имплементацию бд.. с GQL теперь происходит подобное но уже на уровне API и в виде графа

все протоколы, начиная со второго, отдаются по эндпойнтам с префиксом /vN/, где N - номер версии. и все тип-топ, старые клиенты забирают то, что надо, новые - то чно хотят.

а?!

Эх... Может sql напрямую передавать :) наверное этим все и кончится :)

это уже было

Где? В толстых клиентах?

Эх... Может sql напрямую передавать :) наверное этим все и кончится :)

нет, нет и ещё раз нет. Только в том случае если совсем поехала кукушка

Зачем какой-то новый язык запрос изобретать.

гугли AES

Если тема пройдет в массы, этим и должно будет все закончится. Как по мне, это самый логичный способ. Ну может не табличку отдавать, а может и табличку, но не одну... Но sql отличный язык для этого.

а я бы советовал ассиметричное шифрование

а я бы советовал ассиметричное шифрование

SPARQL - вот где следующее будущее, а вы все GRAPHQL... можно немного тут почитать https://habr.com/post/309448/

коллега, вы спятили? извиняюсь за дурной тон, но отдавать базу в сеть это неимоверный нонсенс, это просто верх маразма, мне даже лень вам объянять это потому-что это должно быть очевидным. API уровень существует не ради того чтобы потратить лишнее время программиста, а ради того чтоб защитить бд от возможных опасностей и сделать её более доступной для приложения

как мне это надоело, а?.. про задачу ни одного вопроса не задали, но уже оптимизировали по параметру "производительность".

а кто-то уже пробовал graphql внедрять?

как мне это надоело, а?.. про задачу ни одного вопроса не задали, но уже оптимизировали по параметру "производительность".

ну мы пробовали

Чувак ничего не конкретизировал что ему требуется от шифрования, а ему уже предложили более сложное и с кучей мест, где можно потенциально наебаться шифрование.

и чем он лучше GrahpQL? они хоть из одной и той-же лиги то?

какой клиент использовали? apollo, relay-classic, relay-modern?

Ты меня не понял, начнем с этого. Мы и так отдаем базу клиенту, только интерфейсом у нас rest или граф. Sql это такой же интерфейс. Никто не говорит что его нужно выполнять напрямую с клиента, но они отлично может подойти для описания запросов.

коллега, вы просто безграмотны, похоже. как вы собираетесь ключами обменяться для симметричного шифрования?

человек сам поймёт когда ему нужно ассиметричное шифрование, в любом другом случае всегда стоит использовать AES

Обменивался при личной встрече на флэшке один раз в жизни

apollo

вы вместе с Романом работаете?

чушь. выбор симметричного шифрования тянет за собой столько всего, что ассиметричное и проще, и быстрее, и надежнее

нет, это ответ от моего опыта внедрения

какой клиент использовали? apollo, relay-classic, relay-modern?

а можете поделиться почему apollo выиграл у relay-modern?

честно? никакой. просто plain string query. это у нас ещё нерешённый вопрос с кэшированием (по сути клиент нужен только для этого) выше перечисленные клиенты требуют соответствующие серверные имплементации, которые мы не юзаем

чушь. выбор симметричного шифрования тянет за собой столько всего, что ассиметричное и проще, и быстрее, и надежнее

с relay-modern не сравнивал. Выбирал больше года назад - тогда видимо существовал тот relay, который стал classic. По сравнению с ним более гибкий, бесшовно интегрируемый в реакт-проекты, большое кол-во статей

ассиметричное? быстрее и проще и надёжнее? т.е. плевать на то что ECDH и RSA ломаются алгоритмом Shor'а на квантовом процессоре? плевать на то что ECDH и RSA не ускоряются на уровне железа? и то что ассиметрия с private public key проще это вообще нонсенс... помню лицо коллеги, когда я в 18 лет отдал ему private key на запрос дать ему мой ключ... я тогда ещё шифрование вообще не понимал в то время как симметричное было вполне для меня интуитивным, мол есть ключ, им открывается и закрывается..

Чушь

какое кэширование нужно?

а что на бекенде было у вас?

client-side caching

го. мы на самом деле с тобой год назад общались на эту же тему, и ответы были те же

какое кэширование нужно?

мы отдаём не базу, а данные, не путайте эти слова. нет, SQL это не такой же интерфейс как REST или GQL. Учите мат-часть, коллега

по-моему там вообще с этим все хорошо

Мелко мыслишь. Матчасть я уже больше забыл, чем ты изучал. Думаю на этом можно закончить обсуждение.

А вообще - у меня есть доклад про разработку шифропротокола на базе AES На английском, правда

я вижу как вы её изучали, SQL от GQL отличить не можете)) да, завершаем этот бесполезный "спор"

цитирую FlacheQL offers partial retrieval of cached data based on search parameters — a feature that no other GraphQL library offers. Larger implementations like Apollo and Relay can only cache data based on GraphQL query fields.

Есть ощущение что вы не знаете что такое sql

окей. но это не требует серверных решений.

помоему нет, но я ещё не успел сию тему изучить, надо будет как нибудь с ней поиграться

да и что-то проект вроде затих - коммитов нет

у меня скорее ощущение что люди не знают GQL и наивно сравнивают его с SQL, хотя это вещи совершенно разные. нет, SQL не лучше GQL для API, начиная с того что моделирование взаимосвязей в SQL с помощью JOIN'ов и foreign ключей это боль... грубо говоря: SQL vs GQL == tables vs graph // true

если бы оно было быстрее то мы бы не парились с key-exchange в HTTPS, просто бы шифровали всё в RSA/ECDH... но нет... зачем-то понадобился им AES... не потому-ли что он а) быстрее б) имплементировал в железе инструкциями типа AES-NI?

Причём тут сравнение gql vs sql?

Опять вы производительность оптимизируете?

а ты наверх полистай, там человек утверждал мол зачем GQL если есть SQL

Мне это зачем? Я сказал, что судя по твоим высказывания ты не знаешь, что такое sql. И причём здесь gql и человек что то утверждающий? Хотя я подобных утверждений не видел, скорее это твоя трактовка

Помогите. Использовал Sublime, стоял GoSublime, Потом перестал работать автокомплит. GOPATH по советам в интернете вроде поставил, но ничего не поменялось.

"вы пробовали выключить и снова включить"? переустанови))

по каким высказываниям то?)) ну что-за обвинения такие)))