I like building side projects. They’re how I learn new tools, test ideas, and stay sharp outside of work. Over the past year I’ve gone through a few stacks trying to find the right balance between developer experience, cost, and simplicity. I started with Vercel and Supabase. I ended up on Cloudflare and TanStack.

This post is about why.

What I moved away from

Vercel is genuinely excellent for development. The deployment workflow, preview environments, and Next.js integration are top-notch. For a team shipping a product, it makes a lot of sense. But for side projects the free tier is limited, and the moment you need anything beyond it - more bandwidth, analytics, or team features - the Pro plan jumps to $20/month per member. That adds up fast when you’re just experimenting.

Supabase has a similar story. It markets itself as a Firebase alternative with a Postgres database, and it is. But “Postgres under the hood” means you’re still writing SQL for everything - migrations, functions, triggers. The bigger friction is Row Level Security (RLS). In theory it’s elegant: your authorization lives in the database. In practice, writing and debugging RLS policies is painful. Every new table needs policies, every edge case needs another rule, and it slows you down when you’re prototyping.

When you combine the two, the costs stack up. Two paid services, two billing dashboards, and the Supabase free tier doesn’t include automatic backups. For a side project that might sit idle for weeks, that’s hard to justify.

Why Cloudflare ☁️

Cloudflare solves most of what bothered me about the previous stack. Everything runs at the edge - Workers, Pages, KV, D1 - distributed globally without any configuration. Your side project in Warsaw serves just as fast in Tokyo. Instead of stitching together Vercel for hosting and Supabase for the database, you get everything in one place: compute, hosting, database, key-value store, object storage, queues, and cron triggers. One dashboard, one bill.

The free tier is what sealed it for me. Workers get 100,000 requests/day, Pages offers unlimited sites and bandwidth, D1 gives you 5 GB of storage with 5 million reads/day, KV handles 100,000 reads/day, and R2 provides 10 GB with no egress fees. For a side project, you may never leave the free tier. And when you do, the paid plans are cheap.

After years of working with AWS IAM - writing JSON policies, managing roles, trust relationships - Cloudflare’s bindings model feels refreshing. You bind a D1 database or KV namespace to your Worker in wrangler.toml, and it’s available as a variable in your code. No IAM roles, no resource ARNs. Want to add a /api route next to your frontend? It’s the same Worker - just handle the path. No separate Lambda, no API Gateway configuration, no CORS headaches between services. Your frontend and API live together, share the same bindings, and deploy as one unit. The ecosystem backs this up - TanStack Start, Hono, and React Router all deploy to Workers out of the box. When multiple major frameworks invest in your platform, that’s a strong signal.

Why TanStack ⚡

The other half of the equation is the framework. TanStack Start gives you a full-stack React framework with server-side rendering, file-based routing via TanStack Router, and built-in data fetching with TanStack Query. Everything is type-safe end-to-end - from route parameters to API responses. The router catches errors at build time instead of runtime, and Query handles caching, deduplication, and background refetching out of the box.

What matters most for side projects is portability. Unlike Next.js, which is deeply tied to Vercel’s infrastructure, TanStack runs anywhere - Cloudflare Workers, Node.js, Deno, or Bun. If I ever want to move, I can. You don’t want to be locked in to infrastructure you might stop paying for. The developer experience is excellent without the framework trying to own your deployment.

Comparison

How I structure a project

In practice, I run two Cloudflare Workers as a monorepo. The frontend is a TanStack Start worker handling SSR and file-based routing. The backend is a Hono API worker handling auth, database, and business logic. The frontend calls the backend directly through a Cloudflare service binding - no HTTP round-trip, no CORS, just an internal env.API.fetch() call. Both workers share the same cookie prefix, so auth tokens flow seamlessly between them.

For data, D1 handles the relational storage with Drizzle ORM for type-safe queries and migrations. KV stores session data - specifically refresh tokens for the JWT auth flow. R2 is available for file uploads when needed. Everything is bound to the workers through wrangler.toml, so there’s no infrastructure to provision beyond the config file.

