Chameera Dulanga


Firebase is an application development platform that supports web and mobile development. It is owned by Google and provides various services like real-time databases, storage, authentication, hosting, and analytics.

Firebase authentication is a managed identity authentication system that lets you store and create user sessions without the need for a backend. Here is a quick tutorial on how to set up Firebase authentication with React. 

## How Firebase authentication works

![01-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824791/01_firebasereact_3cc658f6dc.png)

Firebase authentication is part of the services suite offered by Google's full-stack app platform. It covers a majority of authentication options including email, and federated identity providers such as Google, Facebook, Twitter, and GitHub. Firebase authentication is a free service, with the exception of phone verification - which is free for the first 10k API calls. 

Authentication works by providing an API that lets valid apps access login statuses and session tokens that are managed by Firebase. It uses OAuth 2.0 standards for security and OpenID Connect for interoperability. 

There are multiple ways to implement Firebase authentication, including a 'drop-in' solution where an external user flow is provided to sign in users. Another way is to use the Firebase SDK authentication, which is a package that can be leveraged for backend and native applications. 

For this tutorial, we are going to focus on implementing Firebase authentication in a React app. 

## Implementing Firebase Authentication in a React app

In this tutorial, we will be implementing the following:

- email and password authentication method
- Single sign-on with Google authentication method

You wil need to have a basic understand of React before you begin. 

### Step 1: Create a new Firebase project
![02-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824789/02_firebasereact_d5166b6d05.png)

