Decent strategy for integrating with facebook

(Carlos Vergara) #1

I’m thinking of having a forum where all kinds of loosely related people can talk to each other on facebook, in an app which would essentially proxy discourse, and I’m thinking of the best way to actually integrate with facebook so it actually means something. Care to let me know what in here is impossible, stupid, or perhaps just annoying to implement?

What I’m thinking is, having a single and owned (ie not facebook’s) hierarchic users and discussions pool, and giving people the ability to tell other friends about stuff they are discussing, using notifications to let them know when someone posted a topic they care about, using fb messages as the PMs features, and potentially using fb payments to get some kind of premium stuff that might be relevant if it ever happens. Essentially merging this with facebook’s normal communication channels in as many ways as I can.

And now I should mention my problem is I have no clue as to how to integrate all that stuff on Discourse.

I already have a vanilla install working, but I have no clue as to where to hook stuff to try and see if it works, no clue about what facebook’s going to feel about it, and no clue as to what the best case for doing this is going to look like in terms of my hardware. If this idea of mine catches, how do resource requirements change with the amount of users I might have? Say, at which point can I expect to start having to throw hardware at the problem? Can I even just throw hardware at the problem? (I mean, are there any reasons why not to do pretty stuff like pg_sharding and load balancing the hell out of the db?)

Does any of this even make any sense? I’m not sure I’m posting in the right place, but “support” seems to be the closest to what I need. Please, if I’m wrong, do point me to the right places where I could make this questions.

Thank you!

(Jeff Atwood) #2

First of all, I can’t even understand your idea. Can you illustrate it or provide a visual example?

(Carlos Vergara) #3

In a sentence, what I want is to have a forum-ish platform that meshes with facebook and how people use it so that it doesn’t feel weird like just having a Facebook Login button.

My concerns are, I have no clue as to what do I need to do to extend Discourse in that direction, and I have no clue about when and how to spread it along more servers if I ever need to.

Say, if you’ve posted a question like this, whenever someone answers, I’d like to tell you via facebook notifications. If I “PM” you, I’d like to tell you via facebook messages. And so on.

Also, whenever (and if) I ever need to explode the database into shards, can I even do that? Is there going to be a problem?

In a pinch, that’s what I’m trying to find out

(Kane York) #4

Good luck with, um, all of that.

I’ll be very happy if you succeed with any of those.

(Carlos Vergara) #5

What I take from your answer is that none of those things can happen in Discourse’s workflow, and the db might have some real issues. Is that right?

(eriko) #6

I am sure you could build a plugin for discourse and then a separate application that sat between the plugin and facebook that passed information back and forth. It probably would break facebooks rules about api usage and would need to get updated whenever discourse api changed (not to often but it does happen) and facebook changes the rules and api (which happens pretty often.) Facebooks rules are designed to have as much content inside facebook as possible. That way they can use the data to sell ads and more importantly marketing information. Remember if you are not the customer you are the product.

It is not that the database would have issues with sharding. It is that the app is not designed to do that. Even thought there are some large discourse sites my cursory observation is that the rails app that sits between the database and the javascript app in the browsers is the main performance constraint at this point and that can be handled via adding more app servers. If it got to the point where the db was the constraint then it would be possible to adapt to single write, many read databases as postgresql has pretty good support for doing that on the back end. There are some gems like octopus to handles exposing the rails app to this. That said nobody seems to have hit a scale where that is needed. There is the old saw about premature optimization being the root of all evil and this would be a case of that.

(Kane York) #7

Yes, this is the problem that I was alluding to; thanks for spelling it out.

(Fábio Machado De Oliveira) #8

Just thinking in your problem. Facebook may let you post and read user contents if you ask for a lot of permissions when the the user add your application, if your application pass their approval. There are alternative clients for Facebook, so it’s probably possible in their side.

To use discourse with it, the easiest way I can think would be making a program that copies the data from the postgres database to Facebook and vice-versa.

I think it wouldn’t be hard for the hardware. But it will be a lot of work to implement.

Disclaimer: Never integrated anything with Facebook. Just realized how old this thread is now, will post anyway since I already wrote it.