Высоконагруженный RESTful API в Ruby (синхронизация / асинхронная реализация)

Question

Я борюсь с реализацией RESTful API, который должен возвращать JSON-ответ и выдерживать очень высокую нагрузку. Наибольшая нагрузка будет генерироваться частью API «read», а очень небольшая нагрузка будет генерироваться частью API «write». Моей первой попыткой было написать весь API с использованием nodejs. Я почти сделал это, но столкнулся с очень сильным дублированием моделей и логики между javascript и ruby, потому что API является частью большой системы. Я попытался переместить всю логику в бэкэнд (mySql), но эта идея оказалась еще более уродливой. Моя вторая попытка - написать API в экосистеме Ruby для совместного использования моделей / логики и тестов между всеми частями системы.

Я пытался использовать только Cramp и Goliath, но все эти асинхронные вещи действительно усложняли реализацию API. Мне нужно только иметь 2 асинхронных URL-адреса для чтения, потому что они генерируют наибольшую нагрузку, и, идя асинхронно, я был вынужден реализовать остальную часть API асинхронно, что не добавило никакого значения.

Моя нынешняя попытка - стать гибридом: используйте коктейль Тонкий / Синатра / Крамп. Я создаю экземпляр дескриптора Thin rack прямо в коде Ruby и использую конструктор стоек. Я разделяю API между Sinatra, который принимает реализацию синхронизации, и Cramp, который реализует 2 URL-адреса асинхронным способом.

Это хороший путь? Или если Синатра и Крэмп на одном веб-сервере (Тонком) по каким-то причинам доставят мне еще больше неприятностей?

Обновление: Я пробую решение с единственной Синатрой, смешанной с rack / fiber_pool и em_mysql2. Кажется, я убиваю две цели - сделать API-интерфейс асинхронным с реализацией синхронизации. Но я страдаю от ошибки , которая, я думаю, будет исправлена ​​довольно скоро.

Были ли какие-нибудь ошибки, идущие таким образом?

Answer 1

Я не думаю, что это хорошая идея, чтобы синхронизировать (sinatra) и асинхронно (cramp) приложения в одном и том же тонком процессе. Если часть синхронизации относительно проста, я бы предложил реализовать это в Cramp. Немного предвзято здесь, когда я написал Cramp:)

В случае, если вы не знали, у Cramp есть готовая поддержка AR / Fibre Pool - https://github.com/lifo/cramp/blob/master/examples/fibers/long_ar_query.ru

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

Answer 2

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

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