Я тож на саблайме сидел

Vscode

linux?

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

go install -i

linux?

Да, и там тоже работает

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

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

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

Вы зря так кипятитесь. См. postgrest. backendless решения доказали право своё на жизнь. Люди прекрасно себя чувствуют без всяких апи и костылей в виде этих ваших графкуэлей и свагеров

Вы зря так кипятитесь. См. postgrest. backendless решения доказали право своё на жизнь. Люди прекрасно себя чувствуют без всяких апи и костылей в виде этих ваших графкуэлей и свагеров

И где это живёт ?

Есть успешные известные реализации ?

кто пробовал запускать go-tdlib ? [ 1][t 1][1537212656.747661829][TdDb.cpp:381][!Td] Destroy bad sqlite db because of: [Error : 0 : Wrong key or database is corrupted] 2018/09/17 19:30:56 NewClient error: 0 disk I/O error

чтото не понятное

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

Я когда говорю про SQL, я не говорю про БД, а про интрерфейс. Можно например запрашивать данные из фейсбука посредством SQL запросов, или любые другие, только драйвер нужен, который обработает этот запрос. Любой GQL запрос, при условии что на бэке стоит реляционная БД, будет преобразован к SQL запросу, так что любой возможный запрос GQL будет мапиться в SQL, иначе это не имеет смысла. Я там выше писал, что возможно в "таблица" как ответ будет не самым лучшим вариантом, но никто и не говорил, что SQL должен описывать как именно должны быть представленны данные, а только их набор. Так вот если маппинг в итоге есть GQL -> SQL, логично ожидать, что кто-то не будет заморачиваться с еще одним языком, а прикрутит подмножество SQL. Лично я в этом случае более охотно его использую.

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

Да, так надо делать. Прям с фронта - и в общую базу. Make SQL injection great again

Я когда говорю про SQL, я не говорю про БД, а про интрерфейс. Можно например запрашивать данные из фейсбука посредством SQL запросов, или любые другие, только драйвер нужен, который обработает этот запрос. Любой GQL запрос, при условии что на бэке стоит реляционная БД, будет преобразован к SQL запросу, так что любой возможный запрос GQL будет мапиться в SQL, иначе это не имеет смысла. Я там выше писал, что возможно в "таблица" как ответ будет не самым лучшим вариантом, но никто и не говорил, что SQL должен описывать как именно должны быть представленны данные, а только их набор. Так вот если маппинг в итоге есть GQL -> SQL, логично ожидать, что кто-то не будет заморачиваться с еще одним языком, а прикрутит подмножество SQL. Лично я в этом случае более охотно его использую.

предлагаю эксперимент query { customer(id: "xyz") { friends(ageRange: 18_to_25) { name employer { name } } } } в SQL и с соответствующим парсером.

Вы зря так кипятитесь. См. postgrest. backendless решения доказали право своё на жизнь. Люди прекрасно себя чувствуют без всяких апи и костылей в виде этих ваших графкуэлей и свагеров

А как он проверяет что у пользователя есть права?

Да, так надо делать. Прям с фронта - и в общую базу. Make SQL injection great again

Коллега, вы отстали от жизни. В постгресте это всё более или менее решено

предлагаю эксперимент query { customer(id: "xyz") { friends(ageRange: 18_to_25) { name employer { name } } } } в SQL и с соответствующим парсером.

Так в этом нет никакой магии, вот эти движки, которые вы обсуждаете и занимаются тем, что парсят этот запрос и преобразуют его к виду SQL

Коллега, вы отстали от жизни. В постгресте это всё более или менее решено

они туда и GQL уже завезли?

Коллега, вы отстали от жизни. В постгресте это всё более или менее решено

Решено это в couchdb. Но чет мало кто готов на ней делат проекты

Так в этом нет никакой магии, вот эти движки, которые вы обсуждаете и занимаются тем, что парсят этот запрос и преобразуют его к виду SQL

нет, необязательно. У нас ArangoDB (AQL & graph) никакого RDBMS. как только вы напишите SQL запрос похожий на GQL query сверху, вот тогда поговорим

