Апишка внешняя, повлиять не можем.

Но, как я уже сказал, том же запросе к АПИ могут быть разные ошибки и бывает нужно раграничивать их и реагировать на разные типы ошибок по разному

Очень может быть, что в твоем проекте этот подход оправдан. Но ты спросил мнения людей в чате. Я поделился своим фидбеком

Очень может быть, что в твоем проекте этот подход оправдан. Но ты спросил мнения людей в чате. Я поделился своим фидбеком

А никто не спорит, твое мнение было очень полезным, спасибо.

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

Насчет применения exponential backoff в http запросах есть хорошее решение - https://github.com/lostisland/faraday/blob/master/lib/faraday/request/retry.rb

ха, не знал что у фарадея это есть.

А еще, у него есть поддержка адаптеров. Если надло делать кучу запросов, то можно обнаружить, что дефолтный Net::Http у руби - мееедленный

Тогда можно подключить typhoeus(враппер над curl)

То что это свитчер адаптеров это я знаю )

и код не надо переписывать

я сам тифеус юзаю, только напрямую.

А как инициируется дергание апишки?

По расписанию? Пользователь на веб-морде кнопочку жмакнул?

Или цикл бесконечный?

По расписанию? Пользователь на веб-морде кнопочку жмакнул?

+

реалтайм

бизнеслогика так устроена

а что видит пользователь, когда запрос к апишке завалился?

данные по остальным апишкам.

хм.. получается, параллельно делаются запросы?

в тредах?

может, потому и каша, что не thread-safe?

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

разбить на фронте на три запроса: 1. Не нужно 2. Дорого, ибо внутри месиво

Понятно.

ну да, сплошные костыли

Но если бы нужно было бы сделать вебморду максимально отзывчивой, то рекомендовал бы: 1. Вынести все запросы к API в threaded бекграунд (sidekiq) 2. Обновлять статус прямо в браурере пользователя через websockets / sse

> Вынести все запросы к API в threaded бекграунд (sidekiq) Не понимаю как это будет выглядеть если результаты нужны прямо сейчас

кешировать бесполезно.

делать заранее - бесполезный огромный оверхэд

да, конечно, зависит от задач проекта

Просто сталкивался с подобным. И в какой-то момент приходилось решать проблемы производительности

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

Можно еще сделать так: 1) от пользователя поступил запрос 2) не заставляя его ждать, сервер сразу рендерит страницу результатов, где на месте каждого блока - спиннер 3) тем временем в бекграунде делаются запросы и по мере выполнения каждого - соотнесенный спиннер заменяется результатом Конечно, реализация зависит от вашего фронтенда

Да, это очевидно. Просто проект - сплошное месиво.

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

готовые отлаженные решения? это какие же?

ты привел пример rollbar, который просто постфактум отправляет стэктрейс. У меня именно перехватывает ошибку.

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

собственно я об этом как раз и говорю

привели newrelic, sentry

написали что перехват ошибок довольно плохая затея

Объяснил же что получить часть данных лучше чем увидеть 500

лучше обернуть непосредственное обращение к api в обёртку которая контроллируемо делает вызовы(возвращает данные ошибок, если апи недоступно, ещё чего) и там же обрабатывает исключения, чем оборачивать всё в такое вот

но... я думаю это опять бесполезно спорить

это и есть та самая обертка внутри класса которые пытается получить данные ЕСЛИ данные от апи пришли ...

ну так сделай путём что-то типа def call_to_api_server(action, params) open('http://your_server.com/#{action}#{params') rescue Net::OpenTimeout => e do_something rescue SocketError => e do_something end и у тебя будет ясно сразу при 500 ошибке что-то явно не то

глючный класс

так мож его переписать лол

ну так сделай путём что-то типа def call_to_api_server(action, params) open('http://your_server.com/#{action}#{params') rescue Net::OpenTimeout => e do_something rescue SocketError => e do_something end и у тебя будет ясно сразу при 500 ошибке что-то явно не то

еще раз повторяю, ДАННЫЕ ПРИШЛИ.

Данные - бред, класс ломается.

(очень редко но случается)

Данные - бред, класс ломается.

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

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

Лол, как ты будешь обрабатывать неожиданные данные?

что это за код, если он не может обработать некорректные данные?

Или там на входе может быть вообще что угодно, даже небо, даже аллах?

Который ожидает что апишка нормально работает, нет?

И ты на все случаи жизни этот класс гоняешь?

Там на входе иногда приходит бред, редко но приходит.

Велкам Роман

это есть т.н исключение

Ye

Ну

ERROR: S client not available

ну сделай метод def handle_data do_something end

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

а говорить "ничоси, я такое не умею"

и работать дальше

это как бы основы

это как бы основы

Active model serializers например падает если не может получить доступ к какому то аттрибуту который заявлен

Значит ты неправильно описал этот код

ничоси, он кидает эксепшен потому что это действительно эксепшен!

если он прям падает

Он падает потому что это исключительная ситуация.

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

Он падает потому что это исключительная ситуация.

ииии что?

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

это не конец света, пишешь код для обработки эксепшена и программа работает дальше

Причем тут юзеры?

суть как раз в том что если от апишки пришел бред то в юзера я как раз таки 500-ой не стреляю

Я уже потерялся, у тебя проблема в чем конкретно?

а возвращаю те данные которые доступны

Я уже потерялся, у тебя проблема в чем конкретно?

От апишки приходит бред, поэтому я ключевые моменты класса-парсера оборачиваю в failsafe

таким образом я хотя бы часть данных отображаю.

ну смотри - ты же можешь проверить что пришло от апишки?

Привет ✌ ! у меня есть таблица products и welcome_pages, которая has_many :products с такой схемой create_table "welcome_pages", force: :cascade do |t| t.integer "product_id" t.integer "seq" t.datetime "created_at", null: false t.datetime "updated_at", null: false t.index ["product_id"], name: "index_welcome_pages_on_product_id", using: :btree endв контроллере я хочу получить эти продукты @featured_products = WelcomePage.joins(:products) - вот так не получается ?. Буду признателен, если покажете чяднт. С рельсами и sql и орм ами только туториалы проходил)

WelcomePage.products?

WelcomePage.find(page_id).products

ну смотри - ты же можешь проверить что пришло от апишки?

по некоторым полям приходит бред

аааааа

по некоторым норм.

Ну да, плохо описал задачу, сорян.

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

Если бы там полный бред был - было бы проще проверить, да.