Closed pdw207 closed 7 years ago
I was discussing with @InciteDemocracy the possibility of using something like https://redis.io/ to cache the FB API responses, and then the front end hits redis instead of FB. This way we only hit FB every few mins or whatever, and redis takes the hits.
This would probably take more server side work than I would immediately be able to do, so if anyone here is a back end dev, then maybe this is something they could tackle? I also have a friend who might be able to help with this, so I'll reach out to him.
@november9 Redis makes sense.
Hey hey. I think we've been having parallel conversations about the backend architecture. We've created an MVP document to capture some of the ideas, so maybe we can discuss there.
I've included this idea there as well. https://docs.google.com/document/d/1XGZmkcMDXteGJqf9dL0KY7_OUEmkIVleN7OAgWDWM2o/edit#heading=h.i7uqrxxwx5ls
I stood up a back end node server over the weekend that makes FB calls and returns them in OSDI events format. I need a legit FB app, but I can get something more reliable set up this week.
Howdy, I'm @november9's friend. I'm happy to help with the project. I think we could easily setup a caching worker that reads the event and dumps to something like redis. If you host this on Heroku, it would be scalable.
This is my first time looking at the facebook api. I wanted to talk through some basic issues with the facebook graph api. Sampe here
Could we hit a limit on requests to facebook if requests are made on the client? If so we could have a background service make the request. This adds a little complexity because we need to setup a database and background worker. This was essential what the "event service team" was going to do for us in PHP and allow us to focus on the frontend.
Is it possible for the client to make requests to facebook directly while securing the secret app id?