Before we can use authenticated identities through Firebase, you need to create a project. To do this, go to your  [Firebase console](https://console.firebase.google.com/). You should see the screen as per the screenshot below (or something similar).

![03-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824789/03_firebasereact_e9016fc92a.png)

Click the **Create a Project** button, and you will be redirected to the project creation wizard. You will need to enter a project name and enable Google analytics if needed.

It takes a few seconds for your newly minted Firebase project to boot up. Once completed, you will be automatically redirected to your project's dashboard. Your Firebase project's dashboard looks something like this:

### Step 2: Enable Firebase Authentication

To enable Firebase Authentication, you need to select the **Authentication** option from the left side panel. It will redirect you to the Firebase Authentication options, where you can manage users, sign-in options, and templates.

![04-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/04_firebasereact_76209f0352.png)

You can select multiple authentication options from the sign-in method page, including native and federated sign-in methods.

For this tutorial, we will be using Email/Password and Google sign-in. Here is a quick rundown on how to enable email and password, and Google sign-in. 

#### Enabling Email/Password Sign-In

To enable email and password authentication method on Firebase, you need to switch it on by clicking on the enable toggle. 

![05-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/05_firebasereact_61166b215f.png)

After saving, you will be redirected back to the sign-in method page, and you will see the Email/Password authentication option in the sign-in provider list.

![06-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824789/06_firebasereact_25346f9886.png)


#### Enabling Google Authentication federated profile Sign-in

To enable Google federated sign-in, you need to add another sign-in provider by clicking **Add new provider** button.

![07-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/07_firebasereact_01d2eee0f9.png)

Select Google from the additional providers and it will open a configuration modal like below:

![08-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/08_firebasereact_63afc5b165.png)

To save user details - that is, data that is associated with the user profile - you will need a database. We will be using Firebase's Firestore database for this purpose. 

### Step 3 — Creating a Cloud Firestore Database

To create a Firestore database, you need to select the Firestore database option from the left panel. The free tier gives a generous 600,00 writes and 1.5 million reads before you start getting charged for usage. 

![09-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/09_firebasereact_49620ef340.png)

You will be directed to a database creation wizard. Click on **Create database**. This will give you the database security permissions. For now, you can grant all access. However, you will need to close up accessibility to only your application to prevent leaks and potential security breaches. 

![10-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824791/10_firebasereact_5e430b9f3d.png)

Make sure to enable write permissions by changing rules to `allow read, write: if true`.

![11-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/11_firebasereact_e144acbe24.png)

After clicking **Enable,** you will be redirected to the Firestore database page within a few seconds.

![12-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/12_firebasereact_150dd3ad14.png)

Now that we've got your console set up for Firebase authentication and a database set up, we can now integrate it into our React application. 
![13-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/13_firebasereact_90efeca34d.png)

### Step 4: Registering your React app with Firebase 

To connect your Firebase backend to your react app, you need to Firebase project settings and configure it to use the React app. When you go to Firebase settings and scroll down, you will see a message like the below:


![14-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824789/14_firebasereact_071c786fb9.png)
Then, you need to select the Web application icon (**</>**), and it will take you to the app registration page.


![15-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824790/15_firebasereact_21403a6000.png)

After registering the web application with a nickname, you will get the necessary details to add Firebase SDK to your React application. Make sure to copy these details before completing the wizard since we will be using them in the next step.



![16-firebasereact.png](https://res.cloudinary.com/layercode/image/upload/v1638824791/16_firebasereact_149de04152.png)

### Step 5: Adding Firebase to your React Application

Here is a series of steps you need to follow to add Firebase to your React application. 

### Installing Firebase

Firebase provides 2 options to install it to our application - `NPM` and `<script>` tag. For our React app, we are going to use NPM. Here is how to install the Firebase package as a module via NPM.

```
npm install firebase
```

### Creating a Firebase service in React

Then we need to create a service file to keep all the firebase configurations and functions.

Here is an example of a service file:

```javascript
import firebase from “firebase/app”;
import { getFirestore, collection, addDoc, where, query, getDocs} from "firebase/firestore";
import "firebase/compat/auth";

const firebaseConfig = {
  apiKey: “<API_KEY_HERE>”,
  authDomain: “<AUTH_DOMAIN_HERE>”,
  projectId: “<PROJECT_ID_HERE>”,
  storageBucket: “<PROJECT_STORAGE_BUCKET_HERE>”,
  appId: “<APP_ID_HERE>”,
  measurementId: “<MEASUREMENT_ID_HERE>”,
};

firebase.initializeApp(firebaseConfig);
const db = getFirestore();
const provider = new firebase.auth.GoogleAuthProvider();

provider.setCustomParameters({ prompt: 'select_account' });

export const auth = firebase.auth();
export default firebase;
```

In the below user registration function, Firebase returns a new user when we pass the email and the password to `auth.createUserWithEmailAndPassword(email, password)` - which is Firebase's `auth` service method. We will save the records to a Firestore collection using the database service.

```javascript
// User Registration
const userRegistration = async (name, email, password) => {
  try {
    const res = await auth.createUserWithEmailAndPassword(email, password);
    const user = res.user;
    await db.collection("users").add({
    uid: user.uid,
    name,
    authProvider: "local",
    email,
  });
  } catch (err) {
    alert(err.message);
  }
};
```

Firebase will take care of the authentication process from there and return the validity of the user.

```javascript
// Sign-in with Email/Passwordexport 
const signInWithEmailAndPassword = async (email, password) => {
  try {
    await auth.signInWithEmailAndPassword(email, password);
  } catch (err) {
    alert(err.message);
  }
};
```
Firebase provides a password reset option. All you need to do is pass the email to Firebase auth service using `sendPasswordResetEmail()` method.

```javascript
export const resetPassword = async (email) => {
  try {
    await auth.sendPasswordResetEmail(email);
  } catch (err) {
    alert(err.message);
  }
};
```

For Google sign-in, we need to handle both registration and sign-in in the same function. To prevent duplication, I will check if the users exist in the database, and if not, I will create a new record and continue with the sign-in process.

```javascript
// Google Sign-in
export const signInWithGoogle = async () => {
  try {
    const res = await auth.signInWithPopup(provider);
    const user = res.user;
    const userRef = collection(db, "users");
    const result = await getDocs(query(userRef, where("uid", "==", user.uid)));
    if (result.empty) {
      await addDoc(collection(db, "users"), {
        uid: user.uid,
        name: user.displayName,
        authProvider: "google",
        email: user.email,
      });
    }
  } 
  catch (err) {
    alert(err.message);
  }
};
```

That’s basically it. You don't need to deal with password storage management systems or security protocols that come with managing identities. Firebase has you covered.  



Web Dev

How to set up Firebase Authentication in React

Firebase is an application development platform that supports web and mobile development. It provides various services like real-time databases, analytics, storage, authentication, and hosting.

Firebase Analytics is one of the most exciting features of Firebase since it provides an application-focused analytics dashboard with countless features. Here is a quick tutorial on setting up Firebase Analytics with Angular.

## How Firebase Analytics works

![01.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/01_576121cef2.png)

Firebase Analytics was first introduced in 2016 by the Google Analytics team. The main purpose of this introduction was to provide an application-focused analytics service. Compared to Google Analytics, it focuses on tracking events and user properties instead of page views and sessions.

When we use Firebase SDK, it automatically captures up to 500 default events. It can also be used to define custom events to get application-focused data. Once the data is captured, the Firebase Analytics dashboard is populated with detailed insights of data.

However, under the hood, it uses Google Analytics. That is why the name was later changed to **Google Analytics for Firebase**. Nevertheless, a lot of developers call it Firebase Analytics.

## Integrating Firebase Analytics with an Angular Application

In this tutorial, we will be implementing the following:

- Integrating Firebase Analytics for an Angular application.
- Defining a custom event and a user property with Firebase SDK.

You will need to have a basic understanding of Angular before you begin.

## Step 1 — Creating a New Firebase Project

Before we can use Firebase Analytics, you need to create a Firebase project. To do this, go to your [Firebase console](https://console.firebase.google.com/) as shown below.

![02.png](https://res.cloudinary.com/layercode/image/upload/v1643181351/02_63699e83fa.png)

Then, click the **Create a Project** button, and you will be redirected to the project creation wizard. There, you can enter a name for your project and click continue.

![03.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/03_568112f462.png)

## Step 2 — Enabling Firebase Analytics

In the 2nd step of the wizard, you will get an option to enable Firebase Analytics for your project. Make sure to enable it and click the **Continue** button to finish the wizard.

![04.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/04_861ecbc49a.png)

However, if you have already created a project with analytics disabled, you can enable it by navigating to the **Dashboard** under the **Analytics** section in the side menu.

![05.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/05_5a9c2c7c25.png)

Then, you need to click the **Enable Google Analytics** button, and you will be redirected to a window like below.

![06.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/06_cd08402016.png)

There, you can select an existing analytics account or create a new one. Next, you can complete the setup by clicking **Enabling Google Analytics** button.

## Step 3 — Creating a Firebase Application

Now, you need to create a new Firebase application. As I mentioned, Firebase Analytics supports web, android, iOS, and Unity applications. You can select your application type from the options given in the analytics dashboard.

![07.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/07_b71d21b380.png)

Since this tutorial is about Angular, let's select the web application option (**</>**). After choosing the application type, the wizard takes you to the app registration page. There, you need to configure a few details for the application, including an application nickname.

![08.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/08_ad77ca6d31.png)

After registering the web application with a nickname, you will get the necessary details to add Firebase SDK to your Angular application. You have to copy these details before completing the wizard since we will use them in the next step.
![09.png](https://res.cloudinary.com/layercode/image/upload/v1643181351/09_216100a94a.png)

## Step 4 — Integrating Firebase with Angular

You need to follow a series of steps to add Firebase to your Angular application. Let’s go through them step by step.

### Installing Firebase

Using [AngularFire](https://www.npmjs.com/package/@angular/fire) is the recommended way to install Firebase to Angular applications since it's the official Angular library for Firebase. And you can easily install it using `ng add @angular/fire` or `npm i @angular/fire` commands.

### Firebase Configuration

You can use the Angular environment files to keep Firebase configurations.

```
export const environment = {
  production: true,
  firebase : {
    apiKey: “<API_KEY_HERE>”,
    authDomain: “<AUTH_DOMAIN_HERE>”,
    projectId: “<PROJECT_ID_HERE>”,,
    storageBucket:  “<PROJECT_STORAGE_BUCKET_HERE>”,
    messagingSenderId: “<MESSAGE_SENDER_ID_HERE>”,
    appId: “<APP_ID_HERE>”,
    measurementId: “<MEASUREMENT_ID_HERE>”,
  }
};
```

If you are enabling analytics for a project which has already been configured with Firebase, you just need to include the `measurementId` to the configuration.

### Enabling Firebase Analytics

After setting configurations, you can import `AngularFireModule` and`AngularFireAnalytics` modules to `app.module` and initialize Firebase.

```
import { AngularFireModule } from ‘@angular/fire’;
import { AngularFireAnalyticsModule } from ‘@angular/fire/analytics’;import { environment } from ‘../environments/environment’;@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule,
    AngularFireModule.initializeApp(environment.firebase),
    AngularFireAnalyticsModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})export class AppModule { }
```

That's it. You have successfully configured Firebase Analytics for your project. Then you need to deploy the application, and you will start seeing analytics in the Firebase Dashboard within 24 hours.

![10.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/10_a0d0f47f5b.png)

However, if you navigate to the Realtime tab, you will see several instant analytics of the application, including users, user locations, events, etc.

![11.png](https://res.cloudinary.com/layercode/image/upload/v1643181352/11_b542365138.png)

## Step 5 — Optimizing Analytics with Custom Integrations

As explained in the previous step, including the Firebase Analytics package in your application is sufficient to enable automatic data collection. But, we can further optimize the process by using custom events and user properties to collect application-related data.

### Creating a Custom Event

Let's assume that you need to create an event to track when a user subscribes to the newsletter in your blog. So, you can easily create a custom event by injecting ***AngularFireAnalytics\*** into a component.

```
import { AngularFireAnalytics } from ‘@angular/fire/analytics’;

...

constructor(private analytics: AngularFireAnalytics) {}

subscribe(){
   this.analytics.logEvent('subscribed')
}
```

Once the changes are deployed, you can see the event details under the Events tab. You can see more details about those events by clicking on them.

![12.png](https://res.cloudinary.com/layercode/image/upload/v1643181351/12_7284189316.png)

### Creating a Custom User Property

User properties allow Firebase Analytics to divide users into small subgroups. For example, if your applications 2 types of users as admin and non-admin, you can define a custom user property to track which type of user is logged in.

```
import { AngularFireAnalytics } from ‘@angular/fire/analytics’;

...

constructor(private analytics: AngularFireAnalytics) {}async userLogin(username, password){
   var user = await validateUser (username, password);
   
   ...
   
   this.analytics.setUserId(user.id);
   this.analytics.setUserProperties({ level: user.type });
}
```

You can use many custom configurations and features to personalize the analytics result. You can find more about them in [Firebase documentation](https://firebase.google.com/docs/analytics?authuser=0#how_does_it_work).

That's basically it. You have successfully integrated Firebase Analytics with an Angular application. 

Cloud

How to Use Firebase Analytics with Angular

Aphinya Dechalert

The implementation of PostgresSQL on Supabase also makes it highly accessible and low-code projects. What is low-code? Low code is a growing trend and software approach that's supported by an infrastructure that enables minimal coding to build fully functional applications.

The interface for PostgresSQL on Supabase is akin to working on a spreadsheet, with the ability to easily add, edit, and update data in a no-code manner. Meanwhile, there is also an SQL editor interface that lets you create tables, functions, joins, and whatever else is required for your data needs.

## **Firebase features vs. Supabase features**

The idea behind Firebase and Supabase are the same - give developers the ability to create apps as quickly as possible. But which of these two services are better at it?

Overall, Firebase has more features and functionality. Supabase, in contrast, only supports core features of the database, managed authentication, and storage - with functions coming soon.

In contrast, Firebase has the added benefit of integrated monitoring through Crashlytics and Google Analytics, A/B testing, cloud messaging, and in-app messaging for mobile apps. There is also the option of using Firebase extensions to leverage popular third-party integrations such as Stripe payments and invoicing, Mailchimp, MessageBird messaging, and search with Algolia.

Supabase's condensed offering can feel like a drawback. However, due to Firebase being integrated with Google Cloud's ecosystem, it can be harder to integrate external services that haven't been pre-integrated. Not only that, the myriad of services available in addition to Firebase's core features can also be somewhat distracting. The learning curve for Firebase is also higher, mostly due to it being a proprietary database.

Supabase, in contrast, gives you the three pillars required - that is, a database, authentication, and storage - to build an app and keeps your project focused on launch speed without locking you in.

When it comes to interfaces, Supabase is also much easier to use. It is focused and clean, with clear calls to action. Firebase can feel overwhelming, especially on the landing page where there are numerous calls to action, information modules, and announcements.

## **Firebase pricing comparison with Supabase**

Both Firebase and Supabase have a free tier that is generous. However, the major difference between Firebase and Supabase is how data transfer is charged.

Firebase charges are based on a per-call basis, while Supabase pricing is based on overall data transfer. While per-call may sound great because you are only paying for what you're using, it can easily add up if your app is not properly optimized.

For example, in Firebase, each collection returned is counted as a call. This means that if your data returns a collection list of 10 items, this equates to 10 calls in total. If there are 10 people on a view that implement this call, then it is 100 database queries. If you scale this up to 1000 users, then your number of calls explodes rather quickly. If we think of our application as a whole, it can easily find itself up to a few thousand, if not ten thousand database queries for just a single user traversing through your app.

Supabase's pricing module is much better for data. In the beginning, an MVP app's data is often not mature enough yet to be ready for optimization. Database charges based on data transfer make it easier to work with, in addition to being more familiar for many of us. We do not need to worry too much about how many connections we are making, but more about the size of the data being transferred.

## **The wrap-up: Supabase for your next MVP project**

Overall, if you're looking for a platform that will allow you to build as quickly as possible without distraction and frills, then Supabase is the way to go.

It is simple to use, has a minimalist approach to its interface, great pricing that won't burn your pocket as your app scales, an integrated authentication system, and storage space for your single-page app. This means that if you're a frontend developer, you can easily create an app without the learning curve that comes with creating a backend from scratch.

Integrating with Supabase is API-based. The documentation is easier to navigate and mentally digest than Firebase's, making the process more intuitive whilst remaining low-code.

If you have a weekend project in mind and find Firebase too overwhelming to work with, Supabase might be the right platform for you.

Supabase vs. Firebase - which one is better?

Is Supabase your new Firebase alternative?

*Which bootstrap cloud stack should you choose?*

Google Firebase, Digital Ocean App Platform, and AWS Amplify all seem to do the same thing - they exist to help you launch your app into the cloud as quickly as possible. But how comparable are they as a full-stack cloud service?

Here is a quick rundown of everything you need to know about the services, things to consider, and how each cloud platform impacts your short and long-term infrastructure and strategy.

But before we begin, there is a question that needs to be answered - are full-stack app platforms worth the time and investment?

## **Full-stack App Platforms and What Exactly They Do**

Nowadays, it's not hard to launch something into the cloud. However, going beyond beginner tutorials can be a mission. There are multiple things to consider such as scalability, security, and accessibility.

Just because you can code, it doesn't mean that you're capable of doing infrastructure at an expert level. While it's arguable that we all have to start somewhere, sometimes going all-in on cloud infrastructure from scratch can be costly for the size and initial scale of your project.

In short, it can be a bit overkill.

This is where app platforms step in. Services like Google's Firebase, Digital Ocean's App Platform, and AWS Amplify offer quick solutions for developers that want to focus on developing the app rather than spend their time dealing with infrastructure and learning the operations side of development.

Common features of app platforms include scalability, fully managed security, identity services, integrated databases, and support for popular frameworks such as React, Angular, Vue, Next.js, Android, and iOS.

In short, when you're using an app platform, you are getting services that are created to fit together out of the box. The infrastructure is pre-configured and requires minimal understanding and setup to get started.

## **Google Firebase**

Google's Firebase has been around for almost a decade now. The idea behind the platform is to provide all that is necessary for launching scalable mobile and web applications rapidly.

Firebase is integrated with Google's other products such as Analytics and Cloud Storage and includes a proprietary database of the same name.

The process of using Firebase is fairly straightforward - you sign up for an account, upload your frontend or application to the Cloud Hosting portion of Firebase, set up your database and permissions, and that's basically it.

In addition to this, there are extensions that can be used to enhance your app with extra features such as sending messages, triggering emails, and implementing payment methods.

The ability to integrate with popular services such as Slack and Jira means that you can also build automation and bots through Firebase.

Firebase's pricing is based on a pay-per-usage model. The traditional model for cloud infrastructure is often based on the number of hours used. However, with the pay-per-usage model, it means that you can have your app up on the platform but it can remain in an active dormant state until required with no subscription fees or additional cost to you.

## **Digital Ocean App Platform**

Digital Ocean's App Platform is the next contender for the platform-as-a-service (PaaS) space. However, unlike Firebase, Digital Ocean's App Platform is structured in a more traditional cloud manner.

In a way, this is a perk for Digital Ocean. The pricing for Digital Ocean's App Platform is fixed and fairly low. The terms are clear and there is no fuzzy area when it comes to the final bill. This makes budgeting for small and indie developers easier. You won't get an unexpected bill if there is a spike or inefficient usage of the database. For example, in 2018, a crowdfunding campaign went viral and ended up racking [$30,356.56USD in 72 hours on Firebase](lhttps://www.dottedsquirrel.com/30k-firebase/).

No one wants that kind of bill attached to their account - especially in a startup context or single developer working on a side project.

With Digital Ocean's App Platform, you get given containers, which is basically your own little machine that you can scale up or down easily based on your chosen plan. It comes fully integrated with bits and pieces that are typically required such as pre-configured databases, storage, and automated app stack setups.

## **AWS Amplify**

In a way, AWS Amplify is similar in concept and implementation to Google's Firebase. The major difference is that you're working with Amazon instead of Google-based services.

AWS Amplify, on a technicality, is a lot younger than Google's Firebase. Launched in late 2017, AWS is almost half its age when compared against Google's Firebase. However, the services that are provided by AWS are not new.

While Firebase can be seen as a stand-alone platform with integrations into Google's Cloud ecosystem, AWS Amplify is a repackaged set of resources that's already in existence. These services include CI/CD, push notifications, storage (via S3), data storage via DynamoDB, and static websites.

The pricing for AWS Amplify is split between the different services that you end up using. This means that unlike Google's Firebase and Digital Ocean's App Platform, there is no single price as such. You end up with multiple pricing tables to navigate through and different payment models to work with.

## **Firebase vs. Digital Ocean App Platform vs. AWS Amplify - which one is best?**

When it comes to choosing between AWS and Google PaaS, there is a level of provider lock-in. This is because AWS uses DynamoDB as their data storage offering. In contrast, Firebase offers Firebase Realtime Database and Cloud Firestore. Your entire query layers will need to be catered to these service provider-specific databases. This means that if you want to switch providers or move your application out of the PaaS, you may find yourself too tightly coupled to either AWS or Google.

Digital Ocean doesn't have this problem. The application you build and launch to Digital Ocean's App Platform is expected to be service provider agnostic. In contrast, to achieve the same effect on Google's Firebase and AWS Amplify, you will need to go down the route of the traditional cloud infrastructure setup.

When it comes to pricing, Digital Ocean App Platform offers up the most certainty. Google's Firebase is predicated on the correct configuration of your API calls to your database. AWS Amplify is like using AWS under normal circumstances but repackaged under the Amplify hood.

So is there a clear winner?

The quick answer is yes. Digital Ocean seems like the best option to go with when it comes to launching an app. There is no application lock-in, and you're dealing with a more traditional approach to app creation.

Overall, whoever you end up with is dependent on your situation, short-term and long-term needs. If you are budget conscious, want certainty and space to just launch your app, then Digital Ocean might be the way to go.

Google Firebase and AWS Amplify do have their merits. If you're focused on building an app that is serverless and fully automated with scaling, Google Firebase and AWS Amplify may just be the right option for your situation. If you also have other apps within Google or AWS' ecosystem, integrating it with your deployed app may also be much easier than launching your MVP in a different space.

In the long run, there is no correct answer -- only an app that needs to be launched and adapted over time to your needs and your users' needs.

Firebase vs. Digital Ocean App Platform vs. AWS Amplify  

Serverless is not new. Up until the mid-2000s, servers were giant rooms that lived on-premise to provide businesses with the infrastructure they needed to run their centralized software systems. Then along came cloud computing, along with ideas like elastic load balancing, on-demand self-service, resource pooling, and infrastructure as a service.

Cloud computing turned infrastructure into convenience and made it highly accessible, especially for the 'little guys' that did not have big infrastructure budgets to buy the hardware to run their services. 

By the time 2015 rolled around, the term 'serverless' was thrown around. The idea behind *serverless* is that the provider took away the need for teams to manage server configurations and architectures. This meant that developers can focus on the business logic and nothing much else. 

From here, Function as a service (FaaS) came into existence. 

## What is FaaS?

The idea behind FaaS - or Function as a Service - is a cloud computing service that lets developers develop microservice-based applications without the need to worry about infrastructure-related activities such as provisioning, load balancing, and architecture. 

With FaaS, all the hardware, operating systems, virtual machines, and general management are left to the FaaS provider. The benefits of FaaS are:

- **more code, less infrastructure**: your servers are scaled automatically and independently by your chosen provider. This makes it cost-effective in terms of time and resources as it doesn't require a developer to set up everything.
- **automated scaling**: there is no need to worry about provisioning for peak times, capacity planning or when no one is using your functions. You only get charged for what you use. This is scaled in an automated manner and is event-based. 
- **high availability**: FaaS tend to have multiple availability zones, making it a distributed system that can run in different regions without incurring extra costs. 

## What is Serverless?

FaaS is a subset of Serverless. While FaaS is targeted directly at functions that can be used to orchestrate different parts of the business logic, Serverless deals with anything where the responsibility of infrastructure provisioning and architecture can be delegated to the provider. 

This means that serverless also includes services such as compute, storage, databases, and API gateways. The processes of serverless are generally invisible to the end-user and wholly managed by the provider. 

## How to structure a Serverless FaaS project

When it comes to creating a FaaS serverless project, there are two types of functions - `RESTful` and `Reactive`.

`RESTful` functions are your traditional `RESTful` functions. It runs when an `HTTP` request is made. A `reactive` function gets executed in a FaaS when something changes. 

The general structure for FaaS is that there is one file per function. The function also belongs into a RESTful or reactive folder. You then split the backend into resource groups to keep everything tidy and traceable. Here is an example of a file structure based on eCommerce resource groups.

```
functions
- orders
	- reactive
	- restful
- payments
	- reactive
	- restful
- users
	- reactive
	- restful
```

With this file structure, you can build out your entire backend as functions that either respond to HTTP requests or 'react' to something that happened as a result of a database change or event. 

## Top serverless frameworks to check out

It's easy to write serverless functions. However, things can quickly get out of hand as your backend requirements grow. This is where frameworks come in. The purpose of a framework is to provide structure and predictability for a project.  Here are 7 serverless frameworks to check out for your FaaS project.

###  Serverless

[Serverless](https://www.serverless.com/) is one of the original serverless framework supporters that is free, completely open-source, and written using Node.js. It was developed to help build applications on AWS Lambda and also has support for Azure Functions, IBM Cloud Functions, and Google Cloud Functions. 

### Zappa

[Zappa](https://github.com/zappa/Zappa) is a serverless framework for Python. Zappa makes it easy to build and deploy server-less and event-driven applications in the cloud. It works directly with AWS and API Gateway to give each request its own virtual HTTP 'server' through Lambda functions. 

### Chalice

[Chalice](https://github.com/aws/chalice) is another AWS Python-based serverless microframework. It comes with a command-line tool for creating, deploying and managing your app's functions. You can also create decorator-based APIs for integrating with AWS API Gateway, S3, SNS, SQS, and automatic IAM policies for increased security. 

### Architect

[Architect](https://arc.codes/docs/en/get-started/quickstart) is a Node.js based serverless framework that helps developers create opinionated database-backed web apps with AWS. The idea behind Architect is to equip developers with tools such as fast local development, smart configurable defaults, and infrastructure as code. 

### Claudia.js

[Claudia.js](https://claudiajs.com/) is a framework that jets you deploy node.js projects quickly and easily to AWS Lambda and API gateways. It comes with built-it deployments, configuration tasks, and sets up a majority of what you need out of the box. You can deploy and update using a single command, manage multiple versions easily, and has a low learning curve to get started. 

### Webiny

[Webiny](https://www.webiny.com/) is a serverless framework built for creating GraphQL APIs, full-stack applications, and websites to run on AWS Lambda and DynamoDB. Webiny is completely open-source that also supports multi-tenant SaaS applications with modern dev toolchain support such as TypeScript, Jest, ESLint, Yarn 2, and Pulumi. You can also use the provided templates to scaffold REST or GraphQL apis. 

### Up

[Up](https://apex.sh/up/) is another free open-source serverless project that lets you create serverless orchestrations with single command deploys. It also comes with structured logging, free SSL and custom domains via AWS ACM. Deployments made with Up is also immutable, meaning that you can roll back to previous versions in an instant. 

## Wrapping up

While there may be a bit of vendor lock-in for serverless, the code created in a FaaS context is generally independent of where it gets deployed to. For trigger-based FaaS, the code for these events may be tied to your vendor and the triggered service provided. There may also be some initial configurations involved for security policies and accessibility.

Overall, serverless is a cost-effective infrastructure solution that removes the need for infrastructure management. This is all done for you - off-premise and on demand with multiple availability zones across the globe. 



Serverless - an overview starter guide

The idea of Buildpacks has been around since 2011. It was first created by [Heroku](https://www.heroku.com/), with [Pivotal](https://tanzu.vmware.com/) jumping on board to help create Cloud Native Buildpacks. But what are buildpacks?

The concept is simple: turn your application source code into runnable container images that can work on any cloud. Think of it as similar to a snapshot of your source code that can be deployed to different cloud platforms.

The major point of difference for Buildpacks is that it is a framework. This also means that a platform tool is required to orchestrate the creation of your application image. Buildpacks is widely supported by tools and platforms such as  [pack CLI](https://buildpacks.io/docs/install-pack/), [kpack](https://github.com/pivotal/kpack), [Tekton](https://github.com/buildpacks/tekton-integration), [Google cloud run button](https://github.com/GoogleCloudPlatform/cloud-run-button), [Heroku](https://devcenter.heroku.com/articles/buildpacks), [Skaffold](https://skaffold.dev/docs/pipeline-stages/builders/buildpacks/), and [Build.io](https://layercode.com/buildio).

So how do Buildpacks work? and why do they matter?

## How Buildpacks work

Buildpack exists to create an image of your source code and its associated requirements to make it run. The idea is that Buildpacks will take a look at your apps, download the dependencies,  configure the apps, and communicate with bound services to make things work. 

There are two parts to working with Buildpacks - creating the image and using the image. 

Here is a quick example of how to create an image using the CLI `pack` command:

```
cd my-layercode-app-repo
pack build my-image --builder layercodebuildpacks/builder:base
```

The above command will trigger the lifecycle of a buildpack, which follows the four steps below: 

```
Detect --> Analysis --> Build --> Export
```

Here is a quick summary of what happens during each stage of a buildpack execution lifecycle that results in an app image:

- `Detect` - platform tool finds the targeted buildpack group to build.
- `Analysis` - restore any files that buildpacks may use during the build and export phases.
- `Build` - turns application source code into runnable artifacts that is then packaged into a container.
- `Export` - creates the final image that contains the runnable application. 

During this lifecycle process, there is one compulsory script (`buildpack.toml`) that runs and four additional scripts that sit in the `bin` directory. Here is a quick description of what they do:

- `buildpack.toml` - this file provides the metadata about the current buildpack. 
- `bin/detect` - scripts in this folder are used to sequentially test groups of buildpacks on the source code. If conditions are passed, the buildpack will proceed to the next app-build phase
- `bin/supply` - provides dependencies for the app
- `bin/finalize` - prepares the app for launch.
- `bin/release` - gives metadata back to the platform on how the app should be executed. 

For older buildpacks, there may be a `bin/compile`. However, this is no longer in use and has been deprecated with `bin/supply` and `bin/finalize` as the alternatives. 

Buildpacks also populate a Bill-of-Materials, or `BOM`, to provide extra information on what's inside your container and how it was constructed. Here is an example command on how to view your buildpack's `BOM`:

```
pack inspect-image your-image-name --bom
```

That's the introductory beginner's gist to how Buildpacks operate. 

## Buildpack commonly asked questions:

### How are Buildpacks different from Docker Images?

When it comes to Docker, you can build containers via Dockerfile - which is a set of commands that results in a container image. Dockerfiles requires a base image to start from, meaning that commands are built on top of this base image to modify them.

In contrast, Buildpacks turns your source code into a runnable container image. This is achieved through a set of executions that looks at your source code and generates a plan to build and run your application. It does this by encapsulating the app's language ecosystem toolchain and grouping them together into collections called a *builder*. An additional layer may be added that includes dependencies and commands. It creates the container rather than using a pre-existing container that later gets modified based on defined requirements.

### Can you use buildpacks inside Docker?

The quick answer is yes. This is because Docker is the containerized environment that holds the code. A buildpack is the code image, meaning that it is separate from the environment itself. 

### What is a buildpack builder?

A builder is an image that contains everything needed to execute a build. A builder image includes the buildpack itself, the lifecycle files, and the stack.

A stack is two images that are used by the builder and added as part of the buildpack. These images are the build image and the run image. The build image gives the base image where the build environment is constructed. The run image provides the base image where the application images are built. 

### Where do Buildpacks fit into the app development cycle?

Buildpacks lets you containerize your code and turn them into pre-packaged copies of your app that works at runtime. It achieves this through the set of scripts that will perform dependency retrieval tasks and anything else that's required to compile and run the code. 

With Buildpacks, there is no need to set up the base infrastructure for the virtual machine. Instead, the image can be used to deploy to infrastructure platforms such as [Build.io](https://layercode.com/buildio) and run apps in the cloud with ease. 

![buildioStep2.png](https://res.cloudinary.com/layercode/image/upload/v1641601866/buildio_Step2_95a2b20589.png)

### Which cloud infrastructure platforms support buildpack deployment?

Major cloud platforms such as [Google Cloud](https://cloud.google.com/blog/products/containers-kubernetes/google-cloud-now-supports-buildpacks), [AWS](https://aws.amazon.com/blogs/containers/creating-container-images-with-cloud-native-buildpacks-using-aws-codebuild-and-aws-codepipeline/), and [Azure](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-tasks-pack-build) have buildpack deployment support. Heroku and [Build.io](https://layercode.com/buildio) are comparable services that create an easy deployment bridge for your chosen cloud infrastructure. 

### What's the difference between Buildpacks and buildpacks?

**B**uildpacks with capitalization refers to the framework. In contrast, **b**uildpacks with the lowercase 'b' refers to the buildpack itself. 

## Wrap up

Overall, buildpacks are a versatile way to package up your apps for deployment. The major perk is that it reduces the general time costs that come with trying to ensure that everything in the deployment is in sync. Turning your source code into a runnable image, it makes shipping apps faster by cutting down the need to manually set up the code and its dependencies for each deployment. 



# Cloud

How to set up Firebase Authentication in React

How to Use Firebase Analytics with Angular

Is Supabase your new Firebase alternative?

Firebase vs. Digital Ocean App Platform vs. AWS Amplify

Serverless - an overview starter guide

How Buildpacks work and other commonly asked questions