Problems with configuration

[geoidesic]

Hi Ward,

I had a go at setting this up but I seem to be missing something.

I have a current version of qewd running via docker. I'm launching it via docker-compose.yml:

version: '3'
services:
  qewdup:
    image: rtweed/qewd-server-arm64
    container_name: qewdup
    ports:
      - "3000:8080"
    volumes:
      - ~/code/testQewd:/opt/qewd/mapped

That works fine and I can run the standard HelloWorld app examples from Rob, both as REST API or qewd-apps.

I tried creating a Vue 3 app based on this repo but I haven't been able to get it to work.

I'm using Caddy web server which includes some reverse-proxying:

fe.dev.localhost {
    reverse_proxy http://host.docker.internal:5173
}
be.dev.localhost {
    route /api/* {
        reverse_proxy http://host.docker.internal:3000
    }

    route /app/* {
        reverse_proxy http://host.docker.internal:3000
    }

    route /qewd/* {
        uri strip_prefix /qewd
        reverse_proxy http://host.docker.internal:3000
        header Access-Control-Allow-Origin *
    }
}

Here's the qewd config.json:

{
    "qewd_up": true,
    "jwt": {
        "secret": "bc417a22-6baf-4ac0-97ea-d096fdfdd5c5"
    },
    "cors": true,
    "qewd": {
        "webSockets": {
            "io_paths": [
                "/qewd"
            ]
        }
    }
}

I run the Vue app using yarn dev --host and then I can load the initial page on fe.dev.localhost, most of which loads ok but the ewd-registered event never fires.

This is the App.vue:

<script setup>
import { RouterLink, RouterView } from 'vue-router'
import HelloWorld from './components/HelloWorld.vue'
import { ref, onMounted, getCurrentInstance } from 'vue'
import io from 'socket.io-client'

const qewdReady = ref(false);
const { proxy } = getCurrentInstance();

onMounted(() => {
  // Event handler when QEWD's connection is registered/ready
  proxy.$qewd.on('ewd-registered', function() {
    console.log('ewd-registered');
    // Your QEWD environment is ready, set the qewdReady data property to true
    qewdReady.value = true;
    // Optionally turn on logging to the console
    proxy.$qewd.log = true;
  });
  // Start QEWD-Up/QEWD.js client
  proxy.$qewd.start({
    application: 'helloworld',
    // use a url to allow correct startup of WebSocket using a namespace /qewd
    // you *need* to pass a url here too to make the Websocket transport=websocket mode work 
    // (it will fall back to polling mode if the url is not passed in)
    url: 'https://be.dev.localhost/qewd',
    // pass the io_path to the WebSocket
    io_path: '/qewd',
    io,
    // optional: control the transport mode(s) the websocket will use
    io_transports: [ 'websocket' ]
  });

});

</script>

I notice that the Session Cookie is not always being stored. I don't know why that might be. I have seen it appear, but if I delete it, it doesn't always re-appear. I think this might be newish (2023) a cross-domain security update whereby if the ports or domains are different between the source and destination then the browser will refuse to store the cookie.

It's confusing that the cookie not being stored doesn't seem to affect qewd-apps – they happily work without the cookie. However for the VueJs app, the ewd-registration is never received.

If I enable logging outside of the ewd-registered hook then I can see:

send message [HelloWorld.vue:21:15](https://be.dev.localhost/vue/src/components/HelloWorld.vue)
*** server has disconnected socket, possibly because it shut down or because token has expired [qewd-client.js:432:18](https://be.dev.localhost/vue/node_modules/qewd-client/qewd-client.js)

So the server disconnects when the message is sent. Probably because the cookie is not being preserved.

[wdbacker]

Hi Noel,

I'd need to have a look at this: I didn't use WebSockets recently with Vue.js - for my current web apps I'm using Nuxt with QEWD-Up's REST api's. I don't think the cookie is the issue to make it work at first as the cookie just remembers your current QEWD session token. It's more a socket.io (possibly CORS) issue I think.

What I usually do to test these kind of issues: I start QEWD-Up in one debug session in Visual Studio Code using the built-in debugging functionality to trace where the registration message comes in (search for ewd-register in node_modules\qewd\lib\appHandler.js). Secondly, I start the Vue.js app also in Visual Studio Code in a another debug session and put some breakpoints inside the qewd-client code to see what the WebSocket is doing.

I'll try to have a look on my dev setup too, but for now you have already some starting point to debug.

[geoidesic]

Hi Ward,

Thanks for the reply!

The trouble I had with debugging is that I was using the dockerised version of QEWD, and I wasn’t able to figure out how to set breakpoints inside a docker container. Apparently it is possible in VSCode with the right plugins but I haven’t got there yet.

Nuxt is an interesting idea. I was considering trying Next.js and also interested in seeing if Svelte can be used with QEWD too – that was actually my goal, Start with the Vue integration you did and then see if I could convert it to Svelte but I couldn’t get the web sockets to work.

Why would you not want to use the web sockets? I kind of thought that was the whole point of QEWD because it enables reactivity directly from monitoring the database. Using QEWD without that seems to me a rather niche choice because you get none of the benefits of QEWD, plus all of the difficulties (like poor support) – I imagine you’d be better off using a vanilla express framework with Postgres and an ORM like Prisma or Sequelize. What am I missing? I guess you are working in an environment where GT.m is a given, in which case QEWD makes sense even without websockets. Still I’d be interested in your motivation for not using them and losing out on the reactivity?

This was the response from Rob Tweed btw:

Hi Noel

Unfortunately no as I’m not a Vue developer.

However it seems to me that the problem relates to the use of the intermediate web server that Vue seems to think is a good idea: I’ve never understood this approach. It means you end up needing hacky stuff like CORS and proxying traffic.

I’d suggest running it all on a web server that has direct access to the database either via a networked or API connection.

Other than that I think Ward is your best bet.

Sorry I can’t be much more help

Regards Rob

Kind Regards, Noel.

On 6 Jul 2024, at 10:17, Ward De Backer @.***> wrote:

Hi Noel,

I'd need to have a look at this: I didn't use WebSockets recently with Vue.js - for my current web apps I'm using Nuxt with QEWD-Up's REST api's. I don't think the cookie is the issue to make it work at first as the cookie just remembers your current QEWD session token. It's more a socket.io (possibly CORS) issue I think.

What I usually do to test these kind of issues: I start QEWD-Up in one debug session in Visual Studio Code using the built-in debugging functionality to trace where the registration message comes in (search for ewd-register in node_modules\qewd\lib\appHandler.js). Secondly, I start the Vue.js app also in Visual Studio Code in a another debug session and put some breakpoints inside the qewd-client code to see what the WebSocket is doing.

I'll try to have a look on my dev setup too, but for now you have already some starting point to debug.

— Reply to this email directly, view it on GitHub https://github.com/wdbacker/vue3-qewd-hello-world/issues/1#issuecomment-2211716910, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDMKKZND2AZHYKG5NOQC6DZK6Y3HAVCNFSM6AAAAABKOISH62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJRG4YTMOJRGA. You are receiving this because you authored the thread.