DevLog 20250804: Simple File Uploading Service (A Request Unfulfilled)

Revision: 001

(This post identifies a problem and is not generating a solution for it yet.)

The Problem

Wouldn’t it be nice if we had a simple way to share our scripts so others could use them immediately?

Pure attempted this with CentralSnippets, which makes it straightforward on the client side (just call something like Pull("Markdown/BuildToC", disableSSL: false)) while relying on GitHub’s PR-based upload process.

For Divooka, we want to achieve something similar - perhaps even simpler. But file sharing inevitably raises three unavoidable concerns:

1. User authentication
2. Content management
3. API or user interface design

User Authentication

When we’re logged in, we often take it for granted - but most platforms require an account to access core functions. For a file-uploading service, the question becomes: which account system should we use?

OAuth can help, but it doesn’t remove the fact that users still need to create an account with the service. That, in turn, means there needs to be an account server.

One possible simplification: GCP’s Firebase Authentication.

Content Management

Once uploaded, files could live on a dedicated file server, or be distributed via a CDN to reduce server load.

Using a CDN is often the simplest long-term approach. However, you still need an intermediate server to communicate with the CDN - you can’t just expose it directly.

Some platforms, like AWS and GCP, offer Signed URLs, which allow controlled access without routing through a central server first.

API or Access Interface

Users might upload files via:

• Web forms
• HTTP APIs
• CLI tools
• Dedicated protocols
• Client-side libraries

The challenge is deciding which of these methods to support and how to balance simplicity with flexibility.

Accessing

Accessing the files is the easy part: generate a URL, and the file can most likely be downloaded directly over HTTP.

The Ideal Picture

So, what would a general-purpose, ideal file-uploading service look like?

Key aspects might include:

1. Quick deployment and re-deployment of multiple dedicated file servers
2. Configurable backends for storage and delivery
3. Fine-grained access control for uploaded resources

All of which sounds like we’re edging into BaaS (Backend-as-a-Service) territory.

Anecdote (Update: 20250804)

I was writing this post bearing in mind I have to suffer the new UI update of Dev.to - life felt truly like a compromise.

However, the dev team addressed the issue within an hour! I didn't even expect them to notice my post. Salute🫡 To Dev.To Dev Team!

We should definitely learn from Forem developers!