Mobile App- Backend Architecture on GCP (Part-2)

Since there are a lot of details involved in this project, I won’t go into the specifics of every part. At this point, you need to create a cluster on Google Cloud. You should determine your cluster configuration, the number of nodes, etc., based on your needs. (I started with a 3-node e2-standard type as a starting point.) One thing to keep in mind is that if you are new to working with Kubernetes or similar technologies and proceed with minimal configurations, you might encounter resource limitations when deploying your services later on. Resolving errors during deployment due to these limitations might take some time, but perhaps that’s the best way to learn.

While our Kubernetes Cluster is being set up, let’s switch to Firebase and start creating our applications.

Sign in

After creating your application, you will be greeted by Firebase’s welcome screen. Our first task here will be to create an application. To do this, we’ll select one of the icons in the middle of the screen. I’ll proceed with iOS.

Since I’m detailing the actual app development process while writing this article, using iOS doesn’t pose any issues at this point. However, if you choose to go with iOS, you’ll need to handle processes like registering the app on the Apple Developer portal, uploading a provisioning profile, and creating an Apple key.

If you’re creating an app for Apple, you’ll need to download the “GoogleService-Info.plist” file; for Android, you’ll need the “google-services.json” file. These files will need to be included in your iOS and Android applications.

At an appropriate time, I’ll also prepare a separate article dedicated to the processes on the mobile side of the project.

In Firebase, we’ll also integrate many features from the left-hand menu into our mobile applications.

While we’re handling these tasks, our Kubernetes cluster should be set up and ready to go. Let’s get back to the backend and continue from there.

Domain Setup

Since our applications will be communicating with our services through an API, the first step is to prepare our domain. The first task in this process is to obtain an SSL certificate.

To do this, go to the Certificate Manager in the Security Center on Google Cloud and create a certificate for your domain. You can do this by selecting the ‘Create new Certificate’ option. If you already have a certificate, you can use it, or you can offload that task to Google as well. (I prefer to offload as many tasks as possible to Google.)

After selecting ‘Create Google-managed certificate,’ Google will ask you to verify your domain, as shown in the image below. I recommend using DNS verification for this.

After adding the domain, Google will generate the DNS records you need to add for verification. It’s better to add these DNS details to your domain nameserver before clicking the ‘Create’ button.

The name I used when creating the certificate is ‘api-example-com-cert,’ which we will use later.

Once you’ve added these details to the nameserver of the domain, you can relax with a cup of tea and click the ‘Create’ button.

You will need to wait a bit for the certificate to be provisioned. Once the certificate is verified and created, it will become active.

After this, you need to create a certificate map to use the certificate in GKE.

To do this, you must first create a map-entry on Google.

gcloud certificate-manager maps create api-example-com-map

With this command, you create a certificate map. Afterward, you need to associate this map with the certificate you created.

gcloud certificate-manager maps entries create \
api-example-com-map-entry \
 - map=api-example-com-map \
 - hostname=api.example.com \
 - certificates=api-example-com-cert

With this command, you can create the map entry for your certificate and get it ready for use.

Deploy APIGateway

Why I Chose Gateway Over Ingress

When I started building the backend for my project, Ingress was the obvious choice for managing traffic — tried, tested, and reliable. But as I dug deeper, I realized my project needed more than what Ingress could offer. That’s when I choose Gateway API.

This project wasn’t going to be simple. It needed flexibility and the ability to handle complex traffic rules. Gateway offered that and more. It wasn’t just about routing traffic; it was about doing so with precision and preparing the system for future challenges.

Why Gateway Made Sense

Gateway allowed me to separate traffic handling from internal routing, giving me the control and scalability I needed. It also aligned with the future direction of Kubernetes, making it a forward-thinking choice. I knew this decision wasn’t just solving today’s problems — it was setting the stage for tomorrow.

Of course, Gateway came with its complexities. It required more setup and a deeper understanding of Kubernetes. But the benefits — like better security, granular control, and seamless integration with service meshes — made it worth the extra effort.

Ultimately, choosing Gateway over Ingress was about building an architecture that could grow and adapt as the project evolved.

Since I have used KONG before, I prefer to use KONG as my Gateway again. At this point, you can choose to use the native Gateway class if you prefer.

In this case you will need to remove lines related with kong.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: api-gateway
spec:
  controllerName: konghq.com/kic-gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: api-mobile-gateway
  annotations:
    networking.gke.io/certmap: api-example-com-map
    kubernetes.io/ingress.global-static-ip-name: api-ip-adress
spec:
  gatewayClassName: kong
  listeners:
  - name: proxy
    port: 80
    protocol: HTTP
  - name: https
    protocol: HTTPS
    port: 443

The line “ networking.gke.io/certmap: api-example-com-map” includes SSL definition of our certificate.

We deployed our Gateway now.We can do a simple test for this.I will create and deploy a nginx container for this as a service.

Deployment file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-test
  labels:
    app: web-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-test
  template:
    metadata:
      labels:
        app: web-test
    spec:
      containers:
        - name: webapphost
          image: nginx:1.19-alpine
          imagePullPolicy: Always
          ports:
            - containerPort: 80

Service yaml

apiVersion: v1
kind: Service
metadata:
  name: web-test
  labels:
    app: web-test
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: web-test

kubectl apply -f nginx-deploy.yaml
kubectl apply -f nginx-deploy.yaml

Once you have deployed these service we are ready to define this to our gateway.

Here is HTTP Route comes in.

home-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-home-route
  annotations:
    konghq.com/strip-path: 'true'
spec:
  hostnames:
  - api.example.com
  parentRefs:
  - name: api-mobile-gateway
  rules:
  - matches:
    - path:
        type: Exact
        value: /
    backendRefs:
    - name: web-test
      kind: Service
      port: 80

Once you deployed route , you can visit your domain.

Holaa :

Follow up for next parts.