This setup deploys as two workers with a single wrangler deploy per workspace. The service binding between them means the frontend-to-backend call stays within Cloudflare’s network - no public endpoint needed for the API.

One small detail worth mentioning: I prefix backend routes with /a/ instead of the conventional /api/. I noticed that /api paths are regularly scanned by bots - automated crawlers probing for exposed endpoints, looking for common frameworks and vulnerabilities. Switching to /a/ reduced random worker invocations to a minimum. It’s a simple change, but it keeps noise out of your logs and your free tier usage low.

Cloudflare’s perception problem

I have a feeling that Cloudflare is not promoted enough as a hosting and application platform. Most developers still think of it as a CDN or a DNS provider. When they hear “Workers,” they picture a backend-only compute layer - something like AWS Lambda, not a place to run a full-stack app. But Workers serve static assets alongside your server code. You deploy one thing and it handles everything.

D1 has a similar perception issue. People hear “SQLite” and immediately associate it with pet projects or local development. SQLite on a single machine - sure. But D1 is SQLite replicated globally across Cloudflare’s network. It handles reads at the edge with automatic replication. That’s not a pet project database - that’s a globally distributed data layer. Yet the “SQLite” label makes people dismiss it before looking at what it actually does.

The result is that Cloudflare has quietly built a serious application platform - Workers, Pages, D1, KV, R2, Queues, Durable Objects - but many developers don’t consider it because the naming and associations don’t match what they expect from “enterprise” or “production-grade” infrastructure.

A note on reliability

Cloudflare has had several notable downtimes in recent months, and that’s worth acknowledging. If your side project grows into something people rely on, a single-vendor dependency becomes a real risk. The good news is that the stack I described is portable by design. TanStack Start can run on AWS Lambda via serverless or on Google Cloud Run with Docker and Bun. Hono has first-class support for both AWS Lambda and Google Cloud Run. Neither framework locks you into Cloudflare’s runtime.

For one of my side projects I’ve started exploring this as an option - setting up a backup for API endpoints on AWS or GCP, so that if Cloudflare becomes unavailable, traffic can fail over to an alternative. It’s a wider architecture problem that touches DNS failover, database replication, and session portability. I might write a dedicated post about it in the future.

Closing thoughts

There’s no perfect stack. Vercel and Supabase are solid products, and for a funded team shipping fast, they might be the right choice. But for side projects - where you want to keep costs near zero, avoid unnecessary complexity, and still build something real - Cloudflare and TanStack hit the sweet spot.

I get global distribution for free, a database that doesn’t require RLS gymnastics, and a framework that doesn’t lock me in. That’s enough to ship ideas without worrying about the bill.

Introduction

Leader election is a crucial pattern in distributed systems where multiple instances or nodes compete to perform certain tasks. In a Kubernetes cluster, leader election can be used to ensure that only one instance is responsible for executing leader-specific tasks at any given time. This blog post will explore how to implement a leader election mechanism in Kubernetes using lease locks.

Overview

The leader election mechanism implemented in Go code relies on Kubernetes coordination features, specifically Lease object in the coordination.k8s.io API Group. Lease locks provide a way to acquire a lease on a shared resource, which can be used to determine the leader among a group of nodes.

Repository

The example code, used for this blog is available on mjasion/golang-k8s-leader-example GitHub repository.

Code Walkthrough

The main function is the entry point of the program. It reads configuration values from environment variables and obtains the Kubernetes clientset by getting access to Kube-Api by ServiceAccount attached to Pod. The application is written to work in Kubernetes Pod, that’s why it is using rest.InClusterConfig() function.

The leader election configuration is set up using the LeaderElectionConfig struct from the Kubernetes client library. It specifies the lease lock, lease duration, renewal deadline, retry period, and callback functions for leader-specific tasks.

