{"id":273,"date":"2022-08-19T09:59:00","date_gmt":"2022-08-19T07:59:00","guid":{"rendered":"https:\/\/www.zellot.at\/blogs\/?p=273"},"modified":"2022-08-19T16:54:08","modified_gmt":"2022-08-19T14:54:08","slug":"microfrontends-with-vue","status":"publish","type":"post","link":"https:\/\/www.zellot.at\/blogs\/2022\/08\/19\/microfrontends-with-vue\/","title":{"rendered":"MicroFrontends with Vue"},"content":{"rendered":"\n

Microservices are a well known concept nowadays. Handling encapsulated logic in different applications, can be a nice fit for bigger teams to avoid problems in deployments and development speed. Most of the time though, people are talking about the backend, where the UI part to some extend stays as a black box. One of the solutions to also further break down the UI is the concept of microfrontends which we will further explore here.<\/p>\n\n\n\n

There are obviously also other ways to solve issues (I can highly recommend reading Sam Newmans awesome book on this https:\/\/samnewman.io\/books\/building_microservices_2nd_edition\/<\/a> ), but one way to decompose your UI might be as following.<\/p>\n\n\n\n

Each service not only contains the backend logic which then gets called the from one service to render the UI, but rather each service comes with its own UI which then gets loaded into an application which keeps an overview of all the systems to load. This allows us to deploy the full service UI and backend on its own without the need to deploy one big system for each change. This avoids keeping two systems too much in sync in terms of deployments. <\/p>\n\n\n\n

\"\"<\/a>
Basic structure<\/figcaption><\/figure>\n\n\n\n

In order to do this I used a vue js setup, where we have one container app, which further loads asynchronously applications into the main container (this is heavily inspired by https:\/\/blog.bitsrc.io\/how-to-develop-microfrontends-using-react-step-by-step-guide-47ebb479cacd<\/a><\/p>\n\n\n\n

\"\"<\/a>
flow of data<\/figcaption><\/figure>\n\n\n\n

To achieve this one component was written:<\/p>\n\n\n\n

<template>\n  <div :id=\"this.containerName()\" \/>\n<\/template>\n\n<script>\n\/\/utility function to generate a uuid (I didn't wanted to import the uuid\n\/\/lib just for a random string\nfunction uuidv4() {\n  return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(\/[018]\/g, c =>\n      (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c \/ 4).toString(16)\n  );\n}\nexport default {\n  name: \"MicroFrontend\",\n  props: {\n    \/\/ name of the microfrontend like `wisdom` or `dicreoll`\n    name: {\n      type: String,\n      required: true\n    },\n    \/\/ host where the script should be loaded from\n    host: {\n      type: String,\n      required: true\n    },\n    \/\/ define a static container name rather than a generic one\n    \/\/ not needed if you are ok with random divs all the time\n    staticContainerName: {\n      type: String,\n      required: false,\n      default: null\n    }\n  },\n  data: function () {\n    return {\n      uuid: uuidv4()\n    }\n  },\n  methods: {\n    \/\/ calculates the container id we load the microfrontend app into\n    containerName() {\n      if(this.staticContainerName != null) {\n        return this.staticContainerName;\n      }\n      return `${ this.name }-${this.uuid}-container`;\n    }\n  },\n  mounted() {\/\/\n    \/\/ id is generated by frontend - this will avoid loading the same\n    \/\/ script twice\n    const scriptId = `micro-frontend-script-${this.name}`;\n    const renderMicroFrontend = () => {\n      const fnName = `render${this.name}`;\n      const containerName = `#${this.containerName()}`;\n      \/\/load the render function per convention and handover the container id\n      window[fnName](containerName);\n    };\n    if (document.getElementById(scriptId)) {\n      renderMicroFrontend();\n      return;\n    }\n    \/\/first load the manifest.json this contains the way forward\n    fetch(`${this.host}\/manifest.json`)\n        .then((res) => res.json())\n        .then((manifest) => {\n          const script = document.createElement(\"script\");\n          script.id = scriptId;\n          \n          script.crossOrigin = \"\";\n          \/\/load out the path to the main.js file\n          script.src = `${this.host}\/${manifest[\"src\/main.js\"][\"file\"]}`;\n          script.onload = () => {\n            \/\/ call the function defined on top which will resolve then the app\n            renderMicroFrontend();\n          };\n          document.head.appendChild(script);\n        });\n  }\n};\n<\/script>\n\n<style scoped>\n<\/style><\/code><\/pre>\n\n\n\n
At the mounted<\/em> stage we will trigger a check and if necessary a load of the corresponding script files.<\/p>\n\n\n\n
Each script is ensured to be loaded only once, where the script id is the identifier here. Each microfrontend must follow a convention here and offer in its own application a function called render<name><\/em> (e.g. renderDiceRoll<\/em> ).  The manifest json must per convention offer a file with src\/main.js<\/em> which consists of the render functions. The script is than attached to the document header section so that it can be loaded. Afterwards the function is called, which calls the actual render function of the microfrontend app.<\/p>\n\n\n\n
Calling one microfrontend is than as simple as including this in the main container.<\/p>\n\n\n\n
<vue-micro-frontend name=\"diceroll\" host=\"http:\/\/localhost:8000\"\/><\/code><\/pre>\n\n\n\n
The full sample can be found here https:\/\/github.com\/zelle7\/vue3_microfrontend_poc<\/a><\/p>\n\n\n\n
Not solved here<\/p>\n\n\n\n
Things which are left out here: <\/p>\n\n\n\n