Я когда говорю про SQL, я не говорю про БД, а про интрерфейс. Можно например запрашивать данные из фейсбука посредством SQL запросов, или любые другие, только драйвер нужен, который обработает этот запрос. Любой GQL запрос, при условии что на бэке стоит реляционная БД, будет преобразован к SQL запросу, так что любой возможный запрос GQL будет мапиться в SQL, иначе это не имеет смысла. Я там выше писал, что возможно в "таблица" как ответ будет не самым лучшим вариантом, но никто и не говорил, что SQL должен описывать как именно должны быть представленны данные, а только их набор. Так вот если маппинг в итоге есть GQL -> SQL, логично ожидать, что кто-то не будет заморачиваться с еще одним языком, а прикрутит подмножество SQL. Лично я в этом случае более охотно его использую.

Оба решения имеют право на жизнь. От конкретного кейса зависит какое предпочтительней

А как он проверяет что у пользователя есть права?

Стандартно по jwt

кто пробовал запускать go-tdlib ? [ 1][t 1][1537212656.747661829][TdDb.cpp:381][!Td] Destroy bad sqlite db because of: [Error : 0 : Wrong key or database is corrupted] 2018/09/17 19:30:56 NewClient error: 0 disk I/O error

база-то не нулевая случайно?

да я пример main.go запускаю

нулевая или нет - кто ее знает

да я пример main.go запускаю

ну база испорченная. может прав нет на файловую систему?

посмотри

база создается во время первого запуска

./.tdlib/... и тд создаються запускаю в вагранте

Решено это в couchdb. Но чет мало кто готов на ней делат проекты

Ну о какой sql инъекции может идти речь, если сервер преобразует рест запросы в sql?

./.tdlib/... и тд создаються запускаю в вагранте

database/db.sqlite сколько весит?

-rw-r--r— 1 vagrant vagrant 3072 Sep 17 19:46 db.sqlite -rw-r--r— 1 vagrant vagrant 32768 Sep 17 19:46 db.sqlite-shm -rw-r--r— 1 vagrant vagrant 0 Sep 17 19:46 db.sqlite-wal

UseFileDatabase: true, // тут ставим false будет работать

они туда и GQL уже завезли?

Нет, но обещают завести

UseFileDatabase: true, // тут ставим false будет работать

ну копни в эту сторону. удали диру, запусти заново

:) первым делом попробовал, не понятно зачем там sqlite если и так вроде состояние сохраняет

:) первым делом попробовал, не понятно зачем там sqlite если и так вроде состояние сохраняет

после перезагрузки не сохранится состояние

Вы зря так кипятитесь. См. postgrest. backendless решения доказали право своё на жизнь. Люди прекрасно себя чувствуют без всяких апи и костылей в виде этих ваших графкуэлей и свагеров

а как он борется с underfetching'ом?

а как он борется с underfetching'ом?

Не готов ответить, я в данном случае не настоящий сварщик. Знаю лишь что меры принимаются

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

Вспомнил - meteor js, во. Фигня, но proof of concept

Не готов ответить, я в данном случае не настоящий сварщик. Знаю лишь что меры принимаются

учитывая что REST это RPC а RPC решает underfetching только способом добавления специализированных endpoint'ов - звучит не очень.

Ну судя по доке у них есть resource embedding

честно говоря я очень скептически отношусь к слиянию API и DB если endpoint только читает/записывает в бд то на первый взгляд кажется что зачем нужен API?! но потом если нужно реализовать... какие-то особенности в системе прав, посылку мыла вычисления обратную связь (server-side events) и т.д. и т.п. и всё это в бд? звучит слишком хаотично.

учитывая что REST это RPC а RPC решает underfetching только способом добавления специализированных endpoint'ов - звучит не очень.

Как я понял там на каждую вьюху генерятся автоматически ендпойнты соответствующие. Вьюхи докинуть до кучи не проблема. По этому скорее всего решение накидать вьюху на все случаи жизни. Я так думаю

после перезагрузки не сохранится состояние

а на новые сообщения есть возможность подписаться?