leaderElectionConfig := leaderelection.LeaderElectionConfig{
    Lock: &resourcelock.LeaseLock{
        LeaseMeta: metav1.ObjectMeta{
            Name:      lockName,
            Namespace: leaseNamespace,
        },
        Client: clientset.CoordinationV1(),
        LockConfig: resourcelock.ResourceLockConfig{
            Identity: os.Getenv("HOSTNAME"),
        },
    },
    LeaseDuration: time.Duration(leaseDuration) * time.Second,
    RenewDeadline: time.Duration(renewalDeadline) * time.Second,
    RetryPeriod:   time.Duration(retryPeriod) * time.Second,
    Callbacks: leaderelection.LeaderCallbacks{
        OnStartedLeading: onStartedLeading,
        OnStoppedLeading: onStoppedLeading,
    },
    ReleaseOnCancel: true,
}

The most important settings are the lease duration, renewal deadline, and retry period:

• The LeaseDuration specifies how long the lease is valid.
• The RenewDeadline specifies the amount of time that the current node has to renew the lease before it expires.
• The RetryPeriod specifies the amount of time that the current holder of a lease has last updated the lease.

The leader-specific tasks are performed in the onStartedLeading function, which is called when the current node becomes the leader. The updateServiceSelectorToCurrentPod function updates the service selector to include the current pod’s hostname.

func onStartedLeading(ctx context.Context) {
	log.Println("Became leader: ", os.Getenv("HOSTNAME"))
	clientset := getKubeClient()
	updateServiceSelectorToCurrentPod(clientset)
	go func() {
		for {
			select {
			case <-ctx.Done():
				log.Println("Stopped leader loop")
				return
			default:
				log.Println("Performing leader tasks...")
				time.Sleep(1 * time.Second)
			}
		}
	}()
}

The onStoppedLeading function is called when the current node stops being the leader. It can be used for cleanup tasks.

func onStoppedLeading() {
	log.Println("Stopped being leader")
}

A context and a wait group are created to manage goroutines. A goroutine is started to run the leader election using the leaderelection.RunOrDie function.

ctx, cancel := context.WithCancel(context.Background())
defer cancel()
wg := &sync.WaitGroup{}
wg.Add(1)

go func() {
    defer wg.Done()
	leaderelection.RunOrDie(ctx, leaderElectionConfig)
}()

cancel()
wg.Wait()

The program also sets up a Gin router and defines a root endpoint that returns the hostname of the current node, to easily check which Pod is being the leader.

Demo 1 - Deploying a single Pod

In this demo, we will deploy a single Pod to a Kubernetes cluster and observe how the leader election works.

As you can see here, the pod is elected as a leader and performs leader-specific tasks. The lease object contains the information about the current leader in the HOLDER column.

NAME                 HOLDER                               AGE
k8s-leader-example   k8s-leader-example-8dd646bb7-dsfmq   11s

Demo 2 - Deploying multiple Pods and killing the leader

In this demo, we will deploy multiple Pods to a Kubernetes cluster and observe how the leader election works. The settings used for this demo are as follows:

The leader election mechanism will attempt to renew the lease every 5 seconds. If the lease is not renewed within 5 seconds, the leader election mechanism will attempt to acquire the lease. If the lease is not acquired within 1 second, the leader election mechanism will retry to acquire the lease.

Running command kubectl get lease --watch allows to observe the leader election process. The lease object contains first the information about the previous leader, when the leader is killed, and then the information about the new leader.

Conclusion

Implementing leader election in Kubernetes using lease locks is an effective way to ensure that only one instance or node performs leader-specific tasks at a time. In this blog post, we explored the provided Go code that demonstrates how to implement leader election in a Kubernetes cluster.

By incorporating leader election into your distributed system, you can enhance its reliability and prevent conflicts that may arise from multiple instances attempting to execute the same tasks simultaneously.

By default resources, you launch on the cloud (EC2, RDS, and others) cannot communicate with your local networks like home or office. To allow this you can create a Site-to-Site VPN. This VPN connection will be established between your router and AWS VPC.

