Since Rails is not multithreaded (yet), it seems like a threaded web framework would be a better choice for a Facebook application. (reason being is cuz each Rails process can only handle one request at a time, and facebook actions tend to be slow, because there is a lot of network communication between your app and facebook)
Has anyone used Merb to write a Facebook application? Is there a port of Facebooker (the Facebook plugin for Rails) to Merb?
We've used merb_facebooker in one of our projects (Rock the Vote), and it worked out pretty well. Testing Facebook apps is quite annoying, as you don't have control of the middleware, so watch out for your expectations of the FB API and make sure you validate as much of them as possible early in the development stages (not trying out all the things we needed to do with fbML early on brought a few headaches).
Behold, merb_facebooker.
In addition, if you want to use Facebooker directly (like for a desktop app,) just install the gem:
gem install facebooker
Have you looked at Starling? It's the server used by twitter to handle their messages. It's a persistent queue server that allows you to delegate jobs to workers.
You can run passenger on Apache which will start up as many Rails instances as it needs up to a certain limit (I think the default is 30). It will also kill them as required, so if you're not getting as many hits as you were 5 minutes ago, it will release the system resources back to the system.
Learn more about passenger at http://modrails.com
Related
I've inherited a Rails 3.2 production environment which is 'humming' away nicely.
The client now wants another major piece of work doing but I want to do it in Rails 5. The web address would be the same for both the old site and the new project. The new project would be additional functionality which would be accessed via the old site.
Any one know of a way of keeping the old site running whilst I develop and deliver the new work via Rails 5? Eventually if this all works then I get the opportunity to migrate the old site to Rails 5. However for the moment I need to serve up both Rails 3.2 and Rails 5 from the same site.
It's possible to do what you describe with a reverse proxy, e.g. nginx, configured to serve from different web servers based on different paths on the same host. This answer has some details on how to do that. We would need to know how your website is hosted in order to give more details on exactly how to do that.
However, there are other concerns that come up when you start separating your apps which you may not have considered. For example, if your website allows users to log in, do you want them to still be logged in when they visit the new site? To do so transparently will require sharing the session cookie, which this post describes a bit (you'll need to use the same secret key for both apps, or use a remote session store like Memcached). I'm not sure if it'll work properly when shared between Rails 3.2 and 5, though.
As a final note, breaking up your monolithic app into a distributed system is never a decision to take lightly. It would likely end up being less work, and less overall architectural overhead, to simply invest the time in upgrading from 3.2 -> 4.0 -> 4.2 -> 5.0.
Personally I wouldn't touch that old app and its server, especially if the client is happy. Deploying the new app to a new server or a container service like heroku is something you should consider.
I was recently building an internal business database web app using Ruby on Rails 4 and Postgres. The plan was to make the app available to all our employees using Devise for authentication and hosting on Heroku.
Toward the end of development, a request was made to include some highly sensitive information in the app including social security numbers, etc. Thus, instead of heavily worrying about online security we are planning to make this app only run locally on one Mac and not have it available online. The app will only be used about 5 times a month by one person. Instead of requiring that person to launch a postgres server and a webserver via terminal (such as "rails server"), is there a way to package the entire Rails web app and database in to an application so it could be run similar to other OSX apps?
If anyone knows a PC solution instead, that is also a (less preferred) option.
At this point, we realize we should have developed a xcode app, but now that the development is mostly complete with some tricky UI, we would rather not have to recreate the functionality in xcode.
Though I haven't used it myself, what your describing sounds pretty close to what Rubymotion offers
Recently I've been looking for a solution to implement real-time updating web pages, for example, Twitter-like news feed or real-time chat. I've discovered some ways, as Pusher service, faye, and quite a lot of ruby gems, like private_pub or sync.
The problem is that this solutions don't seem to be a completely right way to follow. Pusher is rather expensive, and in fact I would not prefer to use other servie in my project. Faye seems insecure, and it is quite hard to implement security for it. Private_pub does the right thing, but last commit on github was in 2013 and in fact it is quite outdated.
All in all, ways that I have discovered do not seem to be professional-grade solutions for Rails startups. I have come up to the question whether I should completely switch to NodeJS or other technologies, or I can integrate NodeJS app inside a Rails one?
To sum up, is there such solution for Rails framework, or switch to another technologies is inevitable?
It may not help you right now, but at RailsConf last month DHH announced that Rails 5 will add support for websockets via a new library called ActionCable.
https://www.youtube.com/watch?v=oMlX9i9Icno
MessageBus might be a good fit. It's currently used in Discourse to implement live updates.
I'm also not sure what your security concerns about Faye are exactly. You should have no issues if everything is operating over HTTPS with proper CORS settings.
As for a mixed Node/Rails solution, you could push some list (e.g. post and list of those to be notified) on an update in the Rails app to a Redis instance. A Node app subscribed to Redis could then notify clients to make a request back to the Rails server for the latest updates.
I have been conflicted for a great deal of time in deciding how to update the app I am developing with notifications. In my app, users can post. I want to alert Users of new posts, just like facebook. However, given that Heroku does not support websockets and the like, deciding what to do has been tough. I DO NOT want to use pusher or pubnub as those services have outrageous prices.
In doing research, I learned about socket.io, which uses websockets if supported, then falls back on flash, or long polling to keep a connection to the server. This seems like the obvious choice for notifications b/c it will allow cross platform integration, it will be easy to implement websockets down the road, and its free.
I have been searching for a Rails 3+ Heroku supported socket.io gem, but I have read so many conflicting things that I am in great confusion. What are/is the best gem(s) to implement socket.io for Rails 3+ & Heroku?
We do not support long lived connections on heroku, so unfortunately using socket.io is not supported either. I would suggest that you use AJAX pulling (as Jakub Arnold suggests) to accomplish the same thing.
I have built two rails apps that need to communicate and send files between each other. For example one rails app would send a request to view a table in the other apps' database. The other app would then render json of that table and send it back. I would also like one app to send a text file stored in its public directory to the other app's public directory.
I have never done anything like this so I don't even know where to begin. Any help would be appreciated. Thanks!
You requirement is common for almost all the web apps irrespective of rails, Communicating with each other is required by most modern web apps. But there is a small understanding that you need to get hold on,
Web sites should not directly access each others internal data (such as tables), (even if they are build by the same language (in this case Rails) by the same developer),
That is where the web-services comes in to play, So you should expose your data through web services so that not only rails application can consume that, but also any app that knows how to consume a web service will get benefit.
Coming back to your question with Rails, rails supports REST web services out of the box, So do some googling about web services, REST web services with rails
HTH
As a starting point, look at ActiveResource.
Railscast
docs
Message queuing systems such as RabbitMQ may be used to communicate things internally between different apps such as a "mailer" app and a main "hub" application.
Alternatively, you can use a shared connection to something like redis stick things onto a "queue" in one app and read them for processing from the other.
In recent Rails versions, it is rather easy to develop API only applications. In the Rails core master, there was even a special application type for these apps briefly (until it got yanked again). But it is still available as a plugin and probably one day becomes actually part of Rails core again. See http://blog.wyeworks.com/2012/4/20/rails-for-api-applications-rails-api-released for more information.
To actually develop and maintain the API of the backend service and make sure both backend and frontend have the same understanding of the resources, you can use ROAR which is great way to build great APIs.
Generally, you should fully define your backend application with an API. Trying to be clever and to skip some of the design steps will only bring you headaches in the long run...
Check out Morpheus. It lets you create RESTful services and use familiar ActiveRecord syntax in the client.