Как я понял там на каждую вьюху генерятся автоматически ендпойнты соответствующие. Вьюхи докинуть до кучи не проблема. По этому скорее всего решение накидать вьюху на все случаи жизни. Я так думаю

ну конечно, иного варианта нет, этим RPC собственно и не радует.

честно говоря я очень скептически отношусь к слиянию API и DB если endpoint только читает/записывает в бд то на первый взгляд кажется что зачем нужен API?! но потом если нужно реализовать... какие-то особенности в системе прав, посылку мыла вычисления обратную связь (server-side events) и т.д. и т.п. и всё это в бд? звучит слишком хаотично.

Pl sql +расширения решают

Pl sql +расширения решают

PI sql?

хранимые процедуры навека

PI sql?

Ну да, на нём логика же

а на новые сообщения есть возможность подписаться?

да, в ридми пример, если ты о моей либе говоришь

ох... ну делайте как хотите, но я таки за семантическое разделение хранения и обработки

ну конечно, иного варианта нет, этим RPC собственно и не радует.

Чем гря не вижу проблемы - закинул вьюху, все нужные ендпойнты сгенерировать, всё хорошо

да, в ридми пример, если ты о моей либе говоришь

updates.getChannelDifference вот такой запрос сделать, а то сейчас не видно что появилось новое сообщение, в канале к примеру или нет

ох... ну делайте как хотите, но я таки за семантическое разделение хранения и обработки

А я и не говорю что это решение на все случаи жизни. Мой пойнт в том, что не надо им пренебрегать

updates.getChannelDifference вот такой запрос сделать, а то сейчас не видно что появилось новое сообщение, в канале к примеру или нет

ты путаешь mtproto и tdlib. в tdlib нет такого метода. есть непрерывный стрим апдейтов, которые можешь фильтровать

ок, посмотрю что там есть

ок, посмотрю что там есть

в ридми пример

мне надо прочесть новые сообщения просто, смотрю как это сделать через tdlib

мне надо прочесть новые сообщения просто, смотрю как это сделать через tdlib

в ридми пример)

Чем гря не вижу проблемы - закинул вьюху, все нужные ендпойнты сгенерировать, всё хорошо

большой потенциал cross-request caching'а и batching'а на стороне сервера теряется. в GQL можно резолвить поля на loader'ы которые автоматом кэшируют и устраняют дубликаты и batch'ях запросы на бд насколько это производительнее сказать не могу, нет бенчмарков, но в теории это должно лучше распределять хаотичную нагрузку

А я и не говорю что это решение на все случаи жизни. Мой пойнт в том, что не надо им пренебрегать

Что лично мне импонирует в этом - можно взять двух трёх сиквелистов вместо роты рубистов-гошников)))

большой потенциал cross-request caching'а и batching'а на стороне сервера теряется. в GQL можно резолвить поля на loader'ы которые автоматом кэшируют и устраняют дубликаты и batch'ях запросы на бд насколько это производительнее сказать не могу, нет бенчмарков, но в теории это должно лучше распределять хаотичную нагрузку

Вполне возможно, но тут много вопросов без ответа

Что лично мне импонирует в этом - можно взять двух трёх сиквелистов вместо роты рубистов-гошников)))

однако по мере роста RPC интерфейса - растёт его семантическая сложность. s GQL она не растёт

У рест есть преимущество - проще в реализации, проще масштабировать

ERROR: S client not available

однако по мере роста RPC интерфейса - растёт его семантическая сложность. s GQL она не растёт

Не факт. Если база норм. организована и задачи не выходят за рамки применения РА, то может всё гладко меняться

Что лично мне импонирует в этом - можно взять двух трёх сиквелистов вместо роты рубистов-гошников)))

Потом они начнут писать на PL/Ruby и все вернётся к рельсам

У рест есть преимущество - проще в реализации, проще масштабировать

с одним таким маааленьким подтекстом: проще до определённого момента ? а чем его проще масшбатировать я честно говоря не понимаю

с одним таким маааленьким подтекстом: проще до определённого момента ? а чем его проще масшбатировать я честно говоря не понимаю

Есть endpoint которые можно разносить сколь угодно по разным серверам, nginx все разрулит

