Loopback with Google Cloud Functions

[Brian McBride]

I've been leveraging Express with my cloud functions, since GCP Functions basically provide a standard HTTP agent.

const express = require('express');
const app = express();
export const webApi = functions.https.onRequest(main); 

Obviously, there is more to this. In fact, what I end up doing is creating an express app for groups of endpoints. Like, maybe all my User functions hang in one express app. Say I had a Todo app, then I might have another express endpoint for CRUD around Todos. Now I have 2 express apps, one for Users and one for Todos.

What is interesting about this Express pattern is that I can create a meta Express app that uses all the other Express apps as routes. So now I can deploy the meta Express app as well (say on an App Engine or my own container using something like strong-pm). 

As a long-time fan of Loopback, I've been awaiting v4 to hit GA. Now that it is here - I'm wondering how I can leverage it within my Serverless workflow. Can I create Loopback v4 apps that hang in serverless? Something like:

async function main(options: ApplicationConfig = {}) {

const app = new MyServerApplication(options);

await app.boot();

// await app.start();

// const url = app.restServer.url;

// console.log(`Server is running at ${url}`);

// console.log(`Try ${url}/ping`);

return app;

}

export const webApi = functions.https.onRequest(main());

Sorry, my IDE there is in Dark mode, heh.

Maybe I could build a Loopback v4 application with multiple applications. I see how in MyServerApplication I can set up various boot options. So my meta app can have all controler folders, but I can create my serverless app with only the controllers they should utilize.

Hoping one of the loopback contributors can lend some insight on this.

And, of course, congratulations on the release. I can't wait to check it out. 

[Brian McBride]

I'm guessing based on the Lambda thread that the feeling is that Loopback is too heavy for a serverless function. 

We really need a nice framework for serverless though. If you are building an app leveraging cloud functions/serverless, you still need to define your HTTP APIs, you still probably want clear data models, storage connectors, etc... Sure, you want your serverless app to be as light weight as possible - however I keep thinking that good tree-shaking can minimize the actual code deployment to each function. 

Having one project that can be either deployed as a larger node app (in a container or some PaaS App Engine), split up into individual serverless functions (GCP, AWS Lambda, Azure, etc...) or even a hybrid of the two would be an awesome framework for any company to adopt.