I'm trying to build a relatively simple application that has several different views, requires authentication, collects some user data, stores it in a database, and needs backend logic to manipulate that data and spit it back out to the user in a view.
The stack I've decided on is Vue for the frontend, with Express and Node for server side logic and Firebase for some of their services (namely auth, firestore, storage).
I haven't been able to find any examples of this stack (Vue, Express, Firebase) anywhere (I have however found Vue/Express or Vue/Firebase examples). My question is whether or not Express is obsolete here in that I can use Vue router to do my routing. Is the difference that one does the rendering server-side?
You could use Cloud Functions for Firebase as your backend and then limit your stack to Vue.js and Firebase.
From the doc:
Cloud Functions for Firebase lets you automatically run backend code
in response to events triggered by Firebase features and HTTPS
requests. Your code is stored in Google's cloud and runs in a managed
environment. There's no need to manage and scale your own servers.
For your specific need: "backend logic to manipulate that data and spit it back out to the user in a view." you have several possible approaches:
You manipulate the data with Cloud Functions (in the back end), write the results of this manipulation to the Real Time Database and setup some listeners in your Vue.js frontend (with the on() method) that will refresh your front end upon changes in the database
Use some HTTPS Cloud Functions that you call, from your Vue.js front-end, as REST API endpoints. You can use Axios for example. See the doc here.
One advantage of the first solution is that you can easily, by default, rely on the database security rules, while it would need some more extra work in the second case.
Related
I have a desktop app that will be distributed to users, and part of its code (which the user might be able to access) has to perform an API call to a third-party web service. However, this requires the API keys to be embedded into the source code, which causes some obvious security issues.
The main solution I've found while researching on the subject is to have a backend server between the user and the third-party API endpoint. So, I've been looking into Firebase for a while and it seems that this solution can be implemented using Firestore and Cloud Functions.
But, I wasn't able to find any clear examples that achieve something like this, and since I have no previous experience with Firebase or just backend programming in general, I would like to know if I'm on the right track and get more details about how to get it done, or if there are better alternatives for solving this issue. Any input is appreciated, thx.
You can use the firebase cloud functions as you mentioned. Your desktop application will be communicating with the cloud function - simple API call. Here you can find examples how to implement and deploy functions and test it locally https://firebase.google.com/docs/functions/get-started. Your cloud function will hold the API keys (it is backend so it will be secure if you dont expose it explicitly. Also the backend to backend communication is considered as secure). Finally, this cloud function will call the third party service and return some data back to the desktop app if needed. So you are on the right track, that is how the design should look like. If you need some help with cloud functions, you can also contact me directly.
I need to implement a scenario where, after a file is uploaded to Google Cloud Storage, a function is triggered and processes the file. In this case, processing basically means sanitizing the file, storing it into Firestore and making it accessible via another HTTP-triggered function (a REST API of sorts).
Both user-facing ends of this process (a file upload and HTTP function) need to be secured. The process will be used in server-to-server scenario: one side is going to be a backend written in either Node.js or .NET, the other will be my Firebase solution (Cloud Storage and HTTP-triggered function as per above). In Firebase, I am going to maintain a custom set of users that should have access to the system - my idea was to use a simple system where each user will have a client id and a client secret (basically an oAuth client credentials grant type).
Based on what I read online, an only option to implement this is to use [Firebase auth with custom tokens][1]. I found lots of examples online on how to do that, but it was always about client-to-server scenarios (e.g. a Javascript web app talking to REST API). Server-to-server scenarios were not mentioned anywhere and indeed, I am unsure how to go about implementing it - I can call auth.createCustomToken(uid) just fine in my HTTP Firestore function, but there seem to be no server-side libraries I could use to call auth.SignInWithCustomTokenAsync(customToken).
To sum it up:
How can I use Firebase auth with custom tokens in server-to-server
scenario, where I need to sign in using a previously generated
custom token from a server environment?
If it is not possible,
what's the other alternative to securely implement the
above-described architecture?
I've contacted Google Support and if anyone else is struggling with this, in server-side scenarios, recommended approach is to call signInWithCustomToken endpoint in Firebase Auth REST API.
I am currently creating a marketplace mobile application from scratch and I'm using React Native for the front-end part and Firebase for the backend (using Firebase and Firestore).
I am wondering wether :
I should create a RESTful API using cloud functions and express to create API endpoints (that would connect to firebase and firestore) that I'd call from my redux actions in my React Native app (using redux thunk).
or, I should call firebase and firestore directly from redux actions.
I see couple pros and cons for each method.
Restful API pros :
Safer as I can check and manipulate submitted data more easily
Custom API reply (I can manipulate the return data)
Restful API cons :
Probably slower as I would have to call an API endpoint that will then call firebase and/or firestore.
Won't be as easy to set listeners on firestore data
What do you think about it ?
Which option should I choose knowing that I predict that the app will get a few thousand users daily. I want it to be as fast and safe as possible and be able to set listeners for notifications purposes.
In my opinion you should mix them, if you have to manage users, products or etc. Firebase produces client and admin sdk that has different roles. If you haven't need manage any data of products or users or etc. you can simply use client sdk.
My advise is you can use admin sdk on API (server-side) and feel free to use client sdk on your clients.
Use as managements on API, listening data, realtime chat etc. via client sdk.
You can check admin and client sdk. Also npm packages for React Native here.
Mixing will be of help, you can try:
Listen for small amounts of data using the client SDK
Write and sort data using the cloud functions
In my experience, writing to a firebase database that uses ordered ids (in my case) leads to some huge problems in the long run. I lost a good chunk of data when my app accidentally wrote to a root index instead of a child index when the app was resumed from inactivity because the android system cleared the RAM.
Also, for notification, use Firebase Cloud Messaging.
So I was watching multiple tutorials about how to present data on an actual webpage using Cloud Firestore. The thing is, everyone was using an actual index.html file sitting in Public folder(instead of serving html content within node.js code) and tags which would mean that their program would use client-side JavaScript instead of node.js. But why? for what reason? According to Firebase tutorials and documentation, having an ACTUAL index.html sitting in Public folder is only for making static webpages, thus, if I'm making a complicated and dynamic webpage(which will also present Firestore data within the webpage), I should be using node.js right?
The Firebase SDKs for Cloud Firestore perform local persistence (caching) of doucments fetched from the database. The persistence is enabled by default for Android and iOS, and you can programmatically enable it for web (currently experimental). This local caching allows the client to avoid requesting documents from the server, which is obviously faster and cheaper than going through some API endpoint to request the data each time it's needed.
There is also the fact that the SDKs will push you realtime updates of data as it changes on the server, as long as you have a listener attached to some document or query of interest. You won't be able to duplicate this if you write it all in Cloud Functions. You will spend a tremendous amount of time trying to duplicate and scale this behavior using socket.io or something similar on a backend you control.
You could write the entire app to be driven through API endpoints that you create. There's nothing wrong with that, if it meets your needs. But you'll write more code, you'll sacrifice realtime updates, and it will likely be slower and more expensive than allowing the client SDKs to optimize for you.
To avoid rewriting Firebase DB logic in various apps (iOS, Android, Web) we earlier used a service/middle layer to hold this logic. In this way the app never interacts with the DB directly.
However, in the new architecture with Firebase and Google Cloud Functions, would it be wise to route all DB calls through Cloud Functions or should this be done only selectively based on use case?
In almost all the examples I’ve seen so far, the app directly interacts with Firebase DB and the Cloud Functions are meant to only listen to certain events and used selectively. They are not meant to be a middle layer.
This approach would however lead to the need to duplicate DB logic in all apps. Can this duplication of code be avoided?
Yes. By moving certain functionality from your application code into Cloud Functions, you will only have to implement that logic once: in JavaScript. This is great for certain logic that you either don't want on the client (too big, too secret, too slow, etc).
But:
Each client will still need code to access the functionality in Cloud Functions. This can be as simple as a write through the Database SDK, but can also get quite involved.
The functionality will only be available if the user has a network connection. Unlike client-side functionality, it won't work when the user is disconnected/offline.