Docker and/or Firebase? #78
Comments
|
For MakeMIT 2017, I converted Quill to run on Amazon Lambda. The main issue was that the Mongo Client is designed to be stateful; Firebase Cloud functions, amazon lambda, etc… are designed to be stateless. So, O(1) overhead became O(n-ish) overhead, where n is the # of requests. (“n-ish” because I was able to get creative with caching, so it wasn’t as bad as O(n))
Unless you are going to convert the DB to firebase AND the code to cloud functions, I would advise against because of the performance issues I ran into. But, if you still want to go for it, here’s a good guide: https://hackernoon.com/building-a-serverless-rest-api-with-node-js-and-mongodb-2e0ed0638f47
From: Aaron Osher
Sent: Wednesday, June 13, 2018 7:04 AM
To: techx/quill
Cc: Subscribed
Subject: [techx/quill] Docker and/or Firebase? (#78)
Hey, so I'm already Dockerizing quill (pretty much done with that) and I'll submit a PR once I'm happy. I was wondering would be interested in a firebase port, using Real-time Database or Cloud Firestore instead of MongoDB. I probably wouldn't port it over to use the firebase SDK on the frontend, just to use cloud functions instead, but that's probably dependent on how much time I have to kill.
Thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
That's fair, and I've been digging a bit more around the source code and can see how for larger events it could become a fairly large issue. Moreover, in trying to adapt quill to better suite HackNotts, I've run into a handful of quirks that I can't live without fixing. I'm probably going to take a week or so at some point in July/August and port quill over to Angular 6 with Cloud Firestore and Cloud functions. Angular 6 mainly because I never worked with AngularJS and don't really see a point in learning, and partially because the angular SDK for firebase is only for Angular 2+. Firebase because I'm used to it, and it's cheap. |
|
I'll PR my Dockerfile/Docker-Compose config in the next week or so. |
What particular points do you see being performance bottlenecks? I don't see a reason why anyone would or even should encounter performance problems for a fairly straightforward/lightweight CRUD application with barely any models, even if you have multiple thousands of users and thousands on thousands of hits. |
The bottlenecks come in the sense that Cloud Functions aren't optimized to be used as a REST API for everything, and it's a lot more costly compared to hitting Firestore directly through the SDK–especially as you get charged twice, once for the function call, and then also for the Firestore or RDB hit. In any app where I use cloud functions as an API point is notably slower than direct Firestore SDK calls. |
|
Ah, my misunderstanding - I read your message as if this application as is (no cloud functions) had performance bottlenecks. |
|
@aaronosher any developments on dockerizing quill? If you're able to share a Dockerfile, that'd be great! |
|
@jay-khatri My summer seems to have run away from me. If you head over to the I've linked it here: https://github.com/HackSocNotts/quill/tree/feature/dockerize Edit: I also just submitted a PR to add the Docker functionality #86. |
Hey, so I'm already Dockerizing quill (pretty much done with that) and I'll submit a PR once I'm happy. I was wondering would be interested in a firebase port, using Real-time Database or Cloud Firestore instead of MongoDB. I probably wouldn't port it over to use the firebase SDK on the frontend, just to use cloud functions instead, but that's probably dependent on how much time I have to kill.
Thoughts?
The text was updated successfully, but these errors were encountered: