Golang example ?

[gedw99]

@18alantom

The new docs are really good.

I am keen to try to do an example that integrates a golang backend with Strawberry.

Could you possible outline how the API should work between the 2 layers ?

I am keen to see how the state between the 2 layers are synergistic. My plan is for all mutations to go to backend , and somehow update the json on the frontend when it changes. SSE or web sockets…

I was thinking of a nice simple example like a kanban that has projects and items and tags . A tag is the kanban lane.

If you want a different example just let me know also.

[gedw99]

The concept I am working with is to use htmx to update the frontend with html or Json Data.

typically html is pushed, and api wanted to try pushing new templates at runtime

[18alantom]

Thanks!

I'll attempt sketching a super simple kanban. Starting with the shape of the
reactive object:

type Item = {
  title: string;
  details: string;
};

type Lane = {
  title: string;
  items: Item[];
};

type Project = {
  title: string;
  lanes: Lane[];
};


declare const sb: { data: Project };

Note, I've normalized the shape. It can be denormalized to have everything
stored on a single Item object which would map to a single table, but that
wouldn't match the a kanban UI.

Initialization

Considering that only one project would be open at a time, the main reactive
object can be the Project. Loading an app sets up an empty project:

sb.data = {
  title: '' /* placeholder title */,
  lanes: []
}

A project is fetched from the server on connecting. It can be directly set onto
sb.data.

sb.data = {
  title: 'The Board',
  lanes: [
    {
      title: 'To Do',
      items: [
        { title: '...', details: '...' },
      ],
    },
    { 
      title: 'Done',
      items: [] 
    },
  ],
};

Propagating updates

There'll be a couple of functions to update the data, a few examples:

function addItem(item: Item, laneTitle: string);
function shiftItem(itemTitle: string, toLane: string);
function deleteItem(itemTitle: string);

These function will do just one thing and that is update the reactive object,
for example:

function addItem(item: Item, laneTitle: string) {
  const lane = data.lanes.find(({ title }) => title === laneTitle)
  lane?.items.push(item)
}

This way, they can be used for both:

1. UI event listener handlers.
2. WebSocket message event listeners.

For example:

addItemButton.addEventListener('click', () => {
  const item = getNewItem()        // Read from input elements
  const laneTitle = getLaneTitle() // Read from input element/parent


  // UI to reactive object
  addItem(item, lane)

  // UI to socket
  socket.send(
    JSON.stringify({
      message: 'add-item',
      data: {item, laneTitle}
    })
  )
})



socket.addEventListener('message',  (event)  => {
  const data = JSON.parse(event.data)

  // socket to reactive object (by extention UI)
  if (data.message = 'add-item') {
    const {item, laneTitle} = data.data
    addItem(item, laneTitle)
  }
})

In the above example, changes applied to the reactive object propagate to the
UI. But not to the socket. This is done in the UI event listeners

Complications

A couple of complications, if required.

Propagate from reactive object to socket

The reactive object can be made the center of updates such that any changes to
it are propagated to the socket too, using sb.watch (yet to be documented).

sb.watch('lanes.0.items', () => { /* do something */})

The issue here is that since sb.watch captures updates at the parent object
level, if any child element—irrespective of nesting—is updated, it's hard to
pinpoint the nature of the update.

For instance a shiftItem operation consists of several atomic operations, for
example:

1. remove item from source lane   O(1)
2. adjust source lane             O(n_source)
3. set item in dest lane          O(1)
4. adjust dest lane               O(n_dest)

It'd be highly imprudent to transmit all of those changes, depending on the
kanban structure in the database, it could be as simple as just updating a
single cell.

And so it's better to handle UI to socket propagation in the in the UI event
listener.

Optimistic updates

The example above uses optimistic updates. UI is updated (by updating the
reactive object) after which the the socket message is sent.

If the update fails on the server side, then a message will be regarding this
failure will be sent.

Failure can be handled in multiple ways, for instance sending the old state
which can be assigned to the reactive object (which'll update the UI). Along
with a toast indicating the nature of the error.

Denormalizing items, lanes, projects to a single object

If the data is to be denormalized to single objects to say, have a simpler table
structure, the UI side can be dependent on computed values. This would
simplify updates.

---

I'm not sure how this factors in with the usage of HTMX, as per my understanding
when using HTMX, data operations such as addItem, shiftItem, etc would be
handled server side and the updated HTML is returned to update the UI.

W.r.t pushing templates, you can register them using sb.register (yet to be
documented), example:

sb.register(`
 <template name="blue-p">
   <p style="color: blue;">
     <slot />
   </p>
  </template>
`);

but you can't re-register them, limitation of the WebComponent spec.