да!

Тоже не красиво. ((

ты, наверное, не изучал Pascal, Modula, ADA и все такое... :) Там принято так и делать, по сути

Я как раз с паскаля на Go перешёл. В паскале исключения.

конечно, все это скучно и не интересно делать.

Наверное, за это Go и называет хипсерским язычком, что хипстеры одни, которые ошибок не делают :)

Кстати, сам великий Роб считерил, и в встроенной функции append используется дженерикоподобный синтаксис ?

Вместо appendString, appendBool

Андрей, ну, тут просто Роб решил в языке этого не делать. Чтобы у тебя В МОЗГУ был stop point на том месте, где может быть ошипка! Почему бы и не?

это не ADA, конечно.... но нудно, да :)

Мне обработка ошибок в Go нравится, но было бы неплохо чуток сократить синтаксис.

каким образом?

Вот это самый интересный вопрос. Вот тут есть несколько интересных идей https://github.com/vrok/have/issues/2

О! Спасибо, почитаю.

/me не Роб Пайк, так что я не с угрозой сказал "почитаю", а просто, как человек :)

Ну вот, а я подумал что ты Роб. ((

а я - не Роб :)

/me

Кто может подсказать годную либу для телеграма на го?

telegram-bot-api

Спасибо!

https://github.com/go-telegram-bot-api/telegram-bot-api

она?

да

Кто может подсказать годную либу для телеграма на го?

https://github.com/olebedev/go-tgbot

Сам напиал?

Кто может подсказать годную либу для телеграма на го?

зачем библиотека ? бота даже на bash можно сделать

чтобы не анмаршаллить руками например

и не отправлять запросы руками

ну типа это рутинные задачи

которые лучше в либу вынести

и оставить интерфейс "принять на вебхук" и "ответить"

там объем по-моему не такой большой что-бы доп. абстракции вводить

Превед! можно ли сгенерить веп-приложение для gin-gonic из Swagger-декларации?

там объем по-моему не такой большой что-бы доп. абстракции вводить

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

Превед! можно ли сгенерить веп-приложение для gin-gonic из Swagger-декларации?

я насколько помню там на стандартных либах каркас для go генерится, что кстати хорошо

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

еще зависит от сложности бота, но не уверен что прям бот будет использовать все типы запросов

Кстати а кто swagger использует в своих проектах ? Вы его как часть проекта разворачиваете ?

или просто берете yml и сгенеренный каркас ?

Кстати а кто swagger использует в своих проектах ? Вы его как часть проекта разворачиваете ?

да, спс, я глянул и понял о чём ресь Вот планируем перевести часть серверного апи на него

я его не использовал никогда, но смотрел, мне думается его удобно использовать для нового API.

или просто берете yml и сгенеренный каркас ?

This

я пробовал поднимать их образы из dockerhub

редактор странный как по мне, нельзя сохранять правки в определенный файл, только скачивать

это не удобно при составлении спецификации

я его не использовал никогда, но смотрел, мне думается его удобно использовать для нового API.

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

а планируете его использовать ради доки для API?

конечно! это я бы сказал в первую очередь.

есть еще такая штука - http://apidocjs.com/

для генерации документации

тоже интерактивная дока получается

вот у нас нечто подобное сейчас есть, влосипедное. Swagger всё таки на много больше даёт

вот у нас нечто подобное сейчас есть, влосипедное. Swagger всё таки на много больше даёт

как я видел он кроме доки еще и каркас может сгенерить

Есть ещё фуйсбучный GraphQL, вокруг него много хайпа сейчас, многие считают что за ним будущее

а если сравнивать доку то тоже самое

ну только источники данных для генерации разные

Есть ещё фуйсбучный GraphQL, вокруг него много хайпа сейчас, многие считают что за ним будущее

читал не давно про это

продвигают его под видом того что на разные клиенты нужны разные данные от API

ну не знаю сколько клиентов надо с разными требованиями чтобы было целесообразно такое использовать

В реактовом чате его очень любят кст

возможно у таких компаний как Facebook такие вопросы очень остро стоят

http://tonsky.livejournal.com/309037.html - складно глаголит про это дело

продвигают его под видом того что на разные клиенты нужны разные данные от API

несовсем так. решаются все проблемы практически, которые есть у rest-оподобных api. Основная суть: можешь в одном запросе вытащить все необходимые данные в необходимой структуре.

Подскажите, пожалуйста, есть что-то лучше BundDB среди встраиваемых БД?

Подскажите, пожалуйста, есть что-то лучше BundDB среди встраиваемых БД?

BoltDB довольно хорош

несовсем так. решаются все проблемы практически, которые есть у rest-оподобных api. Основная суть: можешь в одном запросе вытащить все необходимые данные в необходимой структуре.

Я про это как раз и написал

Про структуру вообще интересно. Эта проблема может возникнуть если сначала был разработан клиент а потом независимо от клиента API

Я про это как раз и написал

вообще-то нет. ты написал про разные клиенты и разные данные, а я про нужный респонс на один запрос. не надо собирать данные с разных эндпойнтов, как делается в парадигме rest, а можно сделать один запрос и получить правильно структурированные и все необходимые данные - хоть один клиент, хоть много. это именно query language со всеми вытекающими

Так это причина - разные требования к получаемым данным

Просто если такое со старта требуется то что-то не так в проектировании пошло

Кроме того как мне кажется никакой проблемы в нормализации на клиенте нет

Зачем это делать на сервере?

Мне думается с тем же успехом можно rpc использовать и закидывать туда sql запросы

Выполнять на сервере и отдавать ответ

Просто если такое со старта требуется то что-то не так в проектировании пошло

пример: на одной странице нужно получить листинг постов, топ-10 юзеров (причем не объекты из 10 полей, а только имена), топ-10 комментариев. REST частично это позволит сделать через 3 запроса. Частично потому, что грузится все объекты будут полностью. И вот это начальные требования большинства проектов и к проектирование здесь не причем. Ты просто возможно противопоставлячешь graphql своему кастомному апи, но graphql - готовая спека, и противопоставлять надо готовым спекам или парадигмам

Зачем это делать на сервере?

трафик.

мы же о ФБ говорим

Нет

Я про обычные проекты. На пример сразу думаю кому бы из клиентов могло такое понадобится

пример: на одной странице нужно получить листинг постов, топ-10 юзеров (причем не объекты из 10 полей, а только имена), топ-10 комментариев. REST частично это позволит сделать через 3 запроса. Частично потому, что грузится все объекты будут полностью. И вот это начальные требования большинства проектов и к проектирование здесь не причем. Ты просто возможно противопоставлячешь graphql своему кастомному апи, но graphql - готовая спека, и противопоставлять надо готовым спекам или парадигмам

Я ж говорю проще сделать rpc с отправкой sql запроса

пример: на одной странице нужно получить листинг постов, топ-10 юзеров (причем не объекты из 10 полей, а только имена), топ-10 комментариев. REST частично это позволит сделать через 3 запроса. Частично потому, что грузится все объекты будут полностью. И вот это начальные требования большинства проектов и к проектирование здесь не причем. Ты просто возможно противопоставлячешь graphql своему кастомному апи, но graphql - готовая спека, и противопоставлять надо готовым спекам или парадигмам

RPC через веб-сокеты проще.

Мне думается с тем же успехом можно rpc использовать и закидывать туда sql запросы

но ты знаешь что на сервере sql только в своем проекте. graphql - спецификация, абстрагимрующая тебя от этого знания

Я про обычные проекты. На пример сразу думаю кому бы из клиентов могло такое понадобится

трафик экономить?

ну да

Какой трафик?

Какой трафик?

клиента

Какой трафик?

делать меньше хттп, меньше хедеров и служебных транспортных пакетов

Если ты пишешь API то сразу продумаваешь как и где эти данные используются. Если есть не стыковки то API корректируется

ребят, это спецификация. не надо сравнивать ее со своим кастомным api. Спецификация создана для стандартизации и унификации опыта.

И таким образом у тебя меньше запросов

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

А вообще реально rpc с пересылкой slq зароса - который еще и на web-сокетах будет работать будет в разы производительней да и трафика в разы меньше будет

так чем же этот graphql лучше ?

ребят, это спецификация. не надо сравнивать ее со своим кастомным api. Спецификация создана для стандартизации и унификации опыта.

имхо как язык описания данных grpahql имхо не очень swаgger прям в разы лучше. А когда транспорт вебсокеты, особо кипеть на сжате трафика смысла нет

делать меньше хттп, меньше хедеров и служебных транспортных пакетов

речь идет об экономии не на спичках. выбрать 1000 объектов с 10 полями и выбрать 1000 объектов с двумя полями - это огромная экономия на трафике и огромный плюс юзер экспириенсу за счет более быстрого отклика