Work on an app like uber for a graduation project with flutter
There will be two separate applications, one for the driver and another for the user, and we use firebase. How do I make the user application send the driver data such as: address, and so on, to be in contact between the two applications in general
please help me thanks
Just add Firebase to the two applications. And make sure you have the same models class (at least a common base).
Eg. You share the same graduation.dart file targetting same firestore collections named graduations. So you will be able to manipulate graduations collection documents in the two applications.
Related
I have seen a firebase api in which you can create firebase projects and it occurred to me for example, when a user wants to counter a SaaS, make it easier for me to create a project and connect it to their SaaS but I have the following questions:
If there are supposed to be limits to creating firebase projects in a google account, will there be a time when databases can no longer be created for new users?
If the above is true, how can this be solved?
I have seen that you can ask for more projects, but how many can I have?
I know that with firestore, I can model data and only in a database have all the information, but for example, each user may have special requirements in their system and also provide security and information saving operations that would be impossible if all information is in a single database.
Thanks for the help.
EDIT
"How many projects can you have as a developer?" Yes, that's what I mean, having all the user bases in a single firebase google account. For example, on a web page, the user wants to pay for the application, with firebase admin and google cloud functions, I can automatically create a project and have all the databases in a google account. And what I want to know is if you can have multiple databases. I have seen that you can ask google to give you permission to host several projects but, for example, can you have more than 100 projects or even 1000? (I may never have reached that number, but in that case, I would like to know the limits that can be reached).
Edit 2
This first structure I have all the documents in a "universal" collection and I identify them with an id to know the user who used it.
But the second structure seems to me more organized and clean, in addition to the fact that users at no time need to share information among others. I have read that having nested collections is not good but over the years and the progress that firestore has had, this is no longer or was a problem only that the limitation is that you can only have up to 100 collections anidades but I never think to reach that quantity.
Inside of list, have all products for that user, because inside of document, only can have 1 mb of data and download 1 mb and is not the best option.
in the firestore documentation I see that it does not reveal other problems, it only says that it is difficult to delete the subcollection, but I do not allow users to do that and if I need to delete the subcollections, with the Google Cloud functions i can do it.
So, the second structure is more intuitive for me, but is the best option for that? or actually firestore is not good for this strcucutre?
I am considering building a Firebase + Flutter framework to small business solutions.
By providing a fairly high level of security, Firebase + Flutter seems quite good for a number of business applications especially based on Android.
However, for this to make sense I have to solve a few problems and I will be very grateful for help in any of the points below.
Is it possible to connect from within a firebase database via VPN
(mainly OpenVPN) to another database via odbc and/or through
webservice (strongly preferred odbc)? The goal is to connect
firebase with local databases in companies - especially MS-SQL
databases (mainly small ERP / WMS system). If this is not possible,
how can an equivalent effect be obtained? I also need a connection
from firebase to firebase to automatically download changes to the
framework from the main repository.
Many governmental and commercial systems require signing files with
a signature based on X.509 (mainly * .pfx, * .p12 password
protected). I would like all such a signature to be implemented on
the firebase server side (possibility of managing such
certificates). Are there appropriate libraries in firebase to sign
content in accordance with X.509? If not how to get the effect of
signing content in firebase + flutter and strongly prefer that the
certificate was not on the client.
In several places on the network I met the possibility of logging in
using a certificate compatible with X.509 or identical, but I do not
see such an option for selection in the panel in firebase? Is
X.509-compliant login support by Google in Firebase, and if not,
could I ask for a step-by-step link on how to handle it yourself in
two variants: a) external certificate , b) automatically generated
certificate by the client application.
Thank you in advance for your support
The subject of this question is so broad that I don't think its possible to answer on StackOverflow.
Generally Firebase is a set of cloud functionalities including databases, functions, authentication (and many more) that can be used in your mobile apps. One of the technologies that you can use Firebase with, but not only one, is Flutter which is engine using Dart programing language. But there are a lot of API from other programing languages like Java, JS, Python and many more. They might be different depending of the product you choose from Firebase.
Now pointing to your questions:
I am not sure what do you mean by "connecting from Firebase", but I suppose you mean connecting from your app. If you build the app in Flutter you will use Dart and it has VPN support of course like here.
Although I don't know much about X.509 I have found that dart will support it as well here example.
Authentication is one of Firebase enter link description here products. You can find there also custom authentication possibilities
I think all you asking is possible, but of course there is no simple answer for it. I hope it will help you.
I'm trying to determine if I can use Realm DB for an app I am building and I am stuck on access control.
In the Realm DB documentation it looks like the only way to do access control is through Realms themselves, by either granting or revoking access to an entire realm. The documentation also says to try and keep the number of concurrently open and syncing realms to about 12. I am trying to build an app with a social feed where users can "follow" each other, and you could potentially follow hundreds of different users. You see very little data, just their activity, so there is not much actual data going back and forth, but you should only have access to view that data if the other user lets you follow them. I am thinking of it being like each user having a "private" realm and a "shareable" realm that they can grant other people access to. Is there any way to do this with Realm DB that doesn't involve syncing hundreds of different realms?
At the moment, there is no other way than syncing hundreds of Realms.
There will be another way in the future where you can use partial
synchronization.
https://realm.io/docs/java/latest/#partial-synchronization
I am in the process of developing a web based solution do replace an application we provide. The web application is a record storing application and each client would have different forms they would input data into and store. My question is: Is it possible to create a backbone Web Project, which would have minimal updates this would be like a container and be the same for all of our clients, and have the document forms which would be different among clients and need to be updated more often.
Any constructive comments for or against this with reason why would also be appreciated.
It sounds like what you’re describing is a multi-tenant system if you'd like to do some research on that term. Your web interface remains the same for all, but the records/documents are different for each client. It sounds like you might need login/access functionality that ties the records to a client ID (possibly stored in a database). According to how you intend to store the records (file system vs. database), you can control access either based on the client ID (foreign key to the doc tables) or you might want to create roles. This is a very high overview for what can become complex according to the specs.
I am planning to develop a fairly small SaaS service. Every business client will have an associated database (same schema among clients' databases, different data). In addition, they will have a unique domain pointing to the web app, and here I see these 2 options:
The domains will point to a unique web app, which will change the
connection string to the proper client's database depending on the
domain. (That is, I will need to deploy one web app only.)
The domains will point to their own web app, which is really the
same web app replicated for every client but with the proper
connection string to the client's database. (That is, I will need to
deploy many web apps.)
This is for an ASP.NET 4.0 MVC 3.0 web app that will run on IIS 7.0. It will be fairly small, but I do require to be scalable. Should I go with 1 or 2?
This MSDN article is a great resource that goes into detail about the advantages of three patterns:
Separated DB. Each app instance has its own DB instance. Easier, but can be difficult to administer from a database infrastructure standpoint.
Separated schema. Each app instance shares a DB but is partitioned via schemas. Requires a little more coding work, and mitigates some of the challenges of a totally separate schema, but still has difficulties if you need individual site backup/restore and things like that.
Shared schema. Your app is responsible for partitioning the data based on the app instance. This requires the most work, but is most flexible in terms of management of the data.
In terms of how your app handles it, the DB design will probably determine that. I have in the past done both shared DB and shared schema. In the separated DB approach, I usually separate the app instances as well. In the shared schema approach, it's the same app with logic to modify what data is available based on login and/or hostname.
I'm not sure this is the answer you're looking for, but there is a third option:
Using a multi-tenant database design. A single database which supports all clients. Your tables would contain composite primary keys.
Scale out when you need. If your service is small, I wouldn't see any benefit to multiple databases except for assured data security - meaning, you'll only bring back query results for the correct client. The costs will be much higher running multiple databases if you're planning on hosting with a cloud service.
If SalesForce can host their SaaS using a multitenant design, I would at least consider this as a viable option for a small service.