Mixing
Retrieve Firebase RD Data with the JS library or Through a NodeJS Server?
I am working on a project that uses the Firebase Realtime Database and I was wondering if it is best to use the JS library to retrieve data from the client side, or use the NodeJS library to take a client request and retrieve the data via the NodeJS server and send it back to the client. Is there any advantages or disadvantages to either solution? (Security, ease of implementation, speed, etc.)
node.js firebase firebase-realtime-database
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
add a comment |
I am working on a project that uses the Firebase Realtime Database and I was wondering if it is best to use the JS library to retrieve data from the client side, or use the NodeJS library to take a client request and retrieve the data via the NodeJS server and send it back to the client. Is there any advantages or disadvantages to either solution? (Security, ease of implementation, speed, etc.)
node.js firebase firebase-realtime-database
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
add a comment |
I am working on a project that uses the Firebase Realtime Database and I was wondering if it is best to use the JS library to retrieve data from the client side, or use the NodeJS library to take a client request and retrieve the data via the NodeJS server and send it back to the client. Is there any advantages or disadvantages to either solution? (Security, ease of implementation, speed, etc.)
node.js firebase firebase-realtime-database
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
I am working on a project that uses the Firebase Realtime Database and I was wondering if it is best to use the JS library to retrieve data from the client side, or use the NodeJS library to take a client request and retrieve the data via the NodeJS server and send it back to the client. Is there any advantages or disadvantages to either solution? (Security, ease of implementation, speed, etc.)
node.js firebase firebase-realtime-database
node.js firebase firebase-realtime-database
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
asked Jan 1 at 22:21
UnknownLuckUnknownLuck
228
228
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
When at all possible, the client SDK should be preferred. Here's what you lose when proxying through a server:
No realtime updates. Unless you want to spend a lot of time coming up with your own way of shuttling updates through a websocket, the client will only ever be able to get a single update per request. You won't have to ability to receive updates in real time, pushed to the client as they happen.
No security rules. You won't be able to effectively control access to your database with security rules. Since the Admin SDK operates with full control over the entire database, you'll have to come up with your own way of figuring out if the client is allowed to read or write. You could try to work around this by initializing the admin sdk on each request to scope it to a particular uid, but that's inefficient and too much extra code.
No client side cache. The Realtime Database client SDKs all cache data locally, so that future queries against data unchanged on the server are fast and cost less money. You could always try to implement this yourself, but be prepared to spend a lot of time on that.
No offline sync. When you write data using the client SDK, the data actually appears changed on the server (from it's own perspective), even if it's offline. And when it comes back online, it will automatically sync those change to server without you having to do anything. If you proxy through a server, you'll have to implement your own retry logic if you want this sort of behavior.
There might be some advantage going through a server, but it's highly dependent on what you're trying to do, and how you choose to compute what the savings is by doing so.
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
Thank you so much! This helped answer some other questions I had, too.
– UnknownLuck
Jan 1 at 23:06
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53999394%2fretrieve-firebase-rd-data-with-the-js-library-or-through-a-nodejs-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
When at all possible, the client SDK should be preferred. Here's what you lose when proxying through a server:
No realtime updates. Unless you want to spend a lot of time coming up with your own way of shuttling updates through a websocket, the client will only ever be able to get a single update per request. You won't have to ability to receive updates in real time, pushed to the client as they happen.
No security rules. You won't be able to effectively control access to your database with security rules. Since the Admin SDK operates with full control over the entire database, you'll have to come up with your own way of figuring out if the client is allowed to read or write. You could try to work around this by initializing the admin sdk on each request to scope it to a particular uid, but that's inefficient and too much extra code.
No client side cache. The Realtime Database client SDKs all cache data locally, so that future queries against data unchanged on the server are fast and cost less money. You could always try to implement this yourself, but be prepared to spend a lot of time on that.
No offline sync. When you write data using the client SDK, the data actually appears changed on the server (from it's own perspective), even if it's offline. And when it comes back online, it will automatically sync those change to server without you having to do anything. If you proxy through a server, you'll have to implement your own retry logic if you want this sort of behavior.
There might be some advantage going through a server, but it's highly dependent on what you're trying to do, and how you choose to compute what the savings is by doing so.
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
Thank you so much! This helped answer some other questions I had, too.
– UnknownLuck
Jan 1 at 23:06
add a comment |
When at all possible, the client SDK should be preferred. Here's what you lose when proxying through a server:
No realtime updates. Unless you want to spend a lot of time coming up with your own way of shuttling updates through a websocket, the client will only ever be able to get a single update per request. You won't have to ability to receive updates in real time, pushed to the client as they happen.
No security rules. You won't be able to effectively control access to your database with security rules. Since the Admin SDK operates with full control over the entire database, you'll have to come up with your own way of figuring out if the client is allowed to read or write. You could try to work around this by initializing the admin sdk on each request to scope it to a particular uid, but that's inefficient and too much extra code.
No client side cache. The Realtime Database client SDKs all cache data locally, so that future queries against data unchanged on the server are fast and cost less money. You could always try to implement this yourself, but be prepared to spend a lot of time on that.
No offline sync. When you write data using the client SDK, the data actually appears changed on the server (from it's own perspective), even if it's offline. And when it comes back online, it will automatically sync those change to server without you having to do anything. If you proxy through a server, you'll have to implement your own retry logic if you want this sort of behavior.
There might be some advantage going through a server, but it's highly dependent on what you're trying to do, and how you choose to compute what the savings is by doing so.
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
Thank you so much! This helped answer some other questions I had, too.
– UnknownLuck
Jan 1 at 23:06
add a comment |
When at all possible, the client SDK should be preferred. Here's what you lose when proxying through a server:
No realtime updates. Unless you want to spend a lot of time coming up with your own way of shuttling updates through a websocket, the client will only ever be able to get a single update per request. You won't have to ability to receive updates in real time, pushed to the client as they happen.
No security rules. You won't be able to effectively control access to your database with security rules. Since the Admin SDK operates with full control over the entire database, you'll have to come up with your own way of figuring out if the client is allowed to read or write. You could try to work around this by initializing the admin sdk on each request to scope it to a particular uid, but that's inefficient and too much extra code.
No client side cache. The Realtime Database client SDKs all cache data locally, so that future queries against data unchanged on the server are fast and cost less money. You could always try to implement this yourself, but be prepared to spend a lot of time on that.
No offline sync. When you write data using the client SDK, the data actually appears changed on the server (from it's own perspective), even if it's offline. And when it comes back online, it will automatically sync those change to server without you having to do anything. If you proxy through a server, you'll have to implement your own retry logic if you want this sort of behavior.
There might be some advantage going through a server, but it's highly dependent on what you're trying to do, and how you choose to compute what the savings is by doing so.
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
When at all possible, the client SDK should be preferred. Here's what you lose when proxying through a server:
No realtime updates. Unless you want to spend a lot of time coming up with your own way of shuttling updates through a websocket, the client will only ever be able to get a single update per request. You won't have to ability to receive updates in real time, pushed to the client as they happen.
No security rules. You won't be able to effectively control access to your database with security rules. Since the Admin SDK operates with full control over the entire database, you'll have to come up with your own way of figuring out if the client is allowed to read or write. You could try to work around this by initializing the admin sdk on each request to scope it to a particular uid, but that's inefficient and too much extra code.
No client side cache. The Realtime Database client SDKs all cache data locally, so that future queries against data unchanged on the server are fast and cost less money. You could always try to implement this yourself, but be prepared to spend a lot of time on that.
No offline sync. When you write data using the client SDK, the data actually appears changed on the server (from it's own perspective), even if it's offline. And when it comes back online, it will automatically sync those change to server without you having to do anything. If you proxy through a server, you'll have to implement your own retry logic if you want this sort of behavior.
There might be some advantage going through a server, but it's highly dependent on what you're trying to do, and how you choose to compute what the savings is by doing so.
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
answered Jan 1 at 22:32
Doug StevensonDoug Stevenson
80.4k996114
80.4k996114
Thank you so much! This helped answer some other questions I had, too.
– UnknownLuck
Jan 1 at 23:06
add a comment |
Thank you so much! This helped answer some other questions I had, too.
– UnknownLuck
Jan 1 at 23:06
Thank you so much! This helped answer some other questions I had, too.
– UnknownLuck
Jan 1 at 23:06
Thank you so much! This helped answer some other questions I had, too.
– UnknownLuck
Jan 1 at 23:06
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53999394%2fretrieve-firebase-rd-data-with-the-js-library-or-through-a-nodejs-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
