How to use Firebase built-in features instead of ORM? - firebase

I started using Firebase for Android app with Kotlin. So the question is how to use Firebase built-in features instead of adding ORM? I would like to work with classes and objects, instead of dealing with get, set, onSuccessListener and other firebase methods.. So I can create some semi-ORM by myself, by dividing everything to adapter and models. However is there simpler solution? I assume there should be some built in features in Firebase?
E. g. we can query documents with Firebase functions and map them to classes as per official manual:
val docRef = db.collection("cities").document("BJ")
docRef.get().addOnSuccessListener { documentSnapshot ->
val city = documentSnapshot.toObject<City>()
}
To make controller loose coupled from the database, we can create classes AbstractModel and CityModel and Queries and FirebaseAdapter so finally we can do something like
val city = Cities("BJ")
instead of lengthy code above.
Eventually I see that problem is we need to create our own ORM for using Firebase for every project. Or is there simpler solution? Do some existing ORMs work with Firebase? I did some research, however Stackoverflow policy prohibits to post trademarks into the question.

Related

Should my Flutter App instantiate a new object if I'm using Firestore as a backend?

for the technically-savy people out there. I'm building a flutter app with a firestore backend and I've been doing some research as to the best way to structure my models. Tutorials online show different methods and I can't figure out what's the best one as I want my app to be light but also use Firestore efficiently so it doesn't cost too much.
Those are the ways I've encountered so far:
Have model for the flutter object and another one for the firestore object. Everytime I get the data from firestore I instanciate a firestore object and map it into a flutter object or create a new flutter object and then have a listener there to update my whole app.
Have one model for the flutter/firestore object. Everytime I get data from firestore I need to instantiate it once. No mapping. I have a listener there.
Get the data directly from firestore without needing to instantiate an object and print the documents there, and have a streamprovider to get the data.
I'd really appreciate your help in structuring my app/project. Thanks.
I think you should consider all your requirements, technical and business. The definition of your architecture should entails this needs. If you rush to choose an architecture that in the future would be needed to be re-defined, then it could be more expensive.
Once you have considered this, then you should think in your architecture. Try to share your general workflow.
I want my app to be light but also use Firestore efficiently so it doesn't cost too much.
All the three options you have shared fit to your needs? Is there a step in your solution in which the steps of your three options would fail?
I think you should base the architecture more on your needs than in which is least cost.

Firebase - Admin.firestore vs functions.firestore

I'm newbie on cloud function. I have some confusions.
Is there any difference between admin.firestore and
functions.firestore?
Is admin.database for real-time database?
So if cloud functions are basically written as JavaScript or
TypeScript in Node.js environment, then I can write them with
JavaScript. But documentation made me confused about that. Because
whenever I read the documentation, it gives things different. For
example,
Above code to get a document, it uses document('some/doc').
But, above code it uses doc('doc') to achieve the same functionality. If all of them come form firestore, why do both differ each other?
Can someone help me to understand these questions? Thank you for all your supports.
functions.firestore: is used to set up a trigger. You can set up a listener on a document path so that whenever an event happens on that document (create/update/delete etc.), this function will be executed. See how to create one here.
admin.firestore: is used to create a reference to a firestore database. You can perform various operations on firestore collection/documents using admin sdk through that reference. See documentation.

React redux store issues

I am attempting to pull variables from my backend and store them in the frontend. I have react and redux and the piping is setup but I am having trouble with how to store the variable for access later or accessing the Redux store in other places. I am using these variables as URL endpoints (i.e. for changing servers, etc.) Any help would be appreciated.
You can use React Contexts and do something like this:
const MyVariablesContext = React.createContext(defaultValue);
For the defaultValue you can use an Immutable Object or Make an API/Server call and populate the values. Once they are populated you can use React Provider API to consume it.
You can look into how to use React contexts here: https://reactjs.org/docs/context.html#when-to-use-context
If you could give more context in your questions it would be better. But if you are using recompose then withContext HOC is what an ideal solution would be.

Cloud Functions suitability for Custom Tags

I wonder if Google Cloud Functions are a good solution to the following:
For our apps we like to use Google Tag Manager, just like we do for our sites.
Thing is : on the website GTM, we can implement custom tags easily by using javascript.
In an app that's not possible , it would be possible to call a function that's already compiled inside the app.
But that gives a lot of problems with flexibility, for instance: if an app is already used by many users, we need to deploy a new version if we want to implement a new custom tag to a third party.
I was thinking of Google Cloud Functions as an answer, where by using Javascript, we could implement new tags (in the form of api calls) without redeploying.
Question is : how can you call such function without redeploying? And is this a suitable way of doing this.
Unfortunately, this is not possible without planning it ahead of time and it would likely result in a high LOE instead of just adding the tag and releasing a new version of the app.
You would need to setup your app to be able to detect new tags returned by the cloud function since you're trying to add tags without releasing a new version of the app.
You would then need to come up with a way of tying that tag to a particular view or location within the app. In addition, you would then need to have the right code in the right places to make sure that tag is used properly.
Cloud Storage and JavaScript instances might offer a solution:
I'm going to use iOS as an example, you could potentially use JavaScriptCore.framework to implement this dynamic capability within the app. You could store new JavaScript functions in cloud storage. Then you could use a cloud function to fetch these from Cloud Storage, or you can access Cloud Storage directly from an SDK or URL; you do not even need a cloud function to perform this task.
You would then evaluate these scripts within the app:
JSContext *context = [JSContext new];
NSString *jsFunctionText =
#"var isValidNumber = function(phone) {"
" var myTag = 'new custom tag';"
" /* use JS Tag Manager SDK to deliver tag information."
"}";
[context evaluateScript:jsFunctionText];
This only solves part of your problem though, since you need to be able to add context to where the function should be pulled from and called. So again, you need to anticipate your future needs and could potentially over engineer the solution.
I know it's not a solid answer, but it is not a simple problem to solve.

How to organize/handle DB related queries?

I want to know whats the standard way of structuring DB related operations? Because a structure is not defined in the documentation.
E.g. Have a repoclass and have functions written for getUsername likewise?
That's exactly like that.
Your model only contains the entities skeleton. Everything related to querying data for these entities has to be in a Repository.
From the Cookbook:
In order to isolate, test and reuse these queries, it's a good idea to create a custom repository class for your entity and add methods with your query logic there.

Resources