Comments 4
Это ваша разработка?
Что за дичь вы устраиваете, серьезно.
Если вы хотите сделать реализацию сервера, которую будет использовать сообщество, то
1. Используйте rack как интерфейс сервера (https://rack.github.io/)
Хорошую его реализацию для jruby можно найти в puma (https://github.com/puma/puma/blob/master/lib/rack/handler/puma.rb) — как видите, очень близко к вашему UrlExpander
2. Асинхронные запросы — это отлично, но помимо простого проксирования хотелось бы видеть нормальную систему async/await или хотя бы минимальное API для преобразования результата. Опять же не потребует сильных переделок
3. DSL в синатра-стиле а не чудеса с handlers и chain
4. Конфигурация через YML
А так подобное хоть и работает, но абсолютно неюзабельно. А в руби-сообществе неюзабельные вещи очень быстро умирают.
Как эксперимент пойдет, как продакшен решение — не катит и требует изменений API
Что за дичь вы устраиваете, серьезно.
Если вы хотите сделать реализацию сервера, которую будет использовать сообщество, то
1. Используйте rack как интерфейс сервера (https://rack.github.io/)
Хорошую его реализацию для jruby можно найти в puma (https://github.com/puma/puma/blob/master/lib/rack/handler/puma.rb) — как видите, очень близко к вашему UrlExpander
2. Асинхронные запросы — это отлично, но помимо простого проксирования хотелось бы видеть нормальную систему async/await или хотя бы минимальное API для преобразования результата. Опять же не потребует сильных переделок
3. DSL в синатра-стиле а не чудеса с handlers и chain
4. Конфигурация через YML
А так подобное хоть и работает, но абсолютно неюзабельно. А в руби-сообществе неюзабельные вещи очень быстро умирают.
Как эксперимент пойдет, как продакшен решение — не катит и требует изменений API
Извините конечно, но по последней ссылке сходить не пробовали? Ratpack не имеет никакого отношения к Ruby, это быблиотека для JAVA. Собственно в самом анчале про это и указываю.
1) Зачем мне Rack если я не использую rack совместимый сервер + для реаьлной задачи где он используется это лишняя прослойка. UrlExpander это просто пример чуть сложнее HelloWorld, чтобы добавить использование Promise из Ratpack.
2) async/await везде делается на уровне языка, так что этого нет ни в JAVA, ни в Ruby, то и в JRuby ему появится неоткуда. В данном случае, предлагается модель Promise на основе акторов от Netty (JAVA библиотека, не имеет отношения к Ruby), без GIL, как в MRI реализации.
3) Зачем DSL? Еще раз, статья о том как использовать высокопроизводительный сервер из мира JAVA с Ruby.
Подобное работает, в продакшене, быстрое, юзабельное и приносит реальные деньги.
И еще раз повторю, статья о том, как использовать хорошие, быстрые, производительные решения на JAVA и не отказываться от имеющейся кодовой базы полностью. Отсюда и выглядит это все немного не Ruby like, а как JAVA.
1) Зачем мне Rack если я не использую rack совместимый сервер + для реаьлной задачи где он используется это лишняя прослойка. UrlExpander это просто пример чуть сложнее HelloWorld, чтобы добавить использование Promise из Ratpack.
2) async/await везде делается на уровне языка, так что этого нет ни в JAVA, ни в Ruby, то и в JRuby ему появится неоткуда. В данном случае, предлагается модель Promise на основе акторов от Netty (JAVA библиотека, не имеет отношения к Ruby), без GIL, как в MRI реализации.
3) Зачем DSL? Еще раз, статья о том как использовать высокопроизводительный сервер из мира JAVA с Ruby.
Подобное работает, в продакшене, быстрое, юзабельное и приносит реальные деньги.
Как эксперимент пойдет, как продакшен решение — не катит и требует изменений API
И еще раз повторю, статья о том, как использовать хорошие, быстрые, производительные решения на JAVA и не отказываться от имеющейся кодовой базы полностью. Отсюда и выглядит это все немного не Ruby like, а как JAVA.
1. И теряете все преимущества rack как унифицированного интерфейса запуска ruby сервера и управления его конфигурацией, вместо цепочки вызовов.
А делов то — перенести конфигурацию в self.run(app, options = {}) и обозвать экспандер по-другому.
2. > async/await везде делается на уровне языка.
Согласен. Только я имел ввиду не нативный async/await, а «систему async/await», т.е. не ParallelBatch.of(tasks).yieldAll.flatMap
а, например,
tasks.async_each
3. Зачем DSL?
Чтобы у новичков шаблон не рвало, например. Тех кто десятый год в хайлоаде ничем не испугаешь, но простая адаптация и DSL, особенно который является стандартом для подобного рода задач, значительно сокращают время адаптации нового сотрудника. Опять же, переписать — минимум — chain почти все умеет.
Бесспорно «В проде работает, не трогай» — это отлиная отмазка для своей лени. Но друг мой, вы творите дичь. Дичь по меркам руби сообщества. Вы не режете углы там, где могли бы, вы не следуете идеологии руби.
Не надо так. Очень прошу, почитайте доктрину rails http://rubyonrails.org/doctrine/
А делов то — перенести конфигурацию в self.run(app, options = {}) и обозвать экспандер по-другому.
2. > async/await везде делается на уровне языка.
Согласен. Только я имел ввиду не нативный async/await, а «систему async/await», т.е. не ParallelBatch.of(tasks).yieldAll.flatMap
а, например,
tasks.async_each
3. Зачем DSL?
Чтобы у новичков шаблон не рвало, например. Тех кто десятый год в хайлоаде ничем не испугаешь, но простая адаптация и DSL, особенно который является стандартом для подобного рода задач, значительно сокращают время адаптации нового сотрудника. Опять же, переписать — минимум — chain почти все умеет.
Бесспорно «В проде работает, не трогай» — это отлиная отмазка для своей лени. Но друг мой, вы творите дичь. Дичь по меркам руби сообщества. Вы не режете углы там, где могли бы, вы не следуете идеологии руби.
Не надо так. Очень прошу, почитайте доктрину rails http://rubyonrails.org/doctrine/
1) Ratpack пишут ребята из Gradle, и пишут его для JAVA мира, привязаться к Rack можно, написав свои адаптеры и тд. Пару месяцев назад даже делал такую прослойку, чтобы перенести имеющийся прод на Ratpack, но из-за лишних этапов (в самом Rack и потом Sinatra), которые по большей части дублируют функциональность, разница в скорости была не существенная. Когда выпилил их, и всю логику перенес на JAVA (те самые Chain), оставив лишь прямые вызовы бизнес логики, то прирост уже был ощутим.
Если и делать такую обертку, то над чистым Netty, чтобы задачу роутинга, формирования ответа и тд переложить на Rack и выше.
2) В JAVA нельзя расширять существующие классы, в Ruby можно конечно, да и интерфейс авторы сделали более менее привычный, совместим с тем, что есть в RxJava и других пободных бибилотеках и решениях. Многие как раз ругают Rails, за то что расширяет классы безспроса, что потом уже путают что есть в Ruby, что из Rails пришло.
3) Написать DSL поверх этого не проблема, но не вижу смысла, как говорится ИМХО. В данном случае, я за то чтобы делать минимум лишних действий между JAVA кодом и Ruby. А скорость адаптации все же не от DSL зависит, а от качества когда.
Это достаточно специфичное решение. Если нужно что-то каноническое, то это Puma, но на ней не сделаешь сотню паралелельных HTTP запросов, не заблокировав потоки. Можно конечно поколдовать над Ruby::Concurrency или Celluloid, но архитектура у Puma такая, что прям навязывают линейное выполнение кода. Не зря же делают альтернативные решения для выноса ActionCable из основного приложения (anycable).
В проде оно очень даже хорошо себя показывает, высокий concurrency, низкие задержки, узкие места перенесены на JAVA. В итоге время ответа (сложная логика) составляет 2-3мс. И весь I/O полностью асинхронный.
В конечном итоге я не предлагаю коробочное решения, а лишь показываю что если не устраивает то что есть в Ruby экосистеме, но есть на JVM, можно использовать это достаточно легко и просто. Да это будет не ruby way, да это будет идти местами в разрез с идеологией, но все это лишь инструмент и рекомендации, а не догма.
Если и делать такую обертку, то над чистым Netty, чтобы задачу роутинга, формирования ответа и тд переложить на Rack и выше.
2) В JAVA нельзя расширять существующие классы, в Ruby можно конечно, да и интерфейс авторы сделали более менее привычный, совместим с тем, что есть в RxJava и других пободных бибилотеках и решениях. Многие как раз ругают Rails, за то что расширяет классы безспроса, что потом уже путают что есть в Ruby, что из Rails пришло.
3) Написать DSL поверх этого не проблема, но не вижу смысла, как говорится ИМХО. В данном случае, я за то чтобы делать минимум лишних действий между JAVA кодом и Ruby. А скорость адаптации все же не от DSL зависит, а от качества когда.
Это достаточно специфичное решение. Если нужно что-то каноническое, то это Puma, но на ней не сделаешь сотню паралелельных HTTP запросов, не заблокировав потоки. Можно конечно поколдовать над Ruby::Concurrency или Celluloid, но архитектура у Puma такая, что прям навязывают линейное выполнение кода. Не зря же делают альтернативные решения для выноса ActionCable из основного приложения (anycable).
В проде оно очень даже хорошо себя показывает, высокий concurrency, низкие задержки, узкие места перенесены на JAVA. В итоге время ответа (сложная логика) составляет 2-3мс. И весь I/O полностью асинхронный.
В конечном итоге я не предлагаю коробочное решения, а лишь показываю что если не устраивает то что есть в Ruby экосистеме, но есть на JVM, можно использовать это достаточно легко и просто. Да это будет не ruby way, да это будет идти местами в разрез с идеологией, но все это лишь инструмент и рекомендации, а не догма.
Sign up to leave a comment.
JRuby + Ratpack = ❤️