Creating VPN between networks is well documented. However, you can have issues configuring your home router. At home, I have a Unifi Dream Machine router, which is designed for small networks, but has features that match advanced routers for offices. One of them is a Site-to-Site VPN using the IPSec protocol.

Setup VPN on AWS ☁️

The first step is to create a VPN connection on AWS. For this blog I will use… the default VPC 🙂. To configure it AWS requires to define 3 components: Customer Gateway, Virtual Private Gateway and VPN connection.

The Customer Gateway is basically just an entity that holds the information about your home router - public IP. The Virtual Private Gateway is the virtual entity on the VPC side, that allows configuring routing to that gateway. That VPG is attached to the VPN. So the last entity is the VPN connection which brings it all together and establishes the VPN tunnels between your home or office and VPC.

Create base components 🏗️

To start your VPN connection start by defining Customer Gateway. Go to the VPC tab, find the Customer Gateway panel and click the button to Create. The required field is IP address. Write here your public IP address where your router is running. Also, it is good to name this gateway. I named mine home.

To quickly check you public IP you can open https://ifconfig.co

The next step is to create a Virtual Private Gateway. Go to the Virtual Private Gateway panel and click Create. It just asks for a name. Let’s name it also home. The VPG state will be detached. I will come back to it later.

Create a VPN connection 🔒

This is the time to start defining VPN. Open the Site-to-Site VPN connection panel and click Create VPN Connection. The form will have 3 panels: details and tunnel options.

Details start from defining the gateway on the VPC side. Choose Virtual private gateway and in the form select your VPG.

Next select Customer gateway. Here you define with which router the VPN will be established.

There is the last configuration to set: routing. It is a section where you can define which local networks the VPN will be used for. On the screenshot, I marked this as a point 1.

AWS allows for two options: dynamic routing based on BGP, and statically defined. In my case, I am using static. In the prefixes, I am putting my local network prefixes(like 192.168.1.0/24). You are allowed to put multiple networks here.

Configure Tunnel Options ⚙️

Tunnel options allow defining the IPSec parameters. AWS creates 2 tunnels, to which you can connect and each of them you can configure differently. Or the same 🙂.

What I am always choosing is:

• Encryption algorithms: AES-256 (for both phases)
• Integrity algorithms: SHA2-256, SHA2-384, SHA2-512
• DH groups: all above 14
• IKE Version: ikev2

Those parameters will be crucial for setting up our Unifi router.

When you finish these changes you can create the VPN and wait a few seconds. The VPN connection should be ready.

Configure VPC Routing 🛣️

Previously I mentioned that the Virtual Private Gateway state is not attached to any VPC. We can reassign the VPN connection between VPCs by changing attachments.

To attach go back to Virtual Private Gateway and select your VPG and in Actions, button find Attach to VPC. Select your VPC and your VPG should be available to configure routing on VPC.

On VPC the last thing to configure is routes. As we have assigned VPG, and networks from our home are known (configured on VPN with static routes), we can configure automated propagation of those rules to VPC route tables. To configure this perform:

1. Go to Route tables
2. Select routes assigned to VPC, or those which should have access to your home.
3. Select Actions button, and choose Edit route propagation,
4. Select Virtual private gateway

After a few seconds, the new route should be added As you can see, the last route is “Propagated”, and its target is my virtual private gateway.

Setup VPN on Unifi 🏠

Having configured AWS VPC, the last part is to configure our router. In my home, I have Unifi Dream Machine, with the latest software (Network 7.1).

To create a VPN connection:

• Go to Settings > Teleport & VPN,
• Scroll down to Site-to-Site VPN and click Create,

Start filling out the form. The Pre-Shared Key you could configure in Tunnel Options. If you have skipped this, go to the AWS VPN tab, and click Download Configuration. In this file you will find the PSK to fill in point 1 and the Remote IP Address (point 4). In the Remote Gateway/Subnets(point 3) put AWS VPC network addressing. In my case, it was 172.31.0.0/16.

To align encryption options with Tunnel Options on AWS, select Manual in Advanced configuration and customize. Configure your parameters according to how you have configured them on AWS. I recommend using AES-256 and higher DH Groups and use the above image as an example.

