браузер - приложение которое делает запросы к твоему монолиту например

ок я понял я заблуждаюсь

а боты могут принимать json objects c моего api?

У меня есть монолитное приложение, то есть MVC. Надо чтобы Телеграм бот мог работать с ним. Если приложение - монолит, то нету API, тогда как бот могут делать гет и пост запросы?

думаю, надо написать api )

боты - получают сообщения от телеграмма, что-то с этим делают и отвечают телеграмму

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

то есть для каждого action надо делать два формата: json и html

либо так, если экшены совпадают, либо использовать grape для api на однельных юрлах

либо написать отдельное приложение с api которое будет работать с той же базой

боты вроде нихуя не могут, ток текст слать

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

боты вроде нихуя не могут, ток текст слать

вы хотите сказать что они не смогут работать с API моего приложения?

смогут

ну вообще да, ты как это представляешь? ты боту даёшь ссылку на твоё апи и он такой - о, Апи, ща разберусь

смотреть в сторону api.ai

он, кстати, уже несколько месяцев как бесплатный полностью

ну вообще да, ты как это представляешь? ты боту даёшь ссылку на твоё апи и он такой - о, Апи, ща разберусь

так и представляю

эм... ну начни приём хотя бы слова "Привет"

а в чем трудность? ты получаешь слово "Привет", обрабатываешь как-то и засылаешь ответное сообщение от лица бота

можно реализовать самому (тут хз как), можно юзать сервисы специальные (выше линка есть) - там точно это реализуется сверхпросто

там суть в том, что api.ai сам выпарсит данные из сообщения, отправит на твой эндпоинт и получит респонс

из которого возьмет ответ и отправит его хоть в телеге, хоть в скайпе

ты работал с api.ai? ?

читал доки долгую бессонную ночь

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

и запускал дефолтного бота

со словарем уже готовым

с эндпоинтами не взаимодействовал, но функционал там для этого есть и хорошо задокументирован

а в чем трудность? ты получаешь слово "Привет", обрабатываешь как-то и засылаешь ответное сообщение от лица бота

тут ключевое что "обрабатываешь как-то" а чувак просто хочет куда то там ссылку на апи поставить и чтобы всё заработало

это не реклама сервиса, если шо, я к нему никакого отношения не имею, просто говорю о возможности реализации данной идеи

тут ключевое что "обрабатываешь как-то" а чувак просто хочет куда то там ссылку на апи поставить и чтобы всё заработало

нет. я не это имел ввиду

вы хотите сказать что они не смогут работать с API моего приложения?

ты вообще понимаешь что такое бот?

бот - это программа, которая запускается по триггеру - пришедшему сообщению

бот будет обрабатывать его

выполняет свой код и отвечат сообщением отправителю

вот то, что происходит в промежутке - это любой, написанный тобой код

бот будет обрабатывать его

скорее не так это будет работать. ты получишь сообщение от бота, распарсишь и скажешь что ответить

от запроса к апи, до подрыва атомной станции

тобишь по факту обрабатывать будет не бот

а твоё апи

задача бота - отправить данные в апи, получить респонс, выдать ответ

это как я себе представляю )

точно

у нас просто есть сервис распознования голоса в текст, стандартизация и обработка и там всё не очень однозначно. Т.к. в твоей голове юзеры говорят, вбивают очень "правильные данные" а на деле они вбивают всё что в голову придёт

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

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

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

а твоё апи

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

да

эндпоинт твоего апи, в любом раскладе ))

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

Спасибо за советы)

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

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

может сам обработает

может на другой эндпоинт забросит

такое специально не придумаешь )))

ну из экшена вызывать другой эндпоинт такая себе затея

если эндпоинт не часть твоей системы - другого варианта нет же )

если другой эндпоинт всмысле )

ребята, вопрос чисто риторический

схлестнулся в споре с java программистом

он говорит, что у них подход - запросить данные из ОРМ, после обработать приоритетнее нашего - запросить всё, что нужно в plain sql

это в случае допустим группировки большой таблицы

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

у кого то есть опыт подобный?

в рельсе просто ActiveRecord паттерн используется, а там вроде DataMapper

ERROR: S client not available

в рельсе просто ActiveRecord паттерн используется, а там вроде DataMapper

в жзабе-то?

да какой угодно

ну ихний гибернейт попсовый

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

а с помощью ОРМ на самом бэкенде

это что за джава прогер был? EJB/Spring или Hibernate

в рубях это обычно выливается в эндпоинты, работающие по 5-10 секунд

Hibernate

ява же

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

потому что ОРМ для жабы начали пилить еще когда рельс в помине не было

"85 гигабайт памяти должно хватить"

все дела )

чистый sql всегда будет быстрее обработки на бэкэнде

другое дело, что его писать дольше и поддерживать сложнее

вообще DataMapper так же и в жанге питоновской юзается и в Doctrine пэхэпэшной

чистый sql всегда будет быстрее обработки на бэкэнде

вот и я о том же, хочу выяснить - это ООП головного мозга уже или у них это рили не критично )))

сильно зависит

(токо там всё равно в БД уходит всё)

вот и я о том же, хочу выяснить - это ООП головного мозга уже или у них это рили не критично )))

писать сырой SQL - это такое себе занятие

да, но если ты допустим юзаешь стандартные функции БД - то что делать?

писать сырой SQL - это такое себе занятие

допиливать рельсами своё незнание SQL - тоже

допиливать рельсами своё незнание SQL - тоже

+

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

допиливать рельсами своё незнание SQL - тоже

люди по 10 лет SQL Не пишут на рельсах

наверное это что-то да значит

не всегда это будет pain sql

не всегда это будет pain sql

> pain sql

Ж)

моя жизнь в 8 символах

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

да один фиг выглядит хреново

обмазался ты доменной лдогикой в три слоя

а под всеми этими слоями пишешь SELECT * FROM