finite reset pagination error at finite pagination

[s1lviu]

Solved with https://github.com/deltaepsilon/firebase-paginator/issues/18 but now:

with

PS: With infinite pagination it works.. but I need finite.

[deltaepsilon]

Finite pagination is tricky!

You usually have to provide your REST API secret, which is risky to expose to the public.

Firestore does MUCH better pagination than the RTDB, but even Firestore isn't good at finite pagination. You'd have to manually track the record count with a Cloud Function... which is a lot of work for a small gain.

It looks like your script is trying to require a package.json file and can't find it. I'd have to step into your code to debug this.

[s1lviu]

And what's your view or approach, @deltaepsilon about making a finite or infinite pagination API with Node based on your module?

Thank you!

[headwinds]

I'll offer my 2 cents and back up @deltaepsilon - at one point I also wanted finite pagination and investigated it but abandon the effort since I too found out you need to keep a count on the server that felt really painful - definitely not worth the effort after reviewing a couple samples.

Instead I made the design decision to show a max of 10 page numbers thinking the vast majority of users would never dig through 10 pages. I also worked more on improving my search so that the results should not exceed 10 pages.

This is going to be hard to hear - because Firebase is awesome for rapid prototyping - but if your production app absolutely requires finite pagination, I'd use a different DB like postgreSQL which is excellent at finite pagination.

[s1lviu]

@headwinds I really appreciate your cents. I want to implement a simple notifications feed with a pagination. I prefer infinite, but I cannot see a firstKey per pagination request, to send as a parameter every time I want to load more results.

I have found an example here, but I didn't get how to do that working.

On the frontend this module I think is ok, but on the backend I find it very hard to implement it as a viable solution. @deltaepsilon what do you think about returning that firstKey to be able to be sent from front-end to the server - in my case Node, for handling the pagination limits?

[deltaepsilon]

I paginate in the RTDB by reading from either the top or the bottom of the list. I don't send a key on the first query. If I want to show 10 records per page, I request 11 records and hide the last one in my client app's logic, but I save the 11th record's key.

When it's time to request another page I make another query with a limit set to 10 records and a last key set to the 11th key.

This system is reliable and lets you read from the top or the bottom of the list. You can't set a sort in the RTDB, so you may have to sort client-side. It's super annoying, but there's no way around it.

The other option is to use Firestore. Firestore has pagination built in and is much easier to query. It scales very differently from the RTDB, so look at the pricing models before switching over. Most use cases are absolutely fine with Firestore. The pricing is roughly $0.06/100k reads. But if you're doing super fast reads and writes, you'll want to stick with the RTDB. They're priced differently and have different performance profiles.

Finite pagination is very annoying to implement. I've designed around it for the last few years. Postgres makes finite pagination easy, so it was a feature of lots of early web apps. But you'll notice that none of the newer apps use finite pagination, probably because querying record counts is just too expensive for the limited benefit.

[s1lviu]

@deltaepsilon about pagination, I think I will stick on approach with the firstKey limit too.

The pagination in firebase was pain for me since few years ago when tried it.

About the Firestore. I haven't used it, but I see on their documentation that have a better approach on pagination than Firebase.

The good part in this is like you said, the infinite pagination trend in web apps.

About your plugin, I think would be great to add an RESTful API for Node with 3 params: order: asc/desc, number of collections/query and first_or_last_key - hope I will find a good approach and I will try to make a PR.

As a conclusion, thank you for your time to discuss these and I think we can let the thread open for future points on this. :)

[deltaepsilon]

Sounds good to me!