Last step - testing 🪛

To check if you have a working VPN connection create an EC2 instance on this VPC.

I have created an instance with IP 172.31.34.95. This instance has a Security Group rule allowing for All Traffic from my home network. When the VPN works and instance is up, a simple ping can prove that everything is configured:

$ ping 172.31.34.95 -c 5
PING 172.31.34.95 (172.31.34.95) 56(84) bytes of data.
64 bytes from 172.31.34.95: icmp_seq=1 ttl=63 time=38.1 ms
64 bytes from 172.31.34.95: icmp_seq=2 ttl=63 time=38.2 ms
64 bytes from 172.31.34.95: icmp_seq=3 ttl=63 time=36.4 ms
64 bytes from 172.31.34.95: icmp_seq=4 ttl=63 time=38.3 ms
64 bytes from 172.31.34.95: icmp_seq=5 ttl=63 time=38.1 ms

--- 172.31.34.95 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 36.380/37.810/38.285/0.718 ms

If you are not sure that you are pinging EC2 take a look on ping response times. On local networks they are much lower.

Summary ☑️

Setting up VPN allows making your infrastructure secure. You don’t have to expose ports on the public internet to have access to cloud machines.

FAQ ❓

I have two network VLANs at home, should I configure some firewall rules if I don’t want to allow access from one of them?

Let’s assume you have two networks: home and guest. If the guest network should not have access to resources to VPN, on AWS VPN, in Static IP Prefixes configuration you have to set only home network subnet.

Another thing are Security Groups, where we define allowed networks. If you will not set too wide network range, then it will also block access.

In my previous post I showed how to enable debug logs. Today I want to present how to improve terraform plan and terraform apply speed by configuring parallelism.

Terraform by default runs 10 concurrent operations. To reduce execution time on plan or apply operation we can increase this parameter.

By increasing parallelism you can hit the rate limit of your provider. Some cloud providers (like Cloudflare) inform about the number of API requests allowed in a period of time. Hitting the limit can impact your deployments.

TFE_PARALLELISM variable

The easiest way to increase parallelism in Terraform Cloud for Remote Execution is the TFE_PARALLELISM variable. It just requires a number. To set this you need to perform those steps:

• Select your workspace,
• Go to Variables tab,
• Add variable in Workspace variables panel and create TFE_PARALLELISM variable:

  Ensure you have selected Environment variable button

The change should be available on next execution.

Manage parallelism for each stage of execution

Terraform CLI allows configuring parallelism differently per command (terraform plan, terraform apply or terraform destroy). In Terraform Cloud we can also do this. In these cases, use TF_CLI_ARGS_plan="-parallelism=<N>" or TF_CLI_ARGS_apply="-parallelism=<N>" environment variables instead of TFE_PARALLELISM.

I prefer this way because it allows being more granular. I want to run plan fast because it makes a request about every resource.

To set TF_CLI_ARGS_plan="-parallelism=<N>" or TF_CLI_ARGS_apply="-parallelism=<N>" parameters perform same steps as in instruction written above for TFE_PARALLELISM.

Manage the variables in a single place

I showed how to configure a variable per workspace. Terraform Cloud allows configuring a Variable set which can be attached to each workspace, so we don’t need to repeat ourselves for each workspace.

To configure Variable set do:

• Go to your organization Settings
• Select Variable set tab and click button Create variable set
• In Variables panel you need to define your variables

What is left is to attach the variable set to your workspace, or you can enable this set for all workspaces in the organization.

Variables set has lower precedence than workspace variables. Definition of the same variable in workspace will be used in execution. Here you can read more.

Terraform Cloud is an application that helps teams use Terraform together. I am using it for side projects like my cloud infrastructure. Last time I had to see trace logs to find an issue with one of the managed resources.

Terraform has detailed logs which can be enabled by setting the TF_LOG environment variable to any value. This will cause detailed logs to appear on execution.

