On Thu, Oct 24, 2019 at 06:35:50PM +0200, Zelphir Kaltstahl wrote:
> Hi Tomas!
> 
> Do you still remember some of the issues you came across when making
> such a shop?

As I said, it was a pretty simplistic thing:

 - low volume (both customers and inventory)
 - no interest whatsoever in SEO and other things

but it worked pretty well. As basic design principles...

 - I postponed creating session to the last possible
   moment: so the user was browsing the inventory
   basically as a static page, no state encoded;

 - once I had to carry status related to the session
   (i.e. the user dropped the first item into the
   tray), a random session token was generated and
   inserted into the URL. A HTTP redirect then let
   the browser "know" our new common basis.

   I remember chosing an "early" spot at the URL to
   leverage the browser's relative addressing, which
   saves a lot of template substitution in the pages.

   Tokens were expired to avoid abandoned sessions
   piling up

User's feedback was fairly positive: the page felt quick (back
then, the scripts weren't the huge monsters of today, but the
browser's javascript engines weren't as streamlined as today's
either, and the usual bandwidth was a fraction of what is common
these days).

> If I am not mistaken, Racket's continuation based webserver does
> something like this. It also stores state in the URL, which then looks a
> bit strange. I think that state even encodes the continuation.

This is a thing I considered: not to have a per-session
token, but a per-transaction token -- the continuation
idea is pretty cool, because the user can have several
different "histories" of their session running in parallel.

OTOH I tried to imagine the poor webshop user confronted
with that. It sure would confuse the hell out of me ;-)

I think it would take some thinking to tame the less intuitive
parts.

Cheers
-- t