So I want to build an app that constantly monitors a certain hashtag/phase like #cookies and sends out an email to me (and anyone else who signs up on the site) every day with a list of all the tweets.
I have some Ruby/Rails experience and was considering building this on Heroku, but I was wondering if there was an easier platform to build it on, like say, Google App Engine (which I know very little about)
Assuming you want this to be a web application (not necessarily true from your description), I'd recommend Rails. You have some experience with it, and it's a solid platform. Heroku should work fine for this, but it's certainly not the only viable option. I'm not an expert on Heroku, and I don't know much about your app other than its primary function, so I couldn't tell you if Heroku is the optimal choice. As for Google App Engine, I'm pretty ignorant, but I've heard Rails isn't currently its sweet spot. (Just hearsay.) You could also consider a VPS, which is probably more work but also very educational.
The app itself should be pretty easy to use. Plug in to the Twitter Search API (http://dev.twitter.com/doc/get/search) or piggyback off some third-party Twitter aggregator. Then set up a cron job that accesses whatever data stream you've picked (Twitter API or third-party) and plug the results into ActionMailer.
Related
Background
I have a fairly typical Rails application, which uses Devise for authentication management. While building this app, I realized that realtime chat would be a great feature to have. Ideally, of course, this would make use of Websockets, in order to reduce the polling load on the server (as well as making it marginally easier to implement, as you don't have to manage polling).
I realized quickly that Ruby isn't really a great fit for having a large number of concurrent connections open at one time. Phoenix, however, is written in Elixir, so I can make use of the Erlang VM, which is quite good at long connections. It also seems like it could be greatly beneficial if all the chat data was stored separate from the main application database, which should also reduce load in the future.
The Problem
I want to be able to make this separation completely invisible to the user. They visit www.example.com/chat, and it loads all the relevant data in from chat.example.com and starts up the websockets, without requiring them to login to a separate service. I think using an <iframe> is probably the way to go about doing this.
My problem is sharing authentication and data between the two applications. The Rails app needs to be able to create conversations on the Phoenix app in response to certain events. The Phoenix app needs to know what user is currently authenticated into Rails, as well as general data about the user.
An OAuth flow with the Rails app as the ID provider seemed like a good fit at first, but I can't figure out a way for the Phoenix app to automatically be granted access. I also have some concerns about user records existing inside the Phoenix app—it should be aware of all users on the main application, so you can start a chat with a user even if they haven't ever opened chat.
What would be the best way to go about doing this? My intuition says that this is going to involve window.postMessage and some kind of token system, but I wanted to ask what the generally accepted way of doing this was before I accidentally created an insecure mess.
Sharing the session isn't too hard, assuming you are running at least Rails 4.1 and using JSON serialization (default for apps created with >=4.1). A quick google search finds PlugRailsCookieSessionStore, which accomplishes this.
For more information on what it takes to share a session between Rails and another language, Matt Aimonetti has an excellent blog post with detailed information.
Lastly, if you would prefer to stay entirely in Ruby, it's definitely doable. Ryan Stout discusses scalability around persistent connections in the FAQ for Volt, which uses a persistent connection for every user. The article he links is also a great read. Just mentioning it to help you weigh the trade off of building a separate app in another language.
I am building a ruby on Rails 4 app. The web version is ready and I would like to set up/learn how to build mobile apps.
I know and read in many many articles that the "way to go is to use rails-api and feed json to the various clients".
But I'm not sure it's the best fit: I don't want to use it only because it's popular. I want to understand why (if it is) really necessary.
I'd like if possible to build a "beautiful monolith" as explained here.
DHH (core creator of Rails gem) use in Basecamp this beautiful monolith strategy, an hybrid approach which he states is the number 1 time-saving tactic they use to be able to maintain with few developpers numerous web and mobile apps.
Basically you keep your Rails controller, Rails models and everything in your Rails app and rails app and you use a phonegap container to inject in web views the views. You only change this way the views (with Rails 4.2 variant).
https://signalvnoise.com/posts/3766-hybrid-how-we-took-basecamp-multi-platform-with-a-tiny-team
So with this strategy, let's take an example where we need to the database data. for example if someone loads my mobile app:
- the webview 'homepage' on iphone will load ex: views/phone/projects/show.html.erb:
say I need to display the name of the user in this page, the app will go fetch it on /app/controllers/homepage_controller.rb and this controller will have a method like #users = User.find(id)... (active record)
so IT WILL GO HIT THE standard DATABASE (without needing any api or json)
So when I asked 'I'd really want to know why people sue rails-api/josn to know if I really must use it, or if I can use DHH hybird approach', here what people say
80% of start ups use it => blah...not a reason enough. I'd like to know why I should do it.
you can't do "single page apps" and ajax calls without API/json
Here I checked and it's incorrect: as explained below, you can totally use ajax in a webview can totally do it via whitelisting:
http://www.telerik.com/forums/$-ajax-not-working-on-android-devices :
When you are developing a Cordova powered hybrid app, you do not need to make CORS requests. Regular XHR requests will work without a problem. The reason for this is that a mobile app is executed from a file URI and does not comply to the cross origin policy. Mobile apps have an alternative to this policy which is called domain whitelisting.
Are pure and traditional Ajax Requests possible on native / hybrid mobile apps?:
PhoneGap apps run in webview not in browser, so cross origin is not an issue with PhoneGap apps, you can perform AJAX calls to any URL. The only thing to care of is that there is a white list parameter "access origin" in config used to restrict the access to some specific URLs.
So if I follow DHH hybrid approach to keep my Rails app but change the views on the web/iphone/android views and use my database data WITHOUT any API or json, is it possible?
What does API/json really bring to the table, why would they be really necessary, explaining most large multi clients app use them? Can't each of my various apps (web app, mobile app, tv app) just hit the database without any API/json ?
I might be missing something obvious so please advise.
This question does not really suit stack overflow, as the answers can be very opinion-based and also depend on what YOU really want to achieve. However, I will have a go:
Your first question:
So if I follow DHH hybrid approach to keep my Rails app but change the
views on the web/iphone/android views and use my database data WITHOUT
any API or json, is it possible?
Yes this is possible. Note that it will not be a 'native' app on the mobile device, and many people consider such 'apps' to be inferior (since they are not really apps installed on the device). The big advantage of course is that you don't have to learn how to write a native mobile app (and an API for it to talk to). The other big advantage is that you only have to maintain one code-base (models and controllers) for serving all users. You should really google native apps versus non-native to see the full picture.
Your next question:
What does API/json really bring to the table, why would they be really
necessary, explaining most large multi clients app use them?
Separating the API out from the 'front end' part of your code base allows you to have different teams develop different frontends. So you might have a mobile team that focuses on building a very polished mobile native app. You can also have a backend team focus on the API. So for larger enterprises this makes a lot of sense. The API is also more easily scalable - you can have multiple servers running the API and as more 'frontend users' connect (whether form mobile or web or whatever) you can bring up more copies of your API to serve their needs. The other option you have is to easily open-up your API to 3rd party developers if the need arises. That would be a bit harder with the DHH hybrid approach. Not impossible, but harder.
Your last question:
Can't each of my various apps (web app, mobile app, tv app) just hit
the database without any API/json ?
Yes, of course. This is really the same question as the first. Your different views would be serving different 'frontends' (basically HTML/JS/CSS) for the different clients. But they all hit the same controllers/models and hence database. Just don't forget that all your clients are HTML based. Most mobile/tablet users don't like having to open a browser to use an 'app'. They want the native experience (same goes for tv boxes, consoles etc).
By the way, there are ways to develop mobile apps that share one-code base (see appcelerator.com for example). But that's yet another, and different, approach!
We are planning to make a "large" website for I'd say 5000 up to many more users. We think of putting in lots of real time functionality, where data changes instantly propagate to all connected clients. New frameworks like Meteor and DerbyJS look really promising for this kind of stuff.
Now, I wonder if it is possible to do typical backend stuff like sending (bulk) emails, cleaning up the database, generating pdfs, etc. with those new frameworks. And in a way that is productive and doesn't suck. I also wonder how difficult it is to create complex forms with them. I got used to the convenient Rails view helpers and Ruby gems to handle those kind of things.
Meteor and DerbyJS are both quite new, so I do expect lots of functionality will be added in the near future. However, I also wonder if it might be a good idea to combine those frameworks with a "traditional" Rails app, that serves up certain complex pages which do not need realtime updates. And/or with a Rails or Sinatra app that provides an API to do the heavy backend processing. Those Rails apps could then access the same databases then the Meteor/DerbyJS app. Anyone thinks this is a good idea? Or rather not? Why?
It would be nice if anyone with sufficient experience with those new "single page app realtime" frameworks could comment on this. Where are they heading towards? Will they be able to handle "complete" web apps with authentication and backend processing? Will it be as productive/convenient to program with them as with Rails? Well, I guess no one can know that for sure yet ;-) Well, any thoughts, guesses and ideas are welcome!
For things like sending bulk emails and generating PDFs, Derby let's you simply use normal Node.js modules. npm now has over 10,000 packages, so there are packages for most things you might want to do on the server. Derby doesn't control your server, and it works on top of any normal Express server. You should probably stick with Node.js code as much as possible and not use Rails along with Derby. That is not to say that you can't send messages to a separate Rails app, but since you already have to have a Node.js app running to host Derby, you might as well use it for stuff like this.
To communicate with such server-side code, you can use Derby's model events. We are still exploring how this kind of code works and we don't have a lot of examples, but it is something that we will have a clear story around. We are building an app ourselves that communicates with an email server, so we should have some real experience with this pretty soon.
You can also just use a normal AJAX request or send a message over Socket.IO manually if you don't want to use the Derby model to do this kind of communication. You are free to make your own server-side only routes with Express along with your Derby app routes. We think it is nice to have this kind of flexibility in case there are any use cases that we didn't properly anticipate with the framework.
As far as creating forms goes, Derby has a very powerful templating system, and I am working on making it a lot better still. We are working on a new UI components feature that will make it possible to build libraries of self-contained UI widgets that can simply be dropped into a Derby app while still playing nicely with automatic view-model bindings and data syncing. Once this feature is completed, I think form component libraries will be written rather quickly.
We do expect to include all of the features needed for a normal app, much like Rails does. It won't look like Rails or work like Rails, but it will be similarly feature complete eventually.
For backend tasks (such as sending emails, cleaning up the database, generating pdfs) it's better to use resque or sidekiq
Now, I wonder if it is possible to do typical backend stuff like
sending (bulk) emails, cleaning up the database, generating pdfs, etc.
with those new frameworks. And in a way that is productive and doesn't
suck. I also wonder how difficult it is to create complex forms with
them. I got used to the convenient Rails view helpers and Ruby gems to
handle those kind of things.
Also, my question is not only about background jobs, but also about stuff one can might do during a request, like generating a pdf, or simply rendering complex views with rails helpers or code from gems. –
You're mixing metaphors here - a single page app is just a site where the content is loaded without doing a full page reload, be that a front end in pure js or you could use normal html and pjax.
The kind of things you are describing would be done in a background task regardless of the fornt-end framework you used. But +1 for sidekiq if you're using ruby.
As for notifying all the other users of things that have changed, you can look into using http://pusher.com or http://pubnub.com if you don't want to maintain a websocket server.
So, this may be a kind of dumb question, but I checked the Google and got no hits. We want to host multiple Rails apps in a way that makes them look homogeneous. We want all the apps to have the same look and feel, and all the apps to use the same sign-on database.
Theming I think we could accomplish by just putting the site theme into a gem, and requiring that gem from our github repository in each app. However, auth is trickier.
I know that I can achieve this "for free" by just not making the different portions of the site (store, chat forums, etc.) different apps. If they're all, say, Rails Engines, we can basically drop them into the same application with their own namespaced routes, and have a single plugin that does auth.
However, for various reasons we'd like to keep these separate apps, if that's technically possible. The number one reason is scalability; since this will be a hosted site, we want the flexibility to spin up more instances of, say, the store (perhaps to handle a holiday sale rush), without needing to spin up the chat forums. Also, we want to be able to completely isolate the portions of the code that AREN'T intertwined.
Ideally, the databases would be separate too (keeping us from falling back into the rut of "put everything including the kitchen sink in the db"), but I do know that one "cheap" way to do cross-app auth is just to use the same plugin (say, Devise), and just point to the same DB.
So, I'm thinking that maybe the way to do this is to auth via a web service call. Is this prior art -- does anyone have a gem for this that "just works" so that authentication can be shared across all apps? Or am I just entering into a world of pain by trying to build things this way?
Thanks in advance!
You could do a single sign on approach described at:
http://blog.joshsoftware.com/2010/12/16/multiple-applications-with-devise-omniauth-and-single-sign-on/
The single sign on approach with oauth and devise has some drawbacks. The main problem I had was I was unable to extend the timeout time across multiple apps.
I;m a developer looking to make an app similar to chat roulette. I'm pretty comfortable with Ruby on Rails as my platform and would like to program it in that.
The downside is I have no idea about how to do anything using webcams.
Is there a plugin or gem for rails that integrates webcams easily?
Some quick browsing brought me to abobes site...but I haven't used it before, and though I dont mind learning new things, I'd like to get this out quickly so I'd rather stick to what I know.
What you do you use for webcams?
You would have to use a third-party plug-in to interface the webcam with the site. Rails takes care of things on the back-end (finding and connecting users) but you would need to use Flash or something similar to connect the web page with the camera.
This question is pretty old, but we've been able to use headshot gem in one of our apps.
https://github.com/diwadm/headshot