Enabling verbose logging in CLI

You can set TF_LOG to one of the log levels TRACE, DEBUG, INFO, WARN or ERROR to change the verbosity of the logs. You can set this variable in two ways. First option is to set variable for shell session:

$ export TF_LOG=TRACE
$ terraform plan

Second option is to change variable before command execution

$ TF_LOG=TRACE terraform plan

Enabling logging in Terraform Cloud

If this run is in Terraform Cloud or Terraform Enterprise with Remote Execution, perform these steps:

• Select your workspace,
• Go to Variables tab,
• Add variable in Workspace variables panel and create TF_LOG variable:

  Ensure you have selected Environment variable button

• Perform the run that you want to trace

Another option is to enable local execution

If you are working on your own project, it will be much more convenient to disable Remote Execution and execute the run locally. Go to workspace Settings and in Execution Mode panel switch the button to Local. Then you can run plan from your local machine.

Once the issue is resolved, unset the TF_LOG environment variable to disable the enhanced logging.

Istio is a complex system. For the applications, the main component is the sidecar container Istio-Proxy, which proxies all traffic from all containers in Pod. And this can lead to some issues.

This post describes one of the most complicated problems I have encountered in my career.

The problem - Connection Reset 🐛

During Istio rollout on a huge system, with more than 40 different microservices, on a single endpoint, QA engineers found a bug. It was a POST endpoint, which was returning chunked data.

Istio was returning error 502, in logs an additional flag was visible: upstream_reset_before_response_started. The application logs confirmed that the result was correct.

In legacy Istio versions of the presented problem Istio were returning 503 error with UC flag.

Analyzing issue ⛏️

Let’s see the curl response and look at Istio-proxy logs:

