Strongly considering Roda. Any thoughts on its "scalability"?

[Eric Hulburd]

Hi,

I'm building a rest server for a React app for a client that expects peak traffic to reach around 15,000 users at 5-10 requests per minute.

I've developed with both Sinatra and Rails in the past. I have also started some small projects in Golang, only to decide that I didn't like the package management and verbosity. I was thinking about giving Crystal Kemal a try, but I think it may still be too early for this particular project. 

I decided to to take a middle road and am considering Roda - the focus on performance and simplicity have a lot of appeal to me. However, I read a couple of blog posts where the authors suggest they primarily consider Roda for small projects:

http://engineering.procore.com/roda-vs-sinatra-for-small-projects-2/

https://twin.github.io/introduction-to-roda/

I never quite understood this argument again Sinatra either. Sinatra and Roda both seem to be a router and nothing more. If you are building a complex Rest API, there are not significant drawbacks to keeping this layer very simple - complex business logic, ORM, etc can easily be encapsulated outside of this layer.

Am I missing something here? Before I adopt Roda for a Rest API that I think will grow significantly in complexity and traffic, are there any scaling issues I should take seriously?

Another related question, I noticed that New Relic does not support Roda out of the box. https://discuss.newrelic.com/t/ruby-agent-for-roda-framework/39323 It seems like Sinatra is definitely the more well known and used framework, so I'm wondering if anyone has encountered similar integration drawbacks to choosing Roda over Sinatra.

Thanks,

Eric

[Tim Uckun]

You are right roda is just a router but if you are happy with the performance and functionality of Sinatra you'll probably be OK with Roda as Roda is supposedly faster than Sinatra.

The biggest issue is smaller community and the fact that things you are used to getting bundled with Rails are not there so you'll have to implement them yourself if you need them. You might also miss some of the gems that work with rails but not roda.

5 to 1-0 requests per minute is nothing.  You should be able to handle that with anything.  

BTW Crystal also has Amber which is a larger more rails like framework. Also if you may want to look at elixir. I think on a requests per second basis it won't be faster than roda (especially if you use jruby) but it's more scalable in lots of other ways and has a very robust websockets support.   One Issue I have is that it's virtually impossible to write a ruby web app (api or otherwise) which will not need some external processes to handle background tasks, scheduled tasks, etc so the memory requirement balloons up pretty fast.  More often than not you will also need a cache of some sort and yes redis will be installed sooner or later.  With something like elixir everything is built in to the language and the framework. No need to manage multiple processes or external memcache or redis servers. 

Good luck.

--
You received this message because you are subscribed to the Google Groups "Roda" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-roda+unsubscribe@googlegroups.com.
To post to this group, send email to ruby...@googlegroups.com.
Visit this group at https://groups.google.com/group/ruby-roda.
To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-roda/3494e36b-48d9-45c0-91a0-4a6d311e74ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Evans]

On Wednesday, November 22, 2017 at 2:44:31 PM UTC-8, Eric Hulburd wrote:

Hi,

I'm building a rest server for a React app for a client that expects peak traffic to reach around 15,000 users at 5-10 requests per minute.

For 0.1-0.2 requests per second peak, practically anything will work, so you shouldn't need to worry about performance at all.  That Roda is faster will not matter at all.

 

Am I missing something here? Before I adopt Roda for a Rest API that I think will grow significantly in complexity and traffic, are there any scaling issues I should take seriously?

From a complexity standpoint, Roda offers a lot of tools over Sinatra to manage complexity and handle larger applications (e.g. multi_route or multi_run).  Rails offers many features for managing complexity, though in my opinion the incidental complexity in Rails is higher than in Roda.  For example, request control flow in Roda is generally lexical following the routing tree, while it is more spread out in Rails (routing in one place, filtering in another place, handling in the controller method).

The main advantage to using Rails over Roda is that more libraries/tools integrate with Rails and more developers are familiar with Rails.  This is also true with Sinatra, though to a lesser extent.

Thanks,

