Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URLs are state containers

alfy.blog

Post reply on HN
Print view View original

11–20 of 218 posts

Re: URLs are state containers

#11

Post by qdotme »

Yes! This is a very under-utilized concept, especially with client-side execution (WASM etc!)

Few years back, I built a proof-of-concept of a PDF data extraction utility, with the following characteristic - the "recipe" for extracting data from forms (think HIPAA etc) can be developed independently of confidential PDFs, signed by the server, and embedded in the URL on the client-side.

The client can work entirely offline (save the HTML to disk, airgap if you want!) off the "recipe" contained in the URL itself, process the data in WASM, all client-side. It can be trivially audited that the server does not receive any confidential information, but the software is still "web-based", "browser-based" and plays nice with the online IDE - on dummy data.

Found a working demo link - nothing gets sent to the server.

https://pdfrobots.com/robot/beta/#qNkfQYfYQOTZXShZ5J0Rw5IBgB...

Re: URLs are state containers

#13

Post by cluckindan »

caseysoftware wrote: post #12

HATEOAS never gets the love it deserves until you call it something else.. Probably because it sounds like the most poorly named breakfast cereal ever.

This has nothing to do with HATEOAS. Well, apart from both using URLs. But HATEOAS really isn’t about storing state in URLs.

Re: URLs are state containers

#15

Post by qlm »

bob1029 wrote: post #6

To fully describe client side state you also need to look at DOM and cookies. The server can effectively see this stuff too (e.g., during form post). I design my SSR apps so that as much state as possible lives in the server. I find the session cookie to be far more critical than the URL. I could build most of my apps to be URL agnostic if I really wanted to. The current state of the client (as the server sees it) ca…

Maybe I'm misunderstanding what you're saying but applications like this tend to be horrible to use. How do you handle somebody navigating in two tabs at once? What about the back button?

Re: URLs are state containers

#16

Post by weikju »

padolsey wrote: post #8

I agree, and this reminds me: I really wish there was better URL (and DNS) literacy amongst the mainstream 'digitally literate'. It would help reduce risk of phishing attacks, allow people to observe and control state meaningful to their experience (e.g. knowing what the '?t=_' does in youtube), trimming of personal info like tracking params (e.g. utm_) before sharing, understanding https/padlock doesn't mean trusted…

> Generally, even the most internet-savvy age group, are vastly ill-equipped.

It’s a losing battle when even the tools (web browsers hiding URLs by default, heck even Firefox on iOS does it now!) and companies (making posters with nothing more than QR codes or search terms) are what they’re up against….

Re: URLs are state containers

#17

Post by __MatrixMan__ »

qlm wrote: post #15
bob1029 wrote: post #6

To fully describe client side state you also need to look at DOM and cookies. The server can effectively see this stuff too (e.g., during form post). I design my SSR apps so that as much state as possible lives in the server. I find the session cookie to be far more critical than the URL. I could build most of my apps to be URL agnostic if I really wanted to. The current state of the client (as the server sees it) ca…

Maybe I'm misunderstanding what you're saying but applications like this tend to be horrible to use. How do you handle somebody navigating in two tabs at once? What about the back button?

Agreed. Also, when you paste somebody a URL, they should see what you saw... if at all possible.

Re: URLs are state containers

#18

Post by oceanplexian »

vbezhenar wrote: post #4

When the system evolves, you need to change things. State structure also evolves and you will refactor and rework it. You'll rename things, move fields around. URL is considered a permanent string. You can break it, but that's a bad thing. So keeping state in the URL will constrain you from evolving your system. That's bad thing. I think, that it's more appropriate to treat URL like a protocol. You can encode some st…

I think it depends on the permanence of the thing you’re keeping state for. For example for a blog post, you might want to keep it around for a long time.

But sometimes it’s less obvious how to keep state encoded in a URL or otherwise (i.e for the convenience of your users do you want refreshing a feed to return the user to a marker point in the feed that they were viewing? Or do you want to return to the latest point in the feed since users expect a refresh action to give them a fresh feed?).

Re: URLs are state containers

#19

Post by cluckindan »

btown wrote: post #14
caseysoftware wrote: post #12

HATEOAS never gets the love it deserves until you call it something else.. Probably because it sounds like the most poorly named breakfast cereal ever.

I mean, at the end of the day it is a cerealization format…

Jokes aside, the crux of HATEOAS is having a dumb frontend which just displays content and links from backend responses. All logic is on the server side. It is more like a terminal connection than a browser based application.

Re: URLs are state containers

#20

Post by sixhobbits »

More good content with a bunch of GPT noise added, obvious from patterns like

No database. No cookies. No localStorage

Themes chosen. Languages selected. Plugins enabled.

Which have the pattern of rhetoric but no substance. Clearly the author put significant effort it so why get an LLM to add noise?

Post reply on HN