When building a modern web application, the default architecture often looks something like this:
Frontend → API → Database → API → Frontend
For many applications, that architecture is exactly what you need.
But what if the application doesn't actually need persistent server-side data?
What if the entire state of a small web application could be compressed, encoded, placed inside a URL, and reconstructed directly in the browser?
That was the idea behind Storkim Page, a browser-based digital business card and link-in-bio tool.
The product looks simple from the outside: a user creates a page containing their name, photo, bio, social profiles, contact information, and other links, then shares the resulting URL.
Underneath that simple interface is a useful architectural pattern:
The URL becomes the portable representation of the application state.
This article explores that approach, why it works, its advantages, its limitations, and when developers might consider using something similar.
The Traditional Approach
Let's imagine we're building a digital business card.
A traditional implementation might work like this:
User
↓
Create account
↓
Submit profile
↓
API
↓
Database
↓
Generate profile ID
↓
Share profile URL
The public page might look like:
https://example.com/profile/abc123
When someone opens the link:
Browser
↓
GET /profile/abc123
↓
API
↓
Database
↓
Profile data
↓
Render page
This architecture has several advantages.
The user can update their profile without changing the URL.
The application can provide authentication.
Analytics can be associated with a user account.
Multiple devices can access the same profile.
Server-side validation and moderation are possible.
But it also introduces infrastructure.
You need a database.
You need an API.
You need authentication if users have accounts.
You need database migrations and backups.
You need to handle profile identifiers.
You need to think about caching and availability.
For a complex application, those are reasonable requirements.
For a simple, mostly static page, they can be unnecessary.
What If the Data Was Inside the URL?
This is where URL-based state becomes interesting.
Instead of storing the profile configuration on a server, we can represent the configuration as data.
For example, conceptually:
{
"name": "Jane Doe",
"bio": "Designer & Photographer",
"links": [
{
"title": "Instagram",
"url": "https://instagram.com/example"
},
{
"title": "Portfolio",
"url": "https://example.com"
}
]
}
That object can be serialized, compressed, and encoded.
The resulting information can then be placed inside the URL fragment:
https://example.com/page#encoded-data
Now the browser has everything it needs to reconstruct the page.
The request does not necessarily need to ask a database:
"Which profile belongs to this ID?"
Instead, the browser can read the fragment and decode the state locally.
The architecture becomes:
User Input
↓
Serialize
↓
Compress
↓
Encode
↓
URL Fragment
↓
Share
↓
Browser
↓
Decode
↓
Render
This is the fundamental idea behind Storkim Page.
Why Use the URL Fragment?
The URL fragment is the portion after #.
For example:
https://example.com/page#profile-data
The fragment has an important browser behavior: it is processed client-side and is not normally included in the HTTP request sent to the server.
That makes it useful for applications where the browser needs to carry state without putting that state into the server request.
For a client-side application, the page can effectively do:
const hash = window.location.hash;
Then the application can process the data contained in that fragment.
Conceptually:
const encodedState = window.location.hash.substring(1);
const state = decode(encodedState);
renderProfile(state);
The exact implementation can vary depending on the encoding and compression strategy.
The important architectural concept is that the browser becomes responsible for reconstructing the state.
Compression Becomes Important
There is an obvious problem.
URLs aren't infinitely large.
A digital business card can contain:
- Name
- Bio
- Profile image
- Multiple links
- Social profiles
- Contact information
- Styling preferences
- Background settings
- Button settings
If all of that is converted directly into JSON and encoded into a URL, the result could become unnecessarily large.
Compression helps.
The general pipeline becomes:
Object
↓
JSON serialization
↓
Compression
↓
Binary/string representation
↓
URL-safe encoding
↓
URL fragment
When the page loads:
URL fragment
↓
Decode
↓
Decompress
↓
Parse JSON
↓
Application state
↓
UI
Storkim Page also compresses uploaded images before incorporating them into the generated page data, helping make the URL-based approach more practical. Storkim Page
This is a useful example of a broader engineering principle:
If you want to move data from storage into a URL, data size becomes part of your application architecture.
Client-Side State Instead of Server-Side State
One of the biggest differences between this architecture and a traditional SaaS application is where the state lives.
Traditional application:
Database
↓
Server
↓
API
↓
Browser
URL-based application:
URL
↓
Browser
↓
Application State
The second approach can dramatically simplify a small application.
There is no need to maintain a database record simply to render a profile.
There is no profile lookup.
There is no profile ID that needs to be mapped to a database row.
The URL itself contains the information required by the client.
No Account Required
This architecture also changes the onboarding experience.
A traditional application might require:
Create account
↓
Verify email
↓
Log in
↓
Create profile
↓
Save profile
↓
Get public URL
A client-side generator can instead provide:
Open tool
↓
Create page
↓
Generate link
↓
Share
For a tool whose primary purpose is generating a simple shareable page, removing account creation can make the workflow significantly faster.
Storkim Page follows this model. Users can create and customize their page without having to create a traditional account before generating a shareable page. Storkim Page
The Trade-Off: Portability vs. Central Control
URL-based state isn't a replacement for databases.
It is a different trade-off.
Consider a conventional profile:
https://example.com/jane
Jane changes her phone number.
The database changes.
The URL stays the same.
With a self-contained URL:
https://example.com/page#encoded-profile
the URL represents the current state.
If the profile changes, the generated representation can change as well.
This creates a different workflow.
Instead of:
Same URL
↓
Updated server-side data
you can have:
Updated data
↓
Generate new representation
↓
New URL
Storkim Page addresses this by allowing users to save their current draft locally and generate an updated link when they make changes. Storkim Page
This is an important limitation to understand before adopting this architecture.
When This Architecture Makes Sense
URL-based state is particularly interesting for applications where the data is:
- relatively small
- mostly static
- safe to expose to anyone with the link
- independently shareable
- generated by the user
- useful without authentication
- primarily consumed by a browser
Examples include:
Configuration Generators
A tool could generate a configuration URL:
https://example.com/config#encoded-settings
Someone else opens the link and receives exactly the same configuration.
Calculators
A financial or engineering calculator could encode its inputs:
https://example.com/calculator#encoded-inputs
Sharing the URL reproduces the calculation.
Color Tools
A color palette generator could encode:
#FF0000
#00FF00
#0000FF
along with other settings.
The URL becomes the saved state.
Form Builders
A small form configuration could be encoded and shared without requiring a database record for every draft.
Interactive Documents
A generated document or visualization could carry its configuration in the URL.
Digital Business Cards
And, of course:
Name
Bio
Photo
Links
Social profiles
Contact information
Styling
can form a compact, portable application state.
When You Should NOT Use It
There are many applications where this approach would be a bad idea.
Don't put sensitive information into a URL.
URLs can be copied, shared, stored in browser history, and potentially exposed through various logging or analytics mechanisms depending on how the application is implemented.
A URL-based architecture is therefore not a substitute for proper security.
It is also a poor fit for data that needs:
- centralized modification
- access control
- authentication
- frequent updates
- server-side validation
- collaboration
- large amounts of data
- moderation
- centralized analytics
- revocation
For those requirements, server-side storage is usually much more appropriate.
Another Interesting Property: Portability
There is something elegant about treating the URL as a portable state container.
Imagine sending someone:
https://example.com/page#encoded-state
They don't need to know your database ID.
They don't need your username.
They don't need an account.
They don't need access to your dashboard.
The URL represents the page.
This is similar to how certain developer tools allow you to share an entire configuration simply by sharing a URL.
The link becomes more than an address.
It becomes a serialized representation of the application state.
What Developers Can Learn From This
The most valuable lesson isn't necessarily "put your data in a URL."
The lesson is:
Question your infrastructure requirements before adding infrastructure.
When starting a new project, developers often reach for familiar components:
Next.js
+
API
+
PostgreSQL
+
Authentication
+
Redis
+
Object Storage
Those technologies are excellent.
But they also introduce operational complexity.
Sometimes the actual requirements are much smaller.
If the application can safely operate on client-side state, you may be able to eliminate entire pieces of infrastructure.
That can mean:
- fewer backend endpoints
- fewer database queries
- less server-side state
- simpler deployment
- simpler scaling
- fewer infrastructure dependencies
The trade-off is that complexity doesn't disappear.
It moves.
Instead of database design, you now have to think about:
- serialization
- compression
- URL size
- encoding
- browser compatibility
- state validation
- versioning
- client-side security
- migration of old encoded states
Good architecture isn't about eliminating complexity.
It's about putting complexity where it makes sense.
A Simple Mental Model
When evaluating whether URL-based state could work for a project, ask five questions.
1. Is the data small enough?
If the answer is no, use storage.
2. Is the data safe to expose in a shareable URL?
If the answer is no, don't put it there.
3. Does the data need centralized updates?
If yes, a database may be more appropriate.
4. Does sharing the state through a link provide value?
If yes, URL-based state becomes interesting.
5. Can the browser reconstruct everything it needs?
If yes, you may not need a backend for that particular part of the application.
The Bigger Idea
A digital business card is a simple product.
But simple products can reveal interesting engineering patterns.
Storkim Page demonstrates one such pattern: using a URL as a portable representation of client-side application state.
Instead of:
URL
↓
Database ID
↓
Database
↓
API
↓
Profile
you can sometimes build:
URL
↓
Encoded State
↓
Browser
↓
Profile
That doesn't eliminate the need for servers across the web.
It simply shows that not every piece of application state needs to live in a database.
For the right problem, the browser can do more of the work.
And sometimes, the simplest architecture is the one that asks:
"Do we actually need to store this on a server?"
Try the Approach
If you want to see the concept in practice, Storkim Page lets you create a digital business card/link-in-bio page directly in the browser.
You can add your information and links, customize the appearance, preview the result, and generate a shareable page.
Storkim Page:
The tool is a practical example of a broader web-development idea:
Sometimes your application state doesn't need a database. Sometimes it can travel with the user.
Top comments (0)