Есть endpoint которые можно разносить сколь угодно по разным серверам, nginx все разрулит

это называется load balancing, и возможно это как с REST так и с GQL

Только с рест проще

или ты про шардинг?

Только с рест проще

чем проще то?

Тем что все сводится к прописыванию нужных апстримов

Тем что все сводится к прописыванию нужных апстримов

хочешь сказать традиционный load balancing на GQL не распространяется?)

хочешь сказать традиционный load balancing на GQL не распространяется?)

Хочу сказать что с рест ты можешь выносить любой эндпоинт просто добавив пару строчек в нгинкс

Хочу сказать что с рест ты можешь выносить любой эндпоинт просто добавив пару строчек в нгинкс

зачем?

нагрузка? ставишь несколько инстансов GQL сервера и перед ними round-robin load balancer в чём сложность то?

нагрузка? ставишь несколько инстансов GQL сервера и перед ними round-robin load balancer в чём сложность то?

Есть разница между две копии всего приложения

И две копии одного эндпоинт

Ну и в целом есть разница между несколько инстансов всей аппы и масштабирования только самых нагруженных кусков

Ну и в целом есть разница между несколько инстансов всей аппы и масштабирования только самых нагруженных кусков

аа, т.е. запустить несколько копий одной API это сложнее, чем реализовать несколько разных HTTP серверов с разной логикой.. I see, I see..

аа, т.е. запустить несколько копий одной API это сложнее, чем реализовать несколько разных HTTP серверов с разной логикой.. I see, I see..

Смотри, нагрузка идёт на 10% всего апи, ты предлагаешь масштабировать путем поднятия инстансов всего апи, я предлагаю масштабировать только 10% апи

В случае с рест это просто добавить пару строчек в нгинкс

Смотри, нагрузка идёт на 10% всего апи, ты предлагаешь масштабировать путем поднятия инстансов всего апи, я предлагаю масштабировать только 10% апи

в чём разница то?))))) вызыватьсё то будут только те самые 10% просто на больший ряд машин))

Смотри, нагрузка идёт на 10% всего апи, ты предлагаешь масштабировать путем поднятия инстансов всего апи, я предлагаю масштабировать только 10% апи

вообще то о чём ты говоришь называется microservices ? когда ты шардишь своё приложение на независимые компоненты системы и добавляшь инстансов тому компоненту который больше всего нагружен. тут GQL и REST абсолютно не при чём..

в чём разница то?))))) вызыватьсё то будут только те самые 10% просто на больший ряд машин))

Разница в том, что в одном случае это небольшой кусок апи, который имеет свой uri и в реальной жизни сильно легче выделить то что тормозит, вынести это и разбираться с этим дальше

Разница в том, что в одном случае это небольшой кусок апи, который имеет свой uri и в реальной жизни сильно легче выделить то что тормозит, вынести это и разбираться с этим дальше

ещё раз, это называется микросервисы и никакого отношения к GQL/REST не имеет

вообще то о чём ты говоришь называется microservices ? когда ты шардишь своё приложение на независимые компоненты системы и добавляшь инстансов тому компоненту который больше всего нагружен. тут GQL и REST абсолютно не при чём..

Ну вот да не причём, микросервисы апи не имеют конечно же)))

микросервисы можно пилить как на GQL так и на REST..

И снова к началу)))

микросервисы можно пилить как на GQL так и на REST..

Или даже на postgrest

Да, можно

Можно и на grpc

Изначальный посыл был в том что рест имеет ряд преимуществ а именно более простая реализация и масштабироваться легче

короче: подытоживаю: GQL устраняет underfetching, но сложнее в реализации REST проще, но решение underfetching'а со временем приводит к полнейшему аду спец-endpoint'ов который окажется сложнее реализации GQL если вы со мной не согласны то переубедит вас только описанная проблема, с которой вы возможно рано или поздно столкнётесь. в любом случае я желаю вам удачи и спокойной ночи! ?

В том числе за счёт использования микросервисов, так как отдельный эндпоинт может быть хоть отдельным микросервисом хоть кластером таких микросервисов