Become a cloud pro with hands-on experience in developing, styling, and managing a Cloud-Native web application using Tailwind, Google Cloud, and Firebase. No setup, no cleanup, no hassle.

Cloud Native Web Development - A Hands-On Guidebook-01.jpg

cloud-native-web-app.tar.gz

username

email

access_token

repository_name

author

firebase_proj_name

FIREBASE_TOKEN

cypress_key

cypress_projectID

dev_api_key

sapper

add-firebase-sdk

install-firebase-cli

cypress-cli

headless-mode

headless-mode-2

component-tests-1

component-tests-2

testing-library

cypress-dashboard

enable-tests-CI

enable-PR

svelte-intro

tailwindcss-component

tailwindcss-svelte

tailwindcss-svelte2

user-auth1

login-page

admin-page

user-svelte-store

signin-vs-signout

secure-admin-page

redirect

configure-firestore

create-user-interface-1

write-data-1

persist-new-blog-1

read-data-1

security-rules

configure-emulator

test-fcf-locally

new-service-placeholder

dev-integration

test-new-service

markdown2html

write-test-for-service-1

deploy-service-req-one

deploy-service-req-two

speed-up-CI-CD

local-dev

emulator-start

ch-2/lesson-5

ch-3/lesson-3

ch-1/lesson-4

ch-3/lesson-4

ch-3/lesson-5

ch-3/lesson-6

ch-4/lesson-3

ch-4/lesson-4

ch-5/lesson-1/1

ch-5/lesson-1

ch-6/lesson-2

ch-6/lesson-3

ch-8/lesson-3

ch-8/lesson-4

ch-8/lesson-6

ch-8/lesson-7

ch-8/lesson-8

ch-9/lesson-3

ch-9/lesson-4

ch-9/lesson-5

ch-10/lesson-1

ch-10/lesson-2

ch-10/lesson-3

ch-10/lesson-4

ch-10/lesson-5

ch-11/lesson-2

ch-11/lesson-3

ch-11/lesson-4

ch-11/lesson-5

ch-11/lesson-6

ch-11/lesson-7

create-user-interface-2

create-user-interface-3

create-user-interface-4

write-data-2

write-data-3

persist-new-blog-2

read-data-2

read-data-3

ch-12/lesson-2

ch-12/lesson-3

ch-13/lesson-2

ch-13/lesson-3

ch-13/lesson-4

ch-13/lesson-5

ch-13/lesson-6

ch-13/lesson-7

ch-13/lesson-8

ch-13/lesson-9

new-service-placeholder-copy

write-test-for-service-2

write-test-for-service-3

ch-14/lesson-1

This course is a hands-on guidebook to walk you through the journey to creating your first web application in the cloud.

In this course, you will have hands-on experience in developing, styling, hosting, testing, and efficiently managing a complete Cloud-Native web application. Along with this, you will learn how to make the important decision of choosing a technology or tool for your web application.

By the end of this course, you will have a set of expertise in developing cloud native web applications that will help you throughout your career.

Cloud Native Development with Tailwind, Google Cloud and Firebase

# Feature toggles

When we set up the continuous deployment pipeline, we encouraged you to:

<center style="font-weight:bold">Deploy early. Deploy often. Make it part of the culture!"</center>

An automated deployment pipeline is one piece of the puzzle to make frequent deployments successful, not scary, and most importantly, to avoid major incidents in the end-user experience. We want to avoid at all costs the consistent downtime or a buggy experience for web application users.

## What are feature toggles?

If you are not familiar with this term, maybe one of these sounds familiar:
* feature flag
* feature switch
* feature flipper
* conditional feature, etc.

In short,

**It's a mechanism to turn a feature on or off depending on certain conditions.**

What these conditions are is really up to you. A few examples:

* A basic boolean value to control a feature's visibility for all users. It's either on or off for everyone.
* A percentage value. 10% of users see the new features, 90% do not.
* A date value. The feature is visible on weekdays from 9 to 5 but hidden overnight and on weekends.
* A user profile attribute to target individuals or groups of people, such as
users who use the web application at least four times per week.

Depending on your situation, you may use other conditions that make sense in the
context of what you are working on.

Besides individual conditions as described above, nothing stops us from combining
conditions so that the new feature is only available to 5% of frequent users of the web app who previously provided feedback for a beta feature.

## Feature toggles to release unfinished code

Our first use of feature toggles is to hide unfinished code, allowing us to deploy to
production without fear of breaking anything unexpectedly.

The requirements for this work can be summarized as follows:
* Use Firebase Remote Config to store feature toggles.
* Use a Svelte store to store feature toggles on the client.
* Develop a Svelte component to deal with the potential complexity.

As we have not introduced the **Svelte** framework yet, Svelte is an open-source front end JavaScript framework. That's all we need to know for now. We will explain it in detail in the upcoming chapters.

Now, let's start working on the above-defined requirements one by one.

# Feature toggles

When we set up the continuous deployment pipeline, we encouraged you to:

<center>Deploy early. Deploy often. Make it part of the culture!"</center>

An automated deployment pipeline is one piece of the puzzle to make frequent deployments successful, not scary, and most importantly, to avoid major incidents in the end-user experience. We want to avoid at all costs the consistent downtime or a buggy experience for web application users.

## What are feature toggles?

If you are not familiar with this term, maybe one of these sounds familiar:
* feature flag
* feature switch
* feature flipper
* conditional feature, etc.

In short,

**It's a mechanism to turn a feature on or off depending on certain conditions.**

What these conditions are is really up to you. A few examples:

* A basic boolean value to control a feature's visibility for all users. It's either on or off for everyone.
* A percentage value. 10% of users see the new features, 90% do not.
* A date value. The feature is visible on weekdays from 9 to 5 but hidden overnight and on weekends.
* A user profile attribute to target individuals or groups of people, such as
users who use the web application at least four times per week.

Depending on your situation, you may use other conditions that make sense in the
context of what you are working on.

Besides individual conditions as described above, nothing stops us from combining
conditions so that the new feature is only available to 5% of frequent users of the web app who previously provided feedback for a beta feature.

## Feature toggles to release unfinished code

Our first use of feature toggles is to hide unfinished code, allowing us to deploy to
production without fear of breaking anything unexpectedly.

The requirements for this work can be summarized as follows:
* Use Firebase Remote Config to store feature toggles.
* Use a Svelte store to store feature toggles on the client.
* Develop a Svelte component to deal with the potential complexity.

As we have not introduced the **Svelte** framework yet, Svelte is an open-source front end JavaScript framework. That's all we need to know for now. We will explain it in detail in the upcoming chapters.

Now, let's start working on the above-defined requirements one by one.

Get a brief introduction of the feature toggles.

Introduction to Feature Toggles

Introduction

Create a GitHub Project Using Monorepo Template

Set Up Backend Using Sapper Template

Host Your Web App on Firebase

Set Up The Continuous Deployment Pipeline

Local Development

Feature Toggles

Production Monitoring & Rollbacks

Testing

Tailwind CSS

User Authentication

Database - Cloud Firestore

Firebase Local Emulator Suite

Trigger Services Based on Events

Final Tasks

What's Next?

Introduction to Feature Toggles

Feature toggles