So I cant test Firebase using k6 http requests. I’d need to import firestore js packages and use those to make the requests.
Obviously those js packages do something to get the data, and it seems like they just do HTTP requests.
There seems to be a REST API docs, but I am not familiar with firestore.
A quick google search found this blog on how to use it with axios (which is mostly irrelevant).
Depending on your use case just writing some helpers using the k6/http calling the REST API will likely be enough.
But you will have a lot more problems if you just want to use the firestore js SDK. Again they will need to somehow do the requests and this likely will mean using the Fetch API, which is not supported by k6.
I would expect you will be able to polyfill it somewhat, but I am not certain how much work that will be beyond the smallest of examples and likely it will not be easy ;). Also I can’t find the firestore js SDK (easily) so can’t tell you if modifying that will not be easier.
On the other hand - what exactly do you expect to load test? Firestore itself? Google likely has clauses against load testing it’s infrastructure and this likely will cost you a pretty penny even if they do not (or don’t flag you ).
So I am not particularly certain if you even should be doing this .Maybe a bit more info on what you want to achieve will help us.
I just wanted to raise your awareness @vaporware that Firebase bills by the request volume, if I’m not mistaken, and that load testing your Firebase-backed systems might incur potentially much higher costs.
You’re probably already aware of it and got this plan, but I just wanted to make sure it’s said to avoid potential assumptions and mistakes leading to the kind of horror stories I heard of during my years using it.
Not sure if Firestore uses the fetch api but it’s a good bet.
Which means writing a bunch of code to polyfill or use the REST api like you mentioned.
Our app is used at an event, and I want to simulate running the entire event. When we had a Ruby backend K6 was great for running scenarios against the api.
The Firebase docs say something like 10,000 requests/second so really I shouldn’t be concerned with scaling overall. There are idiosyncrasies though. E.g. Firebase can’t update the same doc more than once per second.
I just don’t want to miss anything. We’ve crashed our server in the past and it’s such a pain during the event. I want to be prepared.
But to your last point, yeah I’m basically asking about stress testing the firebase server. I didn’t realize they don’t like that, so thanks for the heads up.
I did run a quick test using our app. Created 5k docs in about 1 minute, which def is enough for our use-case.
@vaporwave In my experience, the firebase stack is excellent.
But I find it shines in certain kinds of scopes: rather small web or mobile applications with a limited supply of development time that can be easily traded for money. It’s, however, quite costly, and its APIs and SDK are quite opaque, huge, and sometimes a bit too opinionated for my taste. I used it in the past for a personal project, and would do it again though: it’s great when you want to actually focus on getting your project out the door, rather than have to build a whole infrastructure. There are good alternatives for the mobile use case now, though: apple, mongo atlas, AWS (I think it does that too now), etc…