Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Hi I'm looking to write a multiplatorm tasks application for technical people. I want to handle as many platforms as I can (web, shell, desktop) and therefore I have decided to begin with a server/API.
I want to write it in Ruby, however i think that Rails is a bit too heavy for this, even though it would do the job. Sinatra also doesn't seem quite suited for the task.
All the server/API would do would be to translate simple requests to Database queries, and at a later stage some authentication and authorization.
So basically I want to know:
1) Should I use a REST api or a SOAP api?
2) Is there a framework for this? Or what is the closest framework avalable?
For the adventurous, there is also a less known project called grape. It is a rack based application, similar to Sinatra, but is only purposed to write API. I don't think it is mature enough to be used in serious projects yet, but it is still interesting to know.
1) REST, SOAP is a terrible system and its support in Ruby is quite lacking. REST, on the other hand, is basically the ruby default and takes very little effort to use, especially if you are using REST/JSON.
2) Sinatra and Rails are basically your options. It comes down to how complex this application will be. Sinatra can probably handle the task just fine, but Rails does much of the work for you at the expense of bloat. You will already be taking on some of the rails bloat if you use ActiveRecord for the database. When authentication and/or roles come into play, Rails has mature solutions for both. Without any additional information, I'd lean towards Rails as it does much of the work for you and, when written properly, can still be fairly fast.
Actually SOAP is very VERY easy to implement with AWS.
At the same time, REST API is also very easy to implement.
I have written a couple of different and parallel (JSON, XML and custom format) APIs with rails. Im sure the framework stack performance will not be your bottleneck, so don't bother with worrying about performance just yet. Your first bottleneck will anyhow be database and then perhaps requests per second.
All in all i would suggest going with Rails, it has a lot of work cut out for you.
Since this old thread still comes up high on related Google searches, I should chip in my highly biased (as co-author and user) recommendation for Hoodoo. Unlike other offerings, Hoodoo includes an API specification that says how API calls must be made and how they must respond; it enforces a consistency across your design that calling clients will appreciate. If you can call one API, you can call them all. Hoodoo implements a lot of the boilerplate so you can focus on meaningful service code.
We've been using Hoodoo services for over two years very successfully at Loyalty New Zealand, who run the country's largest loyalty programme. Our Hoodoo-based microservice platform handles 100% of our client transactions.
http://hoodoo.cloud/
https://github.com/LoyaltyNZ/hoodoo
https://github.com/LoyaltyNZ/hoodoo/tree/master/docs/api_specification
https://github.com/LoyaltyNZ/service_shell
Hoodoo has 100% non-trivial rspec test coverage and 100% rdoc documentation coverage. As you'll see from the above links, there's quite a lot there!
Hoodoo is a Rack application, so works with any Rack compatible web server. Our preferred deployment mechanism though is an indefinitely horizontally scalable arrangement based on an HTTP-over-AMQP bridge and an AMQP cluster of nodes each running the same collection of services, managed inside Docker containers and deployed with Fleet. The system self-load balances across the service nodes via the queue and the decoupling of front end HTTP->AMQP processor versus the AMQP->HTTP input into the Rack stack dramatically reduces the system's attack surface. We wrote the front-end component in Node and for more about this along with Node implementations of other parts of the framework concept, see the Alchemy Framework. Alchemy Node services and Hoodoo Ruby services can coexist on the same grid happily.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
One of my college professors said that ruby on rails is used a lot for web, and I'm wondering how much Ruby on Rails is actually used vs JQuery, Node.js, PHP, etc. Also, what are the benefits?
You are mixing some stuff:
Ruby on Rails is a framework to create server side web applications using the Ruby language
jQuery is a client side JavaScript library that simplifies writing JavaScript web clients
Node.js is a server for the execution of server side JavaScript, thus providing a server version of JavaScript
PHP is a language popular for server side web application development
Thus: Ruby on Rails is a mature framework which offers a template engine, MVC architecture, a mapper between language objects and some relational database and a routing facility between URIs and controller.
Similiar designed frameworks exist for many programming languages / environments, e.g. Django for Python, or see Rails-inspired PHP frameworks in case of PHP.
About its popularity, see e.g. http://hotframeworks.com/
Benefits: IMHO it is a very elegant framework and as the plethora of inspired frameworks shows, has found many developers who like it.
The concepts and techniques learned here might also turn out to be useful when working with other modern frameworks.
And I should note as well, that there are web applications that need less features, e.g. see the Sinatra framework for a lighter alternative.
Also, what are the benefits?
There are a lot of things that websites have in common, e.g. html pages with forms, various javascript features, database interactions, security issues, logging in, etc. If you start from scratch, and try to program all those things yourself, it will be difficult and time consuming, and most likely your code will be full of exploitable security holes.
The other option is to use a web framework. Ruby on Rails is a web framework for the ruby programming language. All the various server side programming languages, such as ruby, python, php, perl, java, etc., have web frameworks(and usually many different frameworks to choose from!). A lot of smart people have come up with the best code for various things that websites need, and you get to use their code for free in your website.
The disadvantage of frameworks is that they are often large and complex, e.g. Ruby on Rails, Java Servlets+JSP, so it can take awhile to learn how to use them. Even then, you will probably not have a good grasp of their inner workings, so you are always sort of feeling around in the dark trying to get them to work the way you want them to. It's sort of like trying to push a large boulder which is at rest to another spot of your choosing: sometimes the boulder rolls cleanly into position, and other times the boulder seems to have a mind of its own and wanders off course.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm planning the basic architecture for a new software that will need to be modular.
I'm trying to define a multitenancy application to have a single instance running for all the users.
What I need is the possibility to scale when and where needed, so I don't like the idea to spawn multiple applications (monolitical architectured) behind a load balancer when it could be a single part of the computation that needs more resources.
So I'm thinking about a Service Oriented Architecture, it would have the rails application as web client and other services, that could be virtually written in any language and accessed via APIs by the rails application.
I'd also like to have this APIs open to users to integrate with their existing software and easily extend these services.
I've some specific question:
would it be a good idea to have this kind of architecture for a new startup (1-5 employees)?
using APIs i don't need to use any RPC since the API request itself is an RPC, am I right on this concept?
what would be a nice standard for the APIs (REST only defines HOW to access resources)?
what could be, pratically, the best (= a good) way to expose those APIs to customers? Via the Web Rails application? Directly via a proxy that makes them all available under the same domain? APIs would be accessible in a RESTful way so via HTTP requests.
with this kind of architecture would it be less expensive to have VPS's, Cloud, or dedicated servers? I like clouds because of their failure-tollerant nature, it would free us from worry about data persistence and backups (including the fact that we want to build an architecture almost 100% available).
Any other suggestion or point of view, and any simply start point to think about this would be very appreciated.
I know very well Python, C/C++, JS, Perl, other pl and I started recently with Ruby/Rails. I'm choosing this last one because it seems to me that this community is strongly oriented in building services and what I mind (before that extreme performances) is the ability to learn asap and have someone to share experience with and to learn from, also with pratical examples (I know it's about an architecture, not PL that implements it, but I think it would be more easy to get it wrong in an immature environment that is still working with web1 or web2.0 style in mind).
P.S. I also need to write the basic architecture design, do you have any template where I can start from? I do need to share it with my team and other very-expert pros, I'd like to have it complete and easy to understand.
Hope to read some good suggestions here guys!
Thanks,
Alex.
Architecture
Here is an example stack that would I think mostly do what you're looking to accomplish:
Cluster
One or more app servers
One or more database servers
Zero or more job servers
Instances
Chef for configuration
Unicorn or Passenger
Nginx
Application
Ruby on Rails
Check out Grape for simple APIs
More Specific Answers
would it be a good idea to have this kind of architecture for a new startup (1-5 employees)?
If done correctly, this approach can be very stable and robust. What you don't want to do it get into a situation where you are spending all your time managing your servers. You want to get it up, be able to deal with problem instances quickly, and work on making your application do stuff. If you do it right, creating instances can be simple and totally automated.
using APIs i don't need to use any RPC since the API request itself is an RPC, am I right on this concept?
Yes.
what would be a nice standard for the APIs (REST only defines HOW to access resources)?
Here we'd need a bit more clarification on how you need to use RESTful design to accomplish specific goals.
what could be, pratically, the best (= a good) way to expose those APIs to customers? Via the Web Rails application? Directly via a proxy that makes them all available under the same domain? APIs would be accessible in a RESTful way so via HTTP requests.
A domain (or subdomain) should be accessible via HTTP and RESTful software design. It might return JSON or something else. It's all up to you.
with this kind of architecture would it be less expensive to have VPS's, Cloud, or dedicated servers? I like clouds because of their failure-tollerant nature, it would free us from worry about data persistence and backups (including the fact that we want to build an architecture almost 100% available).
You get what you pay for. I'd recommend cloud servers. Check out Heroku to get started, or Rackspace if you are prepared to "roll your own." Or Engine Yard.
Any other suggestion or point of view, and any simply start point to think about this would be very appreciated.
I would try creating a test API using something like a free Heroku account.
I'm going to develop a collaborative site, and one of the features will be collaborative editing with realtime changes. i.e. when two or more users are editing the same doc, they can see each other changes as soon as they happen.
I have some experience with Ruby on Rails, so I was thinking about using EventMachine, but with all this hype around Node.js, I am know considering using it instead. So, what would be the main benefits of using Node.js instead of EventMachine?
tl;dr
What are the main differences between EventMachine and Node.js (besides the language)?
EventMachine has nothing to do with Rails apart from them both being written in the same language. You can get EventMachine as bare as Node.js; all you have to do is not add libraries to your project. In my experience the EventMachine libraries (like em-http) are much nicer than anything for Node. And you can use fibers instead of callbacks to avoid callback hell. Complete exception handling is pretty much impossible in Node because of all the callbacks. Plus Ruby is a nicer, more complete language than Javascript.
I tend towards the "use what you know" (even if it's a heavier architecture). Because of that, I don't see it being quite as simple as "EventMachine vs NodeJS." Mainly, the difference can be summarized as this:
NodeJS is a framework/language that was written to handle event based programming in JavaScript. That is its driving force. It's not an after thought, or a third party mechanism. It's baked right in to the language. You create callbacks/events because that's how the language is built. It's not a third party plug in, and doesn't alter your workflow.
EventMachine is a gem in Ruby that gives developers access to some of the goodness of the event based programming model. It's heavily used and well tested, but not baked directly in to the language. Both are locked to one CPU, but with event programming at Nodes core, it still has a leg up. Ruby wasn't written with concurrency in mind.
That said, technical problems can be overcome. The more important questions (from my view) that should guide your decision are these:
What will your production environment look like? Do you have complete control over the server? Can you host it however you want? Or will it be on a shared system to start with, and then you have to expand on that?
Do all the developers on your team have the ability to learn a new language very fast? How fast will they be able to understand an event-based language like JavaScript for the middle tier?
Do you need all of the architecture that Rails gives you (full Testing framework, scaffolding, models, controllers, etc)? Or is that overkill?
There are quite a few technical differences between the two. One is a language, one is a framework. Really, how heavy of a stack you want to run? How much learning will your developers have to do? Do you want a full stack the gives you a lot of niceties, that you may not use, or do you want a bare bones set up that runs extremely fast and concurrent, even though you may have to write extra boiler plate code and learn a new lanugage?
While Rails is not as heavy as some web application architectures, you're still going to need more processor power than you would to handle a similar amount of throughput in NodeJS. Assuming quality code for both systems. Bad code written on either stack is going to prevent the stack from shining. It really comes down to- Do you really want to learn a whole new way of doing things, or utilize your current understanding of Ruby to get things off the ground fast?
I know it's not really a definitive answer, but I hope this helps guide you to a decision!
One thing worth mentioning is the production story. EM, like most Rack stuff, has plenty of testing and monitoring tools available that are well tested, whereas Node.js falls well short in this respect.
At the time of writing, it seems almost impossible to get clear metrics from Node to answer questions like 'Do I need to scale'. There are options starting to form out there from the likes of Joyent, and always the roll-your-own argument, but nothing anywhere near tools such as NewRelic.
Node.js is very good from a performance / configurability point of view, but personally I wouldn't host it in production just yet.
Node.js
You get far better control low level control over what's going in. You can include general libraries to build on top of node.js to tweak your level of abstraction to your own liking. For example you can use connect or express depending on whether you want a view engine written for you.
You can use socket.io or now depending on how much you want your client-server connection abstracted. You can opt to include any of numerous MVC libraries or write your own.
Event-Machine
An asynchronous IO library just like node.js
It comes down to a Ruby vs JavaScript preference, how much flexibility you want with abstractions or lack of abstractions and whether you want to use node as your actual web server.
a detailed view at confusion has already been proposed... just a personal view
[] node.js will be better, if you are ready to learn and experiment more than you think because:
it's thread mechanism is awesome (inspired from that of 'erlang')
you can build a purpose specific server (easily) which will be real productive
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Are Ruby on Rails site usually slower than java or .net sites?
(This is assuming developers are not abusing the technology.)
A lot of Ruby sites I have seen have performance issues.
Yes, Ruby on Rails sites do have performance issues, just like any other site. And just like any other site, those performance almost always are rooted in architectural decisions, not the language or the framework.
There was a nice presentation a couple of years back by Joyent (might have been RailsConf 2007?), which showed on one slide all the servers that are running on a single instance of their Rails platform. About 40 processes. Only one of those processes was the Ruby interpreter, everything else was stuff like the DNS resolver, web server, database server, MTA, memcached, message queue, reverse proxy, load balancer, etc. Every single one of those can screw up your performance. That's a 97.5% chance that your performance problems have nothing whatsoever to do with Rails or Ruby.
There's some really nice E-Mails on the JRuby mailinglists, and also some Tweets and blog posts by people who rewrote their Java web applications in Ruby and got a 10% performance improvement.
A really good example is Twitter. Twitter is one of the biggest Ruby on Rails sites in the world. It is also one with a very unusual usage pattern that will give any framework that is designed for "normal" web applications a tough nut to crack.
Now, you might think, why did I choose Twitter of all things as an example of performance and scalabilit, when clearly it is the exact opposite that they are known for? Well, that's exactly the point: they have had a ton of scaling, performance and reliability problems. And not a single one of those had anything to do with Rails or Ruby. In fact, Rails and Ruby were pretty much the only pieces in their stack that they did not have problems with.
They had problems with unexpected growth. It doesn't matter which language or framework you use: if users are signing on faster than you can buy new servers, there is nothing you can do.
They had problems with the performance and scalability of MySQL. Again, MySQL has nothig to do with Rails or Ruby. In fact, MySQL is written in C, so if you really absolutely must make any ridiculous conclusion about a programming language, based solely on a single incident, then it would be this: C is slow. If you want performance, stay away from C.
(In this particular case, in one interview, they actually did blame Rails: they said that because Rails only supported a single connection to a single database, their MySQL instance simply got overloaded. Within hours of that interview being posted, two Rails developers independently of one another both released Rails plugins to implement multiple connections. The lesson is: only the 80% solutions are in the core. Twitter clearly isn't in the 80%. The plugin API is there for a reason.)
They had problems with the performance and scalability of the overall system. It turned out that, in order to get the product out quickly, they implemented absolutely no caching whatsoever. Even the "static" Twitter homepage was completely dynamically generated for every single request. Again, this had nothing to do with Rails or Ruby. You can bring any site down by turning off their caches, I guarantee you that.
They hit some very bad scalability problems (and the MySQL problems mentioned above are related to that) which were simply caused by the fact that people used the site in a way not anticipated by the developers. Everybody knows that Twitter is a micro-messaging platform. Well, except for the Twitter founders. They had this brilliant idea for a micro content management system.
And so, they did build a micro-CMS. And of course, the central piece of a content management system, is a content repository, IOW a database. Users however used Twitter as a micro-messaging platform. And the central piece of a messaging platform is a message queue.
As a result, MySQL was being used as a message queue. No two things could be further apart than a database (especially a SQL database) and a message queue. The two have almost exactly opposite requirements and constraints.
And of course, the entire architecture was built around that content repository which was now being abused as a message queue.
In response to that, the Twitter developers wrote their own message queue in Ruby, which helped performance and scalability a lot. But not enough. So, they wrote another message queue, this time in Scala.
It is this single rewrite that is wholly responsible for, I would estimate, at leat 70% of all the Rails FUD out there. But, I don't know about you: when I write something that I have absolutely no idea how to write it, and then I write the exact same thing a second time, when I actually do know what the heck I'm doing … the second one is always better than the first. And I suspect that this is the case here, too.
In several interviews, the Twitter developers have pointed out that Ruby on Rails was not responsible for their scaling problems. On the contrary, only the maintainability of Ruby made it possible to do such large-scale architectural changes to fix their scaling problems.
To cut a long story short: today, Twitter is actually using Ruby on Rails for what it was intended to be used: for a web application. And they use a database for storing data and not as a message queue. And they use an actual proper message queue. The message queue and some other backend stuff is written in Scala. The frontend is written in Ruby on Rails. Some stuff is written in C.
And all is peachy.
The real moral of the story here is that you can substitute pretty much any large web app, any language, any framework into the above story and it would still be true. MySpace is one of the slowest, most unreliable websites I know, and that is a .NET site. GitHub is one of the fastest websites I know, while being the biggest hosting platform (it has over a million repositories after just over 2 years, that's more than SourceForge and Google Code combined) and it is written in Ruby on Rails for the frontend, Sinatra for the web service, Ruby for the Git interfacing and Git infrastructure, Erlang for the federation and cloud infrastructure and Node.JS for the download server.
Here's a start
Scaling ROR
Why Rails can run slowly
Framework Preformance Comparison
SO related question
Related interest article Twitter abandons ROR its old I know but I didnt actually know that lol
Short answer
Could potentially sure.
Might be more likely than some other languages.
Depends on the application, the programmer and the architecture.
As I see it - RoR is only a bit slower. At least slower than .Net, cause ruby is interpreted language.
But in general - it depends on quality of developers. RoR app that uses nice caching will work n times faster than .net/java app that loads half database into memory and sends plenty database requests cause of select n+1.
yes it is slower, but in production it will probably only hurt you once your load "exceeds a certain point" ("x requests/sec") and most sites never see more load than that.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
My company is looking to move their software to an open source framework. Their first thought was J2EE. I know that Django and Rails are popular for recreational development, but not sure about them in a corporate setting.
I was looking to compile a list of possible web frameworks to consider. Unfortunately I am not able to release our requirements to the public. Also I would like to know if you have seen/used different frameworks in a corporate environment.
Thanks
I believe the more important question is what talents you got. If you have a primarily Java team, and you want to completely move to Ruby or Python, it's gonna be hard, if not impossible.
When deciding if X language/framework is good for a business, you have to consider opinions from your internal technical staff first. That normally sets you in a place with limited choices. Unless you are with a very small but highly talented/motivated team or planning to build a team with new hires.
Not sure what you mean by a corporate use, but we're using Django at a large media company for the websites of nearly 40 radio stations.
Another vote for Django. I'm not sure if the Washington Post or LA Times count as "corporate" but they have a lot more demands (both daily hits and time-to-new-feature) than your average "corporate" environment.
Struts, Stripes, Wicket, Spring MVC. I use Grails and love it.
You can go to Rails too. We use Rails successfully in a number of serious applications.
If you are just looking to save money from software, you can go to any J2EE frameworks out there. If you looking for some fun and rapid development, try Rails.
It all depends on the type of the project and the talent you have.
I use django in a real-time professional environment.
it's solid, and blazing fast (django on nginx/fastcgi, and soon couchdb too!)
We're using sinatra (ruby) for frontend to our main internal application. Simple, stable and flexible.
Struts2, Spring MVC, Stripes, Wicket, Grails, JSF, Seam, GWT, Flex, etc (Stripes and Grails being my favorite).
Matt Raible did interesting comparisons of (most of) them in this presentation which is an updated version of this old one.
Another interesting reading might be the What is the most commonly used Java web framework? question here on SO.
IMO, whatever you choose doesn't matter that much, the presentation layer will still be throw away code.
Any framework that keeps you away from the imperative languages (e.g. Java, C#, JSP with Java etc.) is better. Declarative/Functional/Data Flow languages (e.g. Ruby, XSLT, Python, etc.) result in solid implementations that save you support/enhancement $$$.
It sounds like the powers that be are comfortable with Java, but do yourself a favor and avoid J2EE. Go grab Restlet and Groovy, write a nice Rest back-end that not only serves as a programmatic API for your project, but will work nicely with any Ajax/Javascript library you choose to implement a UI in.
We are currently using Django and the web site is driving a lot of business to the company as well as growing by double digits since last year. It doesn't matter what kind of technology the corporation is using but what their business model is. What are you currently using in-house? It will make more sense to use a web framework related to your in-house code, knowledge and man power.
If nobody knows Rails or Django, you have to factor in the learning curve during the migration. It should only be a couple of weeks depending on the savviness of your developers. Then again if everyone hates or do not enjoy working with the in-house technology, trying a new one might be worth it.
"I know that Django and Rails are popular for recreational development (...)"
Rails:
http://basecamphq.com
http://highrisehq.com
Django:
http://www.lawrence.com/
http://www.everyblock.com/
They have high traffic and content-heavy services. I wouldn't call those guys business as "recreational development".