
I am looking for alternative solution after Heroku free dynos are no longer available.
Basically what I am trying to achieve is to host my API services and I stumbled upon serverless solution.
It is a very small application with only 3 endpoints to serve, and I am thinking to give serverless a try.

There are two options that are viable for me.

1. Cloudflare workers
2. Firebase functions (will write about this in future blog)

After experiment with Cloudflare workers. Here are my thoughts about it.

<hr />
<br />

#### Cloudflare workers

1. Very easy to get started

    With the `wrangler` tool and good documentations. I managed to get a worker up and running and publish it in no time.


2. Development experience is good

    Changes in files are reflected immediately without having to restart dev server.


3. Deployment is simple

    Hassle free and quick. Make changes and deploy and the endpoints are live.


4. APIs are fast

    Not to mention the API response are pretty fast, that's a bonus.


5. Managing environment variables for staging and production are easy

    Even come with encrypted options for sensitive data and can be configured from dashboard or CLI.


*However*

6. It is JS runtime, not node environment.

    For my case, it's not working for some of the existing API, due to dependency on external node package, `stripe`.
    However I managed to get it to work with `node_compat = true`, but other packages doesn't work well, like `firebase-admin`.
    I can get around that with Restful API provided by Firebase and Google, but I need to rewrite existing code that is working already from using SDK to using Restful APIs.


<br />

Despite I didn't go with Cloudflare workers, given that it's not the right tool in my use case, cause I need to run the existing project without rewriting it, but it is very promising product and I would definitely revisit it for my future projects.

That's it!

Cheers.


Cloudflare workers first impression


A couple of years after my first serverless hands-on with Firebase Cloud Functions, I've revisited it I am amazed by the fact that Express app will work out of the box in Cloud Functions.

This will be the perfect for my use case to serve API endpoints from existing project written in Express app.

I can now seamlesssly make transition to cloud functions, and that is exactly what I am looking for!

It's simple to get the existing Express app up and running with minimal changes of code, not to mention that it's also easy to get started and deploy with Cloud Functions.

<hr />
<br />

Only a few things to take note:

1. Development without hot reload.

    As I am developing with the firebase emulators, I noticed that file changes saved are not reflected without restarting the emulators. There might be an option in the CLI that can be enabled that I didn't know of.


2. Managing environment variables for staging and production are not what I am used to

    For sensitive information, I used `Google Secret Manager` to store the key-value pair secret. It is more secure than storing in `.env` in Cloud Functions, however I can't use the same environment variable name for different environment. For example, I now need to have `MY_SECRET` and `MY_SECRET_STAGING` for different environment. I am looking for other ways to do it in the future but I am now settled with it.

    It is suggested that I should create another cloud functions project to serve staging environment, but in my use case, I use another Express app instead, and it works well for my scenario.


<br />

I didn't spent a lot of time this time exploring how things should be done in Firebase Cloud Functions. However, I am happy that I don't have to spend more time to get my existing project up and running again.

Firebase Cloud Functions saved me from having to rewrite the app, and I am happy about it. Do check that out for your next projects.

Cheers.


Cloudflare workers first impression

9 December 2022

Running Express app in Firebase Cloud Functions

16 December 2022