Keycloak-js client with Quasar

So you’d like to use openid-connect (oidc), especially keycloak (kc) in your Quasar app.

There’s a package, @dsb-norge/vue-keycloak-js . I’d recommend you fork it and create your own version with the keycloak-js version that matches your Keycloak server. However it also works with just the version used in this git repository.

The git repository is available at

Alright let’s get started.

1. Create a file named silent-check-sso.html with the following content:

Put that file in the public directory as its path is

2. Create boot/keycloak.js

3. Reference the created boot file in quasar.conf.js

And that’s really all there is to it.

After this is done you can access the keycloak object via $keycloak in your template.

vue dev server with nginx

The Nginx conf is the same for any sock-js site. It can be used for Vue and Angular and Svelte, not sure about React but I’d guess it uses sock-js as well.

My dev domain is qxdsladmin.local in this example.


This location ~ ^/api/v1/.* is a mountpoint for the backend http api, which in my case is a RESTful Go API.

The vue part, create a file named vue.config.js in the project’s root dir.
So if you used vue create vxdsladmin it’s the directory you go to when doing cd vxdsladmin.

This works for me, but maybe it can be improved. Let me know if that’s the case.

Modern efficient backend design

When writing backends with Go, I follow a simple pattern.
At the core there is the, well, core object, the service.
It has its own configuration struct. In this struct are all the configurations for the related services.
It is the central gateway for everything.

Connected to it on the back side are all the related services like oidc middleware, keycloak api service, the various entity repositories, validation, markup processor and so on.

Connected on the front are the various outlets, RESTful API handlers, gRPC service, SSR handlers, websocket handlers. Everything has its place and concern.

Cobra is used as the flag parser and command structure. There you have commands that reflect the outlets, restful, grpc etc.
Each of those has its own way to configure the core service. If you for instance use gin to serve RESTful data here’s where all the gin related stuff is configured and also where the database client is initialized and passed to the core service.

In the past I followed a trend that defined all the backend repositories as interfaces. This did not turn out to be the correct approach, as mental overhead is there and you can’t have proper, simple repository definitions. If you need those parts done differently, you can do that later. The main concern is getting to your goal, which is a finished, working backend. Bother with abstractions later if you have to.

Do that’s all there is to it. It’s not rocket science. This way you can have separately maintained services that you can just plug into your core service for each new backend you start writing and hopefully also finishing.

Ausgangssperren sind nachteilig im Effekt

Man stelle sich 1000 Menschen vor, die auf einem 24 Meter breiten Streifen entlang bewegen. Diese Menschen halten Abstand usw.
Was passiert wenn man den Streifen um 9 Meter verengt?
Ist dann die Dichte der Menschen auf diesem Streifen höher oder geringer?

Die Antwort ist natĂŒrlich wenn sich die selbe Menge Menschen auf kleineren Raum aufhĂ€lt das der Abstand zu anderen Menschen kleiner wird.

Wenn ich jetzt also normalerweise um 23 Uhr spazieren gehe um den ganzen anderen Menschen auszuweichen, es jetzt aber eine Ausgangssperre ab 20 Uhr gibt, begebe ich mich in stark erhöhtes Risiko.
Ist das verstÀndlich?