Lets talk about the Backend setup!

[FilledStacks]

The backend setup has been decided and implemented! I'd like to keep this discussion alive to talk about better implementations or changes in the code that could benefit us as the backend maintainers. To see the overview of the current state of the backend you can go to this readme.

One thing that has been brought up is:

• Why do we have an express app per group?

My answer to this good question:

1. We have a separate app because each resource should be maintained separate
2. I don't think it has a negative effect, so why not keep them separate
3. Lastly and most importantly, I couldn't figure out the code to use only one express application (5 day Typescript user). I struggle with script style programming

So this discussion is to help this series with some insights from more experienced typescript developers. Lets get talking!

[VictorUvarov]

My thoughts on simplification.

This is currently how I have my index.ts file for firebase. If I also create functions that I may not want to export, I simply do not add them to the exports object.

import * as admin from "firebase-admin";

// Triggers
import { userCreated } from "./triggers/algolia-user-index";

// APIs
import acceptUsersAppointment from "./api/accept-users-appointment";

admin.initializeApp();

// Triggers
exports.userCreated = userCreated;

// APIs
exports.acceptUsersAppointment = acceptUsersAppointment;

Also why use express directly? Firebase functions is using express underneath.

• It is better to use functions.https.onCall so that authentication is handled for you

const myFunction = functions.https.onCall(async (data, context) => {
  if (!(context.auth && context.auth.token)) throw Errors.NOT_AUTHENTICATED;
  ...
});

• For public APIs you can use functions.https.onRequest

[francescopasin]

The problem with you setup is that you always need to import and export every function from index.ts. When the app grows this lead to a huge file. Is a lot easier to manage everything if every function is added automatically just by creating the file.

[francescopasin]

Regarding the use of express Firebase itself suggest to use it in their guide. Without express creating restful endpoints will lead to complicated and bad code (for example you'll end up using switch everywhere to create the different routes). Considering that the whole point of this project is scalability and maintenance express probably is the best choice here

[FilledStacks]

@VictorUvarov thanks for sharing that example. I appreciate it. I've had a similar setup to that before but as mentioned by @francescopasin there's an inherited growth there, maybe not in the index file but in the addition of your functions to the other files.

I feel like the setup I've show is extremely simple. You add a file with a certain name to get an endpoint or a reactive function. There's nothing else to do. The setup code will be turned into a package so it'll all be "hidden" from the user. And in terms of the auth I know there's a format firebase calls use which we can implement. But it sounds like @francescopasin has seen a guide for it.

Can you please link that for me, I'd like to get to that as well in the future.

[francescopasin]

@FilledStacks I didn't see a guide about authentication (but for sure there is a way to handle it with express). I was talking about the use of express in general. If you don't use it, for example, if you need to handle different request types or http methods you need to do something like this:

 * Responds to a GET request with "Hello World!". Forbids a PUT request.
 *
 * @example
 * gcloud functions call helloHttp
 *
 * @param {Object} req Cloud Function request context.
 * @param {Object} res Cloud Function response context.
 */
exports.helloHttp = (req, res) => {
  switch (req.method) {
    case 'GET':
      res.status(200).send('Hello World!');
      break;
    case 'PUT':
      res.status(403).send('Forbidden!');
      break;
    default:
      res.status(405).send({error: 'Something blew up!'});
      break;
  }
};

As you can see this is a lot of code when with express you have everything already handled for you.

Btw I found theese examples in the documentation https://cloud.google.com/functions/docs/writing/http

For authentication you can handle it with a middleware, where you check with firebase auth if the user is authenticated and you can call next middleware only if it is (otherwise you return a 403/401 error). Then you can simply apply the middleware where you need it (this is the reason for my initial doubt about different express app for each group).

[FilledStacks]

@francescopasin I agree. I think express is a lot cleaner for handling the functions, and I'll definitely look into using one single express app for all the endpoints. I'll see how we have to handle auth and if it makes sense to use one app then we'll convert it into one app.

[ketanchoyal]

Just in case anyone didn't notice this.
Firebase will not support functions on free spark plan, to use it for free we have to use node 8 or else we have to upgrade to some paid plan.

[FilledStacks]

Yes, that's correct. I mentioned that in the previous video. You can still develop with by deploying locally to the emulators and test out everything. the blaze plan is pay-as-you-go and includes all the free plan usage as well. If you're only going to be developing with this project you'll never hit the limits in a month since it'll be only you using the app once a week when the new video comes out. So just registering it'll not cost you anything.

[llewellyncollins]

I like this solution you have come up with here, I think it is straightforward and as you said, it will scale well.

Though it might be a bit over-engineered as even with a codebase with a lot of functions keeping the index.ts file tidy is a trivial task. And there is something to be said for explicit action over implicit consequences. But we are engineers so it is natural to engineer a solution to potential problems =)

Where I think this can really shine is with handling versioning of firebase functions as I feel that is a major pain point right now in the firebase ecosystem. So I would do something like structure the folder like

orders

• idle
  -- v1

And extend the export helper to append the version number to the function names. This way you can adapt and grow your backend while keeping backward compatibility.

Also, any particular reason you went with idle instead of restful? Restful is an industry-standard term

[FilledStacks]

@llewellyncollins I didn't know keeping index tidy was a small task haha, now it does feel over engineered. I basically didn't want to modify anything, I just wanted to add new files as I need more functionality. If all the implementations were "hidden" it would have looked magical. But I wanted to show how it was setup, which makes it feel a bit more complex than it it.

There's no particular reason for the naming. In the context it made sense. And this is exactly why I wanted these discussions before, now that you mention that it doesn't make sense anymore. Thanks for pointing that out. I'll update the documentation and code base to use the term restful instead. I completely forgot about that term 😓

I appreciate the feedback man! I'll make an issue to tackle the updates of the naming.

[llewellyncollins]

A small task...maybe not. But I would say it is trivial as it is just a matter of exporting your required functions.

I forked your code last night so I can have bit of a play with it as you have done some stuff I have not considered. Started doing some light refactoring to make it a bit more structured, not sure if you are accepting PR at this early stage but I would love to help maintain or do code reviews for this.

[FilledStacks]

@llewellyncollins I would be very happy with PR's / code reviews for this. I am not nearly as experienced as you are in the world of ES language specs. That's exactly why I want this open, so my lack of JS/TS skills doesn't bring this project down 😄

Send it through!