Jeremy

[Andrew Burleson]

I’ve run both Sinatra and Roda in prod for multiple years, and as far as I’m concerned there’s no significant difference in experience between the two.

On technical merits I find the Roda code base better organized, the docs are much better, and at least in theory the routing performance should be closer to O(log n) vs O(n) for Sinatra, but it depends on what you do with it, and most apps don’t have enough routes + traffic for that to matter much.

Either way, if you’re in Ruby but not in Rails you’re joining this little band of rebels who eschew magic in favor of explicit code - at the cost of having to figure a lot of things out for yourself since they won’t “just work” the way Rails gems do.

To me that’s a desirable trade-off, knowing how my systems work pays off in reduced long-term maintenance and much better reliability. Development ramp time isn’t as fast though.

I think the much more important question for your use case (or any use case) is:

- Do you need to scale up to a large engineering team and move very fast? In this case using a popular framework may be better for you than optimizing for performance or personal preferences.

- Alternatively, are you confident that you’ll be compute / io / memory / or cost constrained? If so then it’s more important to start with the language that best fits your critical constraints, then choose your libraries etc. Whether or not Ruby is a good choice really just depends.

But if from those two questions (a) you don’t need the hiring or velocity advantages of a popular framework, and (b) Ruby fits your performance needs, then I think you’ll find Roda to be a great choice!

- Andrew

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to ruby-roda+...@googlegroups.com.

To post to this group, send email to ruby...@googlegroups.com.
Visit this group at https://groups.google.com/group/ruby-roda.

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-roda/CAGuHJrN2KiS-HD6TnogXCsJHmgtMc0zvEwsqQjc%2BjFEockd3Yg%40mail.gmail.com.

[Tim Uckun]

I found the documentation for Roda to be more frustration to work with. I think sinatra has a pretty nice documentation site with lots of examples and of course there are more sinatra apps to examine on github.  With roda there are a lot of plugins and you need to understand which plugins you need to use for what purpose and then read the docs for that. With sinatra you get a more integrated package.

There is also padrino BTW. That's halfway between sinatra and rails. 

I guess Hanami too but I haven't played with that at all so can't give you any advice about it.

- Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-roda/CAGuHJrN2KiS-HD6TnogXCsJHmgtMc0zvEwsqQjc%2BjFEockd3Yg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Roda" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-roda+unsubscribe@googlegroups.com.
To post to this group, send email to ruby...@googlegroups.com.
Visit this group at https://groups.google.com/group/ruby-roda.

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-roda/2A7ACA76-4D81-4AFB-8B5D-FB26FBF3355A%40gmail.com.

[Eric Hulburd]

Thanks - I actually meant (5-10 requests / minute) * 15,000 users. This was peak traffic the previous time we launched a similar platform in PHP, but in that case we had larger issues with the database (poor indexing).

Amber is also on my radar. I actually really want to use Crystal, but worry about alpha-level issues like memory leaks.

El miércoles, 22 de noviembre de 2017, 17:13:15 (UTC-6), Tim Uckun escribió:

You are right roda is just a router but if you are happy with the performance and functionality of Sinatra you'll probably be OK with Roda as Roda is supposedly faster than Sinatra.

The biggest issue is smaller community and the fact that things you are used to getting bundled with Rails are not there so you'll have to implement them yourself if you need them. You might also miss some of the gems that work with rails but not roda.

5 to 1-0 requests per minute is nothing.  You should be able to handle that with anything.  

BTW Crystal also has Amber which is a larger more rails like framework. Also if you may want to look at elixir. I think on a requests per second basis it won't be faster than roda (especially if you use jruby) but it's more scalable in lots of other ways and has a very robust websockets support.   One Issue I have is that it's virtually impossible to write a ruby web app (api or otherwise) which will not need some external processes to handle background tasks, scheduled tasks, etc so the memory requirement balloons up pretty fast.  More often than not you will also need a cache of some sort and yes redis will be installed sooner or later.  With something like elixir everything is built in to the language and the framework. No need to manage multiple processes or external memcache or redis servers. 