kubectl exec -it curl-0 -- curl http://http-chunked:8080/wrong -v
< HTTP/1.1 502 Bad Gateway
< content-length: 87
< content-type: text/plain
< date: Sun, 24 Apr 2022 12:28:28 GMT
< server: istio-envoy
< x-envoy-decorator-operation: http-chunked.default.svc.cluster.local:8080/*
upstream connect error or disconnect/reset before headers. reset reason: protocol error

$ kubectl logs http-chunked-0 -c istio-proxy
[2022-04-24T12:23:37.047Z] "GET /wrong HTTP/1.1" 502 UPE upstream_reset_before_response_started{protocol_error} - "-" 0 87 1001 - "-" "curl/7.80.0" "3987a4cb-2e0e-4de6-af66-7e3447600c73" "http-chunked:8080" "10.244.0.17:8080" inbound|8080|| 127.0.0.6:39063 10.244.0.17:8080 10.244.0.14:35500 - default

Time for spying 🕵🏻‍♂️

To analyze the traffic we can use tcpdump and Wireshark. Istio-proxy runs as a sidecar, which routes whole incoming and outgoing traffic to pod through own proxy.

To sniff traffic there are 3 ways:

1. Running tcpdump in istio-proxy container,
2. Using kubectl plugin ksniff - a plugin to kubectl to dump packets from pod, github repo,
3. Adding additional container to pod, with root permission and tcpdump installed,

The first option will not work by default, because istio-proxy runs without root permission. The third is the backup if 1 and 2 would not work. Let’s try ksniff.

What is ksniff 🛠️

ksniff in three words is a plugin that:

• figures out what node is running pod with an app,
• deploys an own pod with an affinity to that node, bound to the host network,
• opens Wireshark on your laptop with a packet stream from the application.

Let’s execute it to sniff our application:

kubectl sniff http-chunked-0 -c istio-proxy -p -f '-i lo' -n default

Important parameters

• -p is a parameter to support sniffing even if the pod is non-privileged. See docs,
• -f '-i lo' passes filter to tcpdump, we want to sniff localhost interface inside the Pod.

If there is no issue, our system has Wireshark in PATH, ksniff should open a new window

Finding the root cause 🔎

Wireshark will continuously follow with new packet records. It makes it hard to figure out our particular call. We can use filters to help with searching. Knowing the request path, method, response code - we can use it to find our packet using filter:

http.request.uri == "/wrong"

It shows only a single packet, our request. Wireshark allows to show the whole TCP conversation:

• click right click on the packet,
• go to Conversation Filter,
• select TCP.

Wireshark will write a filter to show the whole communication between istio-proxy container and the application container!

Let’s see the above image. The first 3 records are the three-way handshake packets. Later is our GET request. The most interesting happens in the last two packets. Application container returns response HTTP 200 OK. istio-proxy then closes the connection with RST packet.

This is what we saw in the logs. The flag was upstream_reset_before_response_started{protocol_error}. But why? This still does not explain.

Swiss knife by Wireshark 🪛

It is hard to read the HTTP protocol from multiple packet bodies. But Wireshark also has a solution for that. We can see data from L7, the application one. In our case, it is the HTTP protocol.

Click with the right mouse on a single packet, go to the Follow tab, and select TCP Stream:

Now we can check what the request from istio-proxy looked like, and what was the response from the app. Do you have an idea from the above picture?

Look closer at the response, there is a double Transfer-Encoding header. One starts from uppercase, the second one does not.

Double transfer-encoding header - what does it mean❔

Searching over Istio issues I found this answer. The most important are the first 2 points:

1. two transfer-encoding: chunked is equivalent to transfer-encoding: chunked, chunked as per RFC,
2. transfer-encoding: chunked, chunked doesn’t have the same semantic as transfer-encoding: chunked

Why the response was taken as double-chunked? According to Transfer Codings in Section 4, transfer-coding names are case-insensitive.

Summary 📓

As you see, Istio stands as a guard 👮‍♂️ of the HTTP protocol. If the app is returning a double-chunked response, then Istio requires it, otherwise, it rejects processing the request. curl ignores this inconsistency.

This issue was one of the most difficult tasks, which I ever had :-)

Infrastructure to reproduce and example app 🏭

In Github repository I created example infrastructure to reproduce the problem.

Bootstrap of the infrastructure installs ArgoCD, Istio and the App. The sample app exposes two endpoints:

• /correct - endpoint, which creates a streamed response,
• /wrong - is doing same as above, but additionally it set value of the Transfer-Encoding header to Chunked(uppercase).

I would like to thank Przemysław for his help and for showing me how to use Wireshark efficiently during this issue.🤝🏻

First contract - Pet owners

I am learning blockchain and smart contracts. This post will be my note on how I am starting my journey into blockchain technology.

In this example I will create a contract for storing who is owning a Pet.

Development

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0; //build contract on top of Solidity >=0.8.0 and <0.9.0

contract PetOwner {
    mapping (string => Pet) public petOwners;

    struct Pet {
        string name;
        string petType;
    }

    function addPetOwner(string memory ownerName, string memory _name, string memory _petType) public {
        petOwners[ownerName] = Pet({name: _name, petType: _petType});
    }

}

Put it in the Remix IDE: https://remix.ethereum.org/. It should compile and we can deploy it on the local environment:

When we have contract deployed we can create example contract ownership

and ask petOwners field for information which Pet is owned by Marcin.

Let’s deploy it to Ethereum test network

Ethereum allows testing our contract on test networks. For this example I will use Rinkeby. This is a free network for testing smart contracts.

I am not covering how to install Metamask. Always remember to not share private key and seed You can always create a new Metamask identity for your tests.

1. Switch the Remix Environment from Javascript VM to Injected Web3
2. Connect your Metamask. Ensure you have chosen Rinkeby network
3. If you don’t have any ETH coins you can use this Faucet to grab some: https://faucets.chain.link/rinkeby
4. Click deploy. You will be asked by Metamask to confirm the transaction: Contract deployment transaction

Now I can test my contract. I fill the data

And we will be asked again for confirming the transaction .

When everything will be done, our transaction should be visible on Etherscan

And at the end we can check if petOwner field contains our definition:

This post contains my notes from a Blockchain development tutorial available here.