Making of the demo project

This is a follow-up article to A full-stack developer's shift to serverless paradigm, which explores the spontaneous allocation of project resources. To fully grasp the context, familiarity with JavaScript, its ecosystem, npm, and web development concepts is recommended. However, feel free to proceed at your own pace.

Demo Project Inspiration

Problem: Occasionally, I encounter situations where sharing textual information between my devices becomes cumbersome due to network restrictions or other complex scenarios. The traditional methods of rewriting the information, using USB memory sticks, or emailing myself entail either significant time investment or navigating through authentication processes.

Solutions: Some solutions, such as paste-and-share services, offer convenience by allowing information to be accessed from any device via a shared link. However, these services often come with drawbacks such as intrusive ads, tracking mechanisms, and privacy concerns.

Motivations: The inefficiencies of time wasted, the inconvenience of incompatible or missing USB ports, and concerns about privacy and intrusive tracking spurred the creation of this demo project.

The aim of this project is to provide a solution akin to traditional paste-and-share services but with a significant difference: no ads, no trackers, and complete privacy. The shared information remains secure through a combination of a public and private key, ensuring confidentiality. To demonstrate simplicity, the shared data is encoded using standard JavaScript library functions btoa and atob.

The project offers two core features: read and write. The information is stored in a database service provided by CloudFlare, known as KV (KeyValue), a data storage technique. You can learn more about KV here.

Technical implementation

Before we dive into the technical details, ensure you have CloudFlare's CLI tool, Wrangler, installed. You can either install it globally with npm install --global wrangler or project-based. We'll primarily use two Wrangler commands: wrangler login and wrangler deploy, both of which interact directly with the CloudFlare platform. Note: If you're using Git in your project, be cautious not to leak Wrangler's artifacts that may be generated within your project.

The initial step is to create the project. Since I found using Vite convenient for this demo, the command to create a Vite project is npm create vite@latest. This command prompts the installation of create-vite@, which then leads to another wizard for completing project creation based on our preferences. In my case, it instructed me to proceed with:

Need to install the following packages:
[email protected]
Ok to proceed? (y) y
✔ Project name: … secret-share
✔ Select a framework: › Vue
✔ Select a variant: › TypeScript

Scaffolding project in /path/to/secret-share...

Done. Now run:

  cd secret-share
  npm install
  npm run dev

As a full-stack developer, we often focus on iterating solutions rather than delving into tool details, especially when unnecessary. In this article, we won't delve into Vite's compilation steps, hot reloading, plugin systems, or Vue's features, pros, and cons. Our aim is to get things done efficiently.

Secret-share's frontend comprises three routes: / (root path), treated as read where you must provide a public and private key; /share, the form where you compose the information to share with the keys; and finally, /:publickey, where providing the public key over the link requires only the private one on the form. Modified files from the boilerplate include src/main.ts and src/App.vue. Additionally, we created src/routes.ts and src/pages/Read.vue, src/pages/ReadPublickey.vue, and src/pages/Share.vue.

On the backend, two routes are defined in two files within the functions directory. This follows an implicit convention specified by the CloudFlare platform, where any HTTP request to functions/filename.js translates to /filename as the endpoint. Depending on how you handle the request, you can expect it in any HTTP method (GET, POST, DELETE, etc.).

After making project changes, simply execute wrangler deploy, following a short wizard at initialization to tie the project to an existing CloudFlare page or create a new one. This process is a one-time setup. Subsequently, each use of wrangler deploy will redeploy changes. A final step for our secret-share demo is binding the KV namespace to the CloudFlare page project you deploy to. Since our functions/resources utilize the KV feature from the cloud platform, failing to bind will result in undefined property kv on HTTP requests to the backend.

Wrapping up

This article offers a condensed overview of what can be achieved with some effort, serving as a weekend challenge to explore something new. However, it's essential to note that production-grade solutions would diverge significantly from the scope of this article.

In conclusion, I hope this provides a glimpse into the essence of what serverless truly entails.