Good luck.

On Thu, Nov 23, 2017 at 11:44 AM, Eric Hulburd <er...@arbol.org> wrote:

Hi,

I'm building a rest server for a React app for a client that expects peak traffic to reach around 15,000 users at 5-10 requests per minute.

I've developed with both Sinatra and Rails in the past. I have also started some small projects in Golang, only to decide that I didn't like the package management and verbosity. I was thinking about giving Crystal Kemal a try, but I think it may still be too early for this particular project. 

I decided to to take a middle road and am considering Roda - the focus on performance and simplicity have a lot of appeal to me. However, I read a couple of blog posts where the authors suggest they primarily consider Roda for small projects:

http://engineering.procore.com/roda-vs-sinatra-for-small-projects-2/

https://twin.github.io/introduction-to-roda/

I never quite understood this argument again Sinatra either. Sinatra and Roda both seem to be a router and nothing more. If you are building a complex Rest API, there are not significant drawbacks to keeping this layer very simple - complex business logic, ORM, etc can easily be encapsulated outside of this layer.

Am I missing something here? Before I adopt Roda for a Rest API that I think will grow significantly in complexity and traffic, are there any scaling issues I should take seriously?

Another related question, I noticed that New Relic does not support Roda out of the box. https://discuss.newrelic.com/t/ruby-agent-for-roda-framework/39323 It seems like Sinatra is definitely the more well known and used framework, so I'm wondering if anyone has encountered similar integration drawbacks to choosing Roda over Sinatra.

Thanks,

Eric

--
You received this message because you are subscribed to the Google Groups "Roda" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ruby-roda+...@googlegroups.com.

[Eric Hulburd]

I completely agree that is a desirable tradeoff. I like Ruby's simplicity, but can't stand Rails "magic".

That is a good point about hiring/ velocity changes of a popular framework, but I think in the end, I would rather work with other devs that can write code than rely on a solely on a framework. Most of what I do has high level of domain complexity - frameworks seldom help there.

- Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to ruby-roda+...@googlegroups.com.
To post to this group, send email to ruby...@googlegroups.com.
Visit this group at https://groups.google.com/group/ruby-roda.
To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-roda/3494e36b-48d9-45c0-91a0-4a6d311e74ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Hulburd]

Thanks Jeremy. I'm mostly fine working with lower level libraries, since by the team lot of them are mixed into the same repo, they tend to introduce more complexity than they reduced to start off with - at least that's my take on apps with high domain complexity.

I actually meant that we will have peak traffic of 5-10 requests per minute * 15,000 users, which is on the order of 1250-2500 requests per second - ie very acute surges.

I'm fairly certain at this point I will be using Sequel + Roda or a Crystal framework at this point.

Eric

[Tim Uckun]

According to the techempower benchmarks (I know totally not applicable to real life) the passenger-roda-sequel stack did over 7K requests per second on the multiple query test.  Of course that's just one route probably and no protection or security at all so it seems like 2500 is not totally unreasonable.  I would definitely plan on more than one server if I were you though.

I know there was a lot of talk on the crystal mailing list about why the benchmarks showed far worse performance than what people experienced in their own workstations and I don't know if that ever got resolved. 

Either way I think the main choke point will be your database.

--

You received this message because you are subscribed to the Google Groups "Roda" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ruby-roda+unsubscribe@googlegroups.com.

To post to this group, send email to ruby...@googlegroups.com.
Visit this group at https://groups.google.com/group/ruby-roda.

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-roda/2b5cc79f-fe2a-4f3f-ad01-d40fdf62ac9d%40googlegroups.com.

[Igor Fontana]

ｉ　ｄｏｎｔ　ｓｅｅ　ｗｈｅｒｅ　ｒｏｄａ　ｗｏｕｌｄ　ｆａｉｌ　ｔｏ　ｓｃａｌｅ．

＋１　ｒｏｄａ

－－　

ＡＹＧＨＯＲ