It would be great to include screenshots in the README!

[mikob]

I can't really tell if this is the kinda "admin" that I'm looking for. Can I see all my collections? Sort them? Search through them? I feel some screenshots would tell future contributors and users this info quickly.

[prescottprue]

Thanks for posting! Going to address the screenshots and the mentioned feature separately:

Docs With Screenshots

The guides section of the docs has a setup guide which has some screenshots, but as mentioned those should be added to the README.

Going to leave this ticket open until either images are added to the README or a link is added to the docs where the screenshots are available

Data Viewer/Search Feature

The current focus has been more on features for migrating/move data since that has been what my team needs. Also, since there is a bit of support for querying Firestore directly within the Firebase console, it didn't seem like a huge value add. Are you talking about more for Real Time Database? Or more complex query capability for Firestore?

All of this said, totally open to a data viewer as a feature - I started to think about this in the past and was thinking it may be cool to also have a reporting type of feature, so that counting objects/documents with specific params etc would be possible.

I created #91 to track the creation of that feature so all of the notes/comments can be in one place.

[mikob]

Thanks for the thoughtful response.

Are you talking about more for Real Time Database? Or more complex query capability for Firestore?

Personally, I'm only interested in Firestore.

Also, since there is a bit of support for querying Firestore directly within the Firebase console, it didn't seem like a huge value add.

It's just too primitive to be useful. I was looking for a project that is something like Django's admin:

Of course it would be slightly different since we're not dealing with a RDBS. But the important things would be list views (configurable), performing actions on multiple items (checkbox selection), searching, filtering and sorting.

[prescottprue]

I love the suggestion! This would be great! Thanks for the screenshot.

The functionality of standard admin interfaces, like Django admin that you mentioned, is the overall goal of this project, so this for sure fits.

I had been thinking about a separate user manager feature for just creating/updating/deleting users as well as managing their role etc. With what we are saying here though, maybe we could make it more general, then it could be used by all types of data?

It is great you are focused on Firestore since that should make things a bit easier because of it's better querying capabilities. Was your focus on User data specifically or just collection data in general?

Side Note

Unless we index data with another tool like Algolia or Elastic Search, much of this type of filtering would happen client side, which may soon become a bottleneck, especially with users with large DBs. That could be possible by asking for settings from the user about their Algolia instance as well as include instructions for indexing Firestore data within Algolia. All of that said, lets start something like this and wait for that to be an issue.

[mikob]

Was your focus on User data specifically or just collection data in general?

I agree with what you said earlier, and user data can just be treated like another collection and really a generalized view would be best.

much of this type of filtering would happen client side,

yes, simplest to start client side. I would surmise that those with massive databases are more likely to have their own custom tools already for browsing through their database. This can, at least at first, be useful to those who have smaller amounts of data that can be all managed client side.

Any opinion on what the client side db/search solution should be like? A full-on db like PouchDB or something like: https://github.com/bvaughn/js-search?

[prescottprue]

@mikob The goal would be to include something like Algolia or Elastic Search so we can filter large sets of data without pulling down the whole collection/path and filtering client side. I say that mostly since a number of the applications I manage, including Fireadmin, are already to the DB size where I wouldn't want to pull a whole collection to do client side filtering. In those cases there is almost always a Algolia instance associated with the project (wondering if this is common with other folks?).

Maybe Fireadmin could offer both? It could start with a client side filtering solution, such as js-search, then if you do extra setup, like providing config settings for an Algolia instance, then the filtering can be more advanced. That way if you are small data sets you get simple functionality, then if you are to the level of needing searching, then managing the data indexing is up to your application (presumably through a Cloud function).

There could also be instructions for setting up an indexing cloud function for sending your data to Algolia since that is pretty easy to do.

Either way, thanks a ton for the input! Really excited about this idea/feature - I know I would use it regularly