I am using the Firebase Cloud Messaging to send message to my app. I am thinking about using is to also send data from my app to my server, but I am not sure if there is any advantage in using that over a classic HTTP REST api.
I am better of sticking with a classic HTTP api to send message from devices to server, or is using a Firebase upstream message better in some ways?
The "official" advantage of an upstream FCM message, at least on Android, would be that no additional network connection is needed, resulting in performance and battery-saving benefits, and possibly easier implementation.
Depending on how you authenticate users I see a potential simplification in the case of FCM, as you may not need a separate authentication mechanism compared to a REST API.
Related
I'm making a mobile app using flutter and firebase.
To use Cloud Messaging of firebase, I need to send server key of firebase by putting in headers and sending with http post method.
headers: {
'Authorization': server key
}
However, it is not a recommended way to use server key. Firebase recommends to download json file of service account and use that file to get JWT token from firebase. Otherwise, I have to use Admin SDK and it's difficult for us because we don't have a backend server.
Therefore, my question is that are there any good ways to store json files in client side or local environment or firebase or Azure and can read the file only when we need it.
Plus, if you know the better way to send FCM from client side, please let me know. Thank you so much for reading it.
I have to use Admin SDK and it's difficult for us because we don't
have a backend server.
You can very well use the Admin SDK with Cloud Functions for Firebase, the "serverless framework that lets you run backend code". It is very common to use Cloud Functions to send message requests to the FCM backend, which then routes messages to client apps running on users' devices.
There is actually an official example that demonstrates how to send an FCM notification from a Realtime Database triggered Function. You can adapt it to be triggered by any other available trigger mechanism.
I'm working with a service that will forward data to a URL of your choosing via HTTP POST requests.
Is there a simple way to publish to a Pubsub topic with a POST? The service I'm using (Hologram.io's Advanced Webhook Builder) can't store any files, so I can't upload a Google Cloud service account JSON key file.
Thanks,
Ryan
You have 2 challenges in your use cases:
Format
Authentication
Format
You need to customize the webhook to comply with the PubSub format. Some webhoock are enough customizable for that but it's not the case of all. If you can't customize the webhook call as PubSub expect, you need to use an intermediary layer (Cloud Functions or Cloud Run for example)
Authentication
Directly to PubSub or with an intermediary layer, the situation is the same: the requester (the webhook) needs to be authenticated and authorized to access to the Google Cloud service.
One of the bad, and possible, practice, is to set allUsers authorized to access your resources. Here an example with a PubSub topic
Don't do that. Even if you increase "your" process security by defining a schema (and thus to reject all the messages that aren't compliant with this schema), letting a resource publicly, and without authentication, accessible on the wild internet is criminal!
In the webhook context (I had this case previously in my company) I recommend you to use a static authentication (a long lived authentication header; not a short lived (1h) as a Google OAuth2 token); an API Key for example. It's not perfect, because in case of API Key leak, the bad actors will be able to use this breach for a long time (rotate as soon as you can your API Keys!), but it's safer than nothing!
I wrote a pretty old article on this use case (with ESPv2 and Cloud Run), but the principle, and the configuration, is almost the same on API Gateway, a Google Cloud manage services. In the article, I create a proxy for Cloud Run, Cloud Functions and App Engine, but you can do the same thing with PubSub by setting the correct target URL.
I'm building a web app with Laravel for scheduling emails and when I was checking out the competitors, I noticed that one of them is using only one endpoint for all the requests and sending different payload in the POST request.
I thought of building my app's API the same way but I really don't find the use of this point.
I noticed that one of them is using only one endpoint for all the requests and sending different payload in the POST request.
It's a common approach to use when you want transport agnostic messaging. See, for example, SOAP.
I do have some data stored in my Real-Time Firebase database. I am willing to expose some of this data via a REST API to my B2B customers.
I know that Firebase is itself a REST API but its authentication mechanisms don't fit my needs. I am willing my customers to access the API with a simple API Key passed in the HTTP request headers.
To summarize, I need an API layer sitting on top of my Firebase real-time database with the following properties:
Basic Authentication via an API key passed in the HTTP request headers
Some custom logic that makes sure customers respect the API limits (maximum requests per day for example)
The only thing I can think of is implementing this layer in AWS lambda but that also sounds a bit off. From the lambda, I would have to access my Firebase database and serve that data. That seems too many network requests; something native to Firebase would be great.
Thanks,
Guven.
Why not have a simple API which provides them an Oauth token for the original firebase REST API if they have the correct Api Key
It'll be more secure as only you'll be able to make the tokens as only you'll have the service account private key. Also saves you the headache of making a whole REST API. Also the Oauth tokens expire relatively quickly so it's less of a risk than a normal key that you furnish
I personally have created my own Servlets where a user posts their data if they are authenticated using an id pass combo.
In the Servlets i use the default REST API provided by Firebase with the Oauth generated in my servlet. This way, i can have the DB security rules set to false for all writes from any client api. And the REST API and their admin sdk on my server ignore the security rules by default.
After some research, I have decided that AWS is the best platform such API related features.
Gateway API lets you setup your API interface in a matter of seconds
DynamoDB stores your API data; you can easily populate the data here
AWS Lambda lets you write the integration code between Gateway API and DynamoDB
On top of these, the platform offers these features out of the box:
Creation & handling and verification of API keys for authentication
Usage plans to make sure that API consumers don't exceed your API usage limits
Most of what I was looking for is offered in these AWS services.
I'm new to whole live data broadcast. I'm creating a website on laravel 5.1, and I need to get live data from a REST API, and after making some changes, broadcast the result to my own users.
I'm using pusher to broadcast data to my clients. and I figured, I should use Guzzle and/or CURL to get data from API. but the part I don't understand is how to get live data from API? Is there an option in guzzle that will keep the connection open continuously,or should I create a job to execute guzzle code every few seconds?
I know we use websockets to create a persistent connection between the server and clients to broadcast live data. but how to create a persistent connection between API server and my server to transfer the data?
Thank you friends in advance, appreciate any help :)
It depends on an API that you are using. If it's an usual REST API, then there are no options to make a "live" catching. Only pull the API periodically.
You API provider might support webhooks, websockets or some other technologies for push model. Depends on a provider, as I said before.