Most of "bigger" project I was working with was using REST API for Frontend->Backend communication. I was using Firebase Cloud Firestore for some small (one-day/hackathon) projects. Now I'm thinking about using Firestore for some bigger project but I'm not sure if this will work.
For "standard", REST api project I had Swagger documentation, where each developer could see list of all endpoints with request/response data structures. How does it work with Firestore? Can I create similar documentation for developers to check data structure, so they will know what can they add and what should they read? Or maybe there is another way?
I'm thinking, maybe there is no tool for this kind of documentation because frontend data structures are defining database structure? But what if I am connecting database from two or more platform (ex. web, mobile and cloud functions)? How can I synchronize knowledge about data structures between all the developers?
I was looking for some answers but couldn't find anything useful expect advice to manually maintain some documentation. How does it work in your projects? Is there some automation? Manually written documentation? Or no documentation - everything "in code"?
I understand your concerns, but unfortunately, there is no such tool available for Cloud Firestore to generate the documentation for database structure as Swagger.
I believe you can do it programatically.
From
Generating Swagger Docs in Firebase Cloud Functions project
I'm using express and nodejs in my Firebase Function implementations, and for me, Swagger doc generation can be implemented via the following libraries:.
https://github.com/scottie1984/swagger-ui-express
https://github.com/Surnet/swagger-jsdoc
You can find other libraries at:
https://swagger.io/tools/open-source/open-source-integrations
In addition to the responses there, the following service allows you to access Firestore metadata, click the explorer tab, looks promising for your use case https://aapi.io/api-directory/Google_CloudFirestore_GoogleCloudFirestoreAPI_v1beta1 though not necessarily more so than the links above.
Related
There are multiple companies using one application. So I want to have, or know if this is the best way, to create a project for each company, all this with the Firebase API, to create everything programmatically. But I think this is too difficult to do and get that structure. The truth is that the documentation about the Rest API to create projects is not very clear and I am getting lost. One of the things that I want to structure projects like this is to know how much use is made of each project, calculate requests and use of storage. But I don't know if there are other ways to do this.
It's not possible to create a new project for Firebase using the Firebase API, what is possible is to list projects, and create/list apps within an existing project using the Firebase Management API.
For monitoring usage, you can use Cloud Monitoring to assess the usage of each individual app, per service.
I'm working on a product which uses Firebase as its backend. Since firebase exposes the API keys to the user so that could be a security issue. So, after doing some research I've set the database security rules along with API keys restrictions.
But, now I'm unable to use it in local development as well. I was thinking of creating another firebase project and use that as a testing environment and use the existing one as production.
Since the existing project has a lot of data and users. I want everything similar in the new firebase project as well. But I'm unable to find an efficient way to do so. Can anyone please suggest what would be the best option here? Should I create a new testing environment or is there a way to allow me to use the keys locally without it causing a security concern?
Any help would be great. Thank you for your time.
There is no specific command to replicate one project to another, but you can build the necessary functionality yourself with each product's APIs.
For porting users between projects you can use:
The Firebase CLI, which has auth:import and auth:export commands.
The Firebase Admin SDK, which has commands to list all users and import a list of users.
For transferring data between the projects, you can use the API of the relevant database to read/write the data.
Will it be a good idea to create a completely "serverless" app using Appsync/Firebase when fine-grained access control is necessary?
I tried to build an app with Firebase, and then with AppSync and it feels like these solutions are kind of crippling me, and I started to think that maybe im still thinking in the "old" way of solving the problem, and that's what is crippling me and not the tools.
Where im struggling is with access control.
Firebase has "Firebase rules" and AppSync has "VTL"(Apache Velocity Template Language), both offer relatively good solutions, "Firebase rules" is easier and cleaner, but VTL is more robust because it is basically a programing language.
The problem is that im trying to give the user access to documents on the database based on a "collection/table" of permissions. So each user has a document inside that "collection/table" with fine-grained permissions, and I need to read that document in order to know if he has access to the resource he is trying to read/write.
With both, firebase and AppSync I can read the DB, but both have their limits:
Firebase Rules has request limits. and that is problematic if a user
has multiple "permission groups".
AppSync is more flexible, but still limited, and I rather use my language of choice rather than VTL if im going to write some logic. And in addition, I rather have that code inside my project locally than only in the cloud accessible via the GUI.
So, in the end, it feels like both solutions drive me into having another layer before them in order to do more complex stuff, so it can either be functions or an entire app.
But then, why do I need all of their APIs? Having another layer before Appsync/Firebase basically forces me to reimplement GraphQL/Firebases API, and then, why not build it using another tool?
So, am I doing it all wrong? Will it be better to have an app deployed on AppEngine or a similar solution(and thus losing the advantages of functions)?
Note: Im sorry if after all this reading its still not clear, English is my first language.
AWS AppSync added Pipeline Resolvers recently, which sounds like a perfect solution for your use case. You compose the GraphQL resolver with a chain of Resolver Functions. Your auth check against the document collection table can be implemented as a reusable function.
Take a look at the Pipeline Resolvers tutorial to see if it meets your needs.
All my app's data is stored in Firebase. I'd like to build some reports with my data that aren't necessarily accessible through the web/app front-end. I don't see any good options for this in the Console. Has anyone found a good reporting solution for Firebase? I am looking for something like Crystal Reports or just an easy way to render Firebase data based on a query.
Thanks,
Rima.
I found a issue with the solution above. Firebase stores its data in JSON format, which cannot be consumed by solutions such as BigQuery, because it is expecting JSONL format and you get an error. It beats me why Google are not providing an elegant solution when integrating between two of their products, but I believe they have something planned.
Firebase does not have any "built-in" reporting tools other than the defined querying APIs.
If your database is small, you dump the JSON from the Firebase Console and then manually run analysis on it.
If your database is large, you can upgrade to the Flame or Blaze plans and sign up for daily private backups. This will create a JSON dump in the background without affecting your database performance and store it in the cloud. You could then use tools to grab that dump and perform advanced reporting on it.
1) Via BigQuery
Official Docs:
https://cloud.google.com/bigquery/docs/loading-data-cloud-firestore
Codelab Walkthrough:
https://codelabs.developers.google.com/codelabs/modern-data-pipeline-firestore-bigquery-dataflow-templates/index.html?index=..%2F..next17
Connect whatever BI tool you want to BigQuery. Google Data Studio is
free as is Metabase. Almost every Enterprise BI tool has a BigQuery
connector.
From https://www.reddit.com/r/Firebase/comments/arps42/reportingbi_tools_and_firestore/
2) Via "Custom Data Sources"
Cloud Firestore (and probably Realtime-Db) has a RESTFUL API. Many popular reporting tools support "custom", "restful", "ajax", and/or "HTTP" sources.
You should search your favorite reporting tools, and internet search accordingly.
I can see that Stimulsoft seems to support custom/RESTFUL sources. A PowerBI data connector seems to provide a lot of latitude - https://github.com/Microsoft/DataConnectors
Of course, this means that you need to create several data sources, and they probably won't be as optimised as a built-in source type. For example, the report engine probably won't know how to translate any front-end UI filters into custom-source query filters. Perhaps some platforms support the ability for you to create your own adaptors.
I have two production apps that are currently using Parse.com. I have no plans on using Parse server, and I wanted to switch to the firebase service. I was wondering if there was a way to migrate my database from Parse.com to Firebase
There are differences between Parse and Firebase that makes a straight migration not as easy as you would hope.
Parse is based on a relational database, where as Firebase stores all it's data in JSON - thus a "copy and paste" job isn't going to work here.
On top of that the way that the two platforms organise user authentication is completely different.
So unfortunately no easy solution here.
Firebase has a import JSON option so if you get your data out of Parse.com as JSON, it can be imported.
However, the structure Parse uses to create relationships between data is (probably) going to be different than Firebase, so it's going to take some planning and coding to make the transition.
Once we had a plan, we found it easiest to just craft an importer App that would take the Parse.com data structure, and massage it to a Firebase format that worked for our app.
In some cases we had to start from scratch as the thought process is different from Parse (objects) to Firebase.
Firebase API is completely different from the Parse one. It means that you have to learn other API, SDKs, etc, and rewrite your frontend code.
Does not exist an easy path to migrate from Parse to Firebase.
Moreover I think it is not a good decision. Parse Server community is growing and it is becoming even better than original Parse. In a short time, Parse Server will become the best framework for backend and API development.
My recommendation to you is to migrate to a Parse Hosting provider. Using this kind of solution you will use same Parse APIs and features. It will not require you learn other technology nor rewrite any frontend code.
You can find some options in parse server repository:
https://github.com/ParsePlatform/parse-server#parse-server-sample-application
For a full disclaimer, I am co-founder of https://www.back4app.com that is the first parse server mover.