If the concept of a single page website was a novelty, then the single file web app is a wonder.
Without using the commonly used terms for describing the single file web app, let me describe what the file does -
1. it listens to a request using the HTTP or the https protocol and can respond with JSON. Is it a REST API?
2. it can contain multiple route handlers for a web request. A web server?
3. it is written in plain javascript or es6. A node.js web app?
4. it uses express.js to handle the request, response. A node.js web server?
5. it spins itself up as and when required to serve requests. Wait! Is it an appEngine?
6. it provides for modular services. Ok! Is it microservices?
7. it is a function that can handle web requests hosted on the cloud.
Alright, it is a lambda function or a cloud function.
What the Google Cloud Function (GCF) does as a FaaS (Function as a Service) is well-documented but it is in the enhancement of the DX (Developer eXperience) that the GCF scores hugely.
For an architect, it helps ensure that there are no async calls on the main app.js file, or promises used that don't get fulfilled because the app.js is the main server file that is only concerned about setting up the server and to start listening after running through a sequence of synchronous flow.
Like the moron in the '3 idiots' movie (Hindi movie) who simply rattles off memorized words, from a prepared speech in an unknown language, as it got interpreted in its mind, without bothering to understand the meaning of the sentences used, the app.js file in the node.js, expressjs context, simply runs through all the statements, dumbly - its sole purpose being to reach the end of the file for the magical server.listen statement!
Not so with the GCF.
The GCF simply spins up, executes the lines, intelligently, and once the request, response cycle is done, it shuts down by itself. So, no worries about load testing or listening to requests when there are none as in the app.js context or bothering about server resources! The GCF is a serverless server.
The GCF handles thens and catchs but most importantly, with its ability to act as a route handler, with the help of Firebase-functions, it completes the requirement for the most robust, lean web server - a single file web server. The GCF, by itself, cannot handle/parse parameters or query strings passed via the URL, but with firebase, it can!
Here is a simple GCF [Edit: link removed] - Edit: One of the pitfalls is managing the connections in a cloud function as each time, a new container instance may execute the Cloud function causing new connections with the Cloud Database server so, it becomes more than challenging to keep or share db connections!
Of course, the workaround is the infamous "Allow access from anywhere" option but then this is where the prudence in using something like a firebase library lies because it enables authorization token to be submitted in the request URL and so the infamous workaround may actually become an ideal workaround if not the solution.
And yes, with the GCF, you can query external databases in other cloud regions like a Mongodb Atlas database and the speed of the response is phenomenal!
Without using the commonly used terms for describing the single file web app, let me describe what the file does -
1. it listens to a request using the HTTP or the https protocol and can respond with JSON. Is it a REST API?
2. it can contain multiple route handlers for a web request. A web server?
3. it is written in plain javascript or es6. A node.js web app?
4. it uses express.js to handle the request, response. A node.js web server?
5. it spins itself up as and when required to serve requests. Wait! Is it an appEngine?
6. it provides for modular services. Ok! Is it microservices?
7. it is a function that can handle web requests hosted on the cloud.
Alright, it is a lambda function or a cloud function.
What the Google Cloud Function (GCF) does as a FaaS (Function as a Service) is well-documented but it is in the enhancement of the DX (Developer eXperience) that the GCF scores hugely.
For an architect, it helps ensure that there are no async calls on the main app.js file, or promises used that don't get fulfilled because the app.js is the main server file that is only concerned about setting up the server and to start listening after running through a sequence of synchronous flow.
Like the moron in the '3 idiots' movie (Hindi movie) who simply rattles off memorized words, from a prepared speech in an unknown language, as it got interpreted in its mind, without bothering to understand the meaning of the sentences used, the app.js file in the node.js, expressjs context, simply runs through all the statements, dumbly - its sole purpose being to reach the end of the file for the magical server.listen statement!
Not so with the GCF.
The GCF simply spins up, executes the lines, intelligently, and once the request, response cycle is done, it shuts down by itself. So, no worries about load testing or listening to requests when there are none as in the app.js context or bothering about server resources! The GCF is a serverless server.
The GCF handles thens and catchs but most importantly, with its ability to act as a route handler, with the help of Firebase-functions, it completes the requirement for the most robust, lean web server - a single file web server. The GCF, by itself, cannot handle/parse parameters or query strings passed via the URL, but with firebase, it can!
Here is a simple GCF [Edit: link removed] - Edit: One of the pitfalls is managing the connections in a cloud function as each time, a new container instance may execute the Cloud function causing new connections with the Cloud Database server so, it becomes more than challenging to keep or share db connections!
Of course, the workaround is the infamous "Allow access from anywhere" option but then this is where the prudence in using something like a firebase library lies because it enables authorization token to be submitted in the request URL and so the infamous workaround may actually become an ideal workaround if not the solution.
And yes, with the GCF, you can query external databases in other cloud regions like a Mongodb Atlas database and the speed of the response is phenomenal!
