DEV Community: Muzafar Umarov

Dynamic DNS sync with Cloudflare

Muzafar Umarov — Sat, 28 Dec 2024 21:50:03 +0000

Dynamic DNS sync with Cloudflare

If you ever get yourself a Raspberry Pi, NAS, or turn an old computer into a server, you start to think about accessing it from outside of your network. This usually requires you to open a port on your router and forward to the IP of your device. Some of the services you might want to access could be a Wireguard/OpenVPN VPN or some other service.

One note about VPN, there is a way to get into your network without opening a port. You can use https://tailscale.com/ to open a tunnel to your network and access it with better security. However, using Tailscale doesn’t work with all use cases. In this blog post, I go over how to automatically sync your public IP with Cloudflare and always have your Dynamic DNS domain point to the correct IP address.

Also those of you who have experience with Cloudflare and using their proxy, you will know that Cloudflare only will proxy certain ports and the port you have for your VPN or other service might not work. If you need to have a dedicate subdomain for VPN, you can modify the code below and have it update two records. That's how I have setup.

Another note on syncing IPs with cloudflare: there are already some tools that can do this for you. I went this path, because I wanted to understand how it works under the hood and it was fun! If you are interested in writing some code to automate some tasks, this post is for you!

Assumptions

Your domain is on Cloudflare (or you are willing to change your domain provider to Cloudflare)
You can run a docker container in your server
You have deno installed on your computer
You are comfortable writing some TypeScript code to check IP and update it using Cloudflare APIs

Get started

Cloudflare Domain Settings

Create an A record for your Dynamic DNS subdomain or full domain for your public IP.

You can skip this step, if you already have an A record for your public IP.

Cloudflare API Token

Go to Account API Tokens > Create Token and select the Edit Zone DNS template.

You want to only allow Zone DNS Edit/Read permissions.

You also want to limit access to the specific zones you want to work with. In this case, you want to only work with the zone that will have your Dynamic DNS IP A Record. This will limit the blast radius of the API token.

Then you need to Continue to Summary and Create Token.

Store the API key securely while you build the rest.

Cloudflare Worker

You can either use the Cloudflare CLI or the Dashboard to create your worker. I started out by doing this on the Dashboard. Later, I generated a Cloudflare Worker project with CLI and pushed it to a Gitlab repo. Then I connected the existing Worker to the repo. This added support for automatic deployments on push to the main branch.

Create a hello world worker and get it deployed to Cloudflare workers. This will set up all the basics.

You might be asking, why are we using Cloudflare Workers? Because I preferred to keep the Cloudflare API related work within Cloudflare’s walled garden. API key, ideally, never leaves the platform. You will be directly making requests against the Cloudflare Worker and the worker will take care of interacting with Cloudflare API.

Architecture

Code

We will be using TypeScript and Deno.

Cloudflare Worker

You need to make sure you have some secrets set:

WORKER_API_KEY: API key to authenticate with the Cloudflare worker
API_KEY: Cloudflare API key you created earlier
DNS_ZONE_ID: Cloudflare Zone ID. You can get it by making a GET request to https://api.cloudflare.com/client/v4/zones with "Authorization: Bearer API_KEY" in the headers. Be sure to replace API_KEY with your actual API key. Grab the id of the zone you want to update.
DNS_RECORD_ID: This is the ID of the Dynamic DNS record. You can find it by sending a GET request to https://api.cloudflare.com/client/v4/zones/DNS_ZONE_ID/dns_records. It will return an array of DNS records. Grab the id of the record you want to update.

wrangler.toml: These are the environment variables for the worker

[vars]
DDNS_NAME="ddns.YOUR_DOMAIN.com"
DDNS_COMMENT="DDNS for my server"
DDNS_PROXIED=true

index.ts

import { getIp } from "./get-ip";
import { updateDnsRecord } from "./update-dns-record";

export default {
  async fetch(request, env): Promise<Response> {
    const WORKER_API_KEY = env.WORKER_API_KEY
    const API_KEY = request.headers.get('Authorization')

    if (API_KEY !== WORKER_API_KEY) {
      return new Response('Not Authorized', { status: 403 })
    }

    if (request.method === 'PUT') {
      const { ip } = await request.json() as { ip: string }
      return updateDnsRecord(ip, env)
    } else {
      return getIp(env)
    }
  },
} satisfies ExportedHandler<Env>;

get-ip.ts

export async function getIp(env: Env) {
  const options = {
    method: "GET",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${env.API_KEY}`,
    }
  };

  try {
    const response = await fetch(
      `https://api.cloudflare.com/client/v4/zones/${env.DNS_ZONE_ID}/dns_records/${env.DNS_RECORD_ID}`,
      options
    )

    const { result: { content: ip } } = await response.json() as { result: { content: string } }

    return new Response(JSON.stringify({ ip }), { headers: { 'Content-Type': 'application/json' } });
  } catch (err) {
    console.error(err)
    return new Response(JSON.stringify(err))
  }
}

update-dns-record.ts

export async function updateDnsRecord(ip: string, env: Env) {
  if (ip) {
    // snake_case because Cloudflare API uses snake_case :)
    const zone_id = env.DNS_ZONE_ID

    const id = env.DNS_RECORD_ID
    const name = env.DDNS_NAME
    const comment = env.DDNS_COMMENT
    const proxied = env.DDNS_PROXIED

    try {
      const update = {
        id,
        zone_id,
        name,
        comment,
        type: "A",
        content: ip,
        proxied
      }
      const body = JSON.stringify(update);

      const options = {
        method: "PUT",
        headers: {
          "Content-Type": "application/json",
          Authorization: `Bearer ${env.API_KEY}`,
        },
        body,
      };

      const response = await fetch(
        `https://api.cloudflare.com/client/v4/zones/${zone_id}/dns_records/${update.id}`,
        options
      )

      const responseBody = await response.json()

      return new Response(JSON.stringify(responseBody), { headers: { 'Content-Type': 'application/json' } });
    } catch (err) {
      console.error(err)
      return new Response(JSON.stringify(err))
    }
  }

  return new Response(JSON.stringify({ message: 'bad request' }));
}

Docker Container

You can get started by installing deno on your machine and generate a new deno app with deno init ddns_sync.

I used Deno in this example, because it is so easy to get started and have a running code without installing bunch of stuff. Deno is so awesome for that. I installed zero packages to achieve cron and HTTP requests.

Dockerfile

FROM denoland/deno:alpine-2.1.4

WORKDIR /app

ADD *.ts .
ADD *.json .

RUN deno cache main.ts

ENTRYPOINT ["deno", "task", "start"]

main.ts

Deno.cron("Sample cron job", "*/1 * * * *", async () => {
  const currentDateTime = new Date().toISOString()
  try {
    const [publicIp, ddnsIp] = await Promise.all([
      getPublicIp(),
      getExistingDdnsIp(),
    ]);

    if (publicIp === ddnsIp) {
      console.log(currentDateTime, "IP address did not change");
    } else {
      const updatedIp = await updateDdnsIp(publicIp);
      console.log(
        currentDateTime,
        updatedIp === publicIp
          ? "DDNS IP has been updated"
          : "DDNS failed to update"
      );
    }
  } catch (error) {
    console.error(currentDateTime, 'Error: ', error)
  }
});

async function getPublicIp(): Promise<string> {
  const response = await fetch("https://api.ipify.org/?format=json");
  const body = await response.json();

  return body.ip;
}

async function getExistingDdnsIp(): Promise<string> {
  const response = await fetch(Deno.env.get("WORKER_URL"), {
    headers: { Authorization: Deno.env.get("API_KEY") },
  });
  const body = await response.json();

  return body.ip;
}

async function updateDdnsIp(ip: string) {
  const options = {
    method: "PUT",
    headers: {
      "Content-Type": "application/json",
      Authorization: Deno.env.get("API_KEY"),
    },
    body: JSON.stringify({ ip }),
  };

  const response = await fetch(Deno.env.get("WORKER_URL"), options);
  const body = await response.json();

  return body.result.content;
}

deno.json

{
  "tasks": {
    "dev": "deno run --unstable-cron --allow-net --allow-env --watch main.ts",
    "start": "deno run --unstable-cron --allow-env --allow-net main.ts"
  },
  "imports": {
    "@std/assert": "jsr:@std/assert@1"
  }
}

You can build your docker image and run it on your server like this:

docker build -t ddns-sync .
docker run -d --name ddns-sync \
  -e API_KEY=WORKER_API_KEY \
  -e WORKER_URL="http://ddns.YOUR_USERNAME.workers.dev" \
  --restart unless-stopped ddns-sync

That’s it. That should have you check your public IP every minute and compare it against the DNS record. If your public IP changes, this will automatically update it. You will get about a minute of outage if this happens.

I recently had to do this and decided to document it as a blog post. I hope someone finds this helpful!

The code quality is at the level of a homelab project, so there is definitely room for improvement. Let me know if you have suggestions on how to improve this.

If you have any questions or corrections, definitely leave a comment. I am more than happy to answer them.

Stop exposing your Node.js metrics 🛑

Muzafar Umarov — Wed, 14 Feb 2024 02:15:31 +0000

In many production environments, having application instrumented using something like Prometheus metrics is a minimum. These metrics can tell you a lot about the state of your application. You can have your alerting system monitor these metrics and alert you when something is wrong (i.e. error rate above threshold).

Let's say your application is public facing. However, all the systems involved with metrics are all internal and not public facing. Everything runs inside the private network of your organization. This is because all your metrics will contain information specific to your server and domain. You will be exposing your routes and methods used.

I love Fastify. It is a great Node.js server web framework. If you want to expose Prometheus metrics from your server, you have to use fastify-metrics. By default, it will add a /metrics route and serve default metrics along with the HTTP route histograms and summaries. On a public facing Fastify server, you are doing to be exposing these metrics to the public.

Fastify has a great recommendations on productionizing your Fastify server. There is a section on running multiple instance of your Fastify server:

There are several use-cases where running multiple Fastify apps on the same server might be considered. A common example would be exposing metrics endpoints on a separate port, to prevent public access, when using a reverse proxy or an ingress firewall is not an option.

Exposing metrics

You usually start a Fastify application like this:

import Fastify from "fastify";

const mainApp = Fastify({ logger: true });

mainApp.get("/", () => {
  return { hello: "world" };
});

try {
  await mainApp.listen({ port: 3000, host: "0.0.0.0" });
} catch (err) {
  mainApp.log.error(err);
  process.exit(1);
}

If you follow the fastify-metrics docs, you will setup metrics by registering it on the mainApp

import fastifyMetrics from 'fastify-metrics';

...

await mainApp.register(fastifyMetrics, {
  endpoint: '/metrics'
})

If you navigate to http://0.0.0.0:3000/metrics, you will see bunch of metrics. So if your application is serving traffic from port 3000, then your metrics will be accessible publicly.

Example of a Kubernetes service to route port 80 and 443 to your deployments:

---
apiVersion: v1
kind: Service
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: fastify-metrics-demo.test.domain
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: '443'
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: ARN
  labels:
    app: fastify-metrics-demo
  name: fastify-metrics-demo
  namespace: fastify
spec:
  ports:
  - name: http
    port: 80
    targetPort: 3000
  - name: https
    port: 443
    targetPort: 3000
  selector:
    app: fastify-metrics-demo
  type: LoadBalancer

This is how the service monitor for this application would look like:

---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: fastify-metrics-demo
    component: metrics
    prometheus: app
  name: fastify-metrics-demo-metrics
  namespace: fastify
spec:
  endpoints:
  - honorLabels: true
    interval: 15s
    path: "/metrics"
    port: http
  selector:
    matchLabels:
      app: fastify-metrics-demo

Based on the config above, if you went to https://fastify-metrics-demo.test.domain/metrics, you would see your Prometheus metrics. Let's fix that.

Running a second instance

Instead of serving metrics from the mainApp, you can create a second instance and endpoint value to null.

const mainApp = Fastify({ logger: true });
const metricsApp = Fastify({ logger: true });

await mainApp.register(fastifyMetrics, {
  endpoint: null,
});

This will allow mainApp to instrument the server by collecting metrics. Then you can have metricsApp serve them on a separate port.

metricsApp.get(
  "/metrics",
  { logLevel: "error" },
  async (_, reply: FastifyReply) => {
    return reply
      .header("Content-Type", mainApp.metrics.client.register.contentType)
      .send(await mainApp.metrics.client.register.metrics());
  }
);

Don't forget to start mainApp and metricsApp:

try {
  await mainApp.listen({ port: 3000, host: "0.0.0.0" });
  await metricsApp.listen({ port: 3001, host: "0.0.0.0" });
} catch (err) {
  mainApp.log.error(err);
  process.exit(1);
}

Now, if you navigate to http://0.0.0.0:3000/metrics, you will get a 404. Metrics are no longer accessible publicly. You can access them privately through http://0.0.0.0:3001/metrics.

Now let's tell Kubernetes to scrape metrics from the new port. First we need a service for it:

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: fastify-metrics-demo
    component: metrics
  name: fastify-metrics-demo-metrics
  namespace: fastify
spec:
  clusterIP: None
  ports:
  - name: prometheus
    port: 3001
    protocol: TCP
    targetPort: 3001
  selector:
    app: fastify-metrics-demo
  sessionAffinity: None

Then we declare the Service Monitor:

---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: fastify-metrics-demo
    component: metrics
    prometheus: app
  name: fastify-metrics-demo-metrics
  namespace: fastify
spec:
  endpoints:
  - honorLabels: true
    interval: 15s
    path: "/metrics"
    port: prometheus
  selector:
    matchLabels:
      app: fastify-metrics-demo

Now, if you try to go to https://fastify-metrics-demo.test.domain/metrics, you will get a 404. But if you go to your Prometheus instance, you will be able to query your metrics.

Wrap up

As you can see, it is very simple to expose your metrics on another port. This is how most people do it with Rails applications. I wanted to replicate the same behavior.

One downside is running two instances of your server. Granted, the metricsApp doesn't have all the extra plugins registered. Its sole responsibility is to serve a route. Other than the memory overhead, you aren't paying a big price for this implementation.

Let me know if you have built something like this before.

Code can be found here: https://github.com/umarov/fastify-metrics-demo

Why we chose Vue

Muzafar Umarov — Fri, 17 May 2019 19:50:37 +0000

When I joined Optoro, a technology company that helps retailers manage their returns, five years ago, the world of front-end development was in a completely different place. Grunt was the go-to tool, and Gulp was becoming popular. "Bundling" was just concatenating all the JS into a single script.js. AngularJS was the hottest front-end framework, and CoffeeScript was a socially acceptable language to use.

If you were to time travel from four or five years ago to today, there would be so many new concepts to learn. Changes to ECMAScript alone are huge since five years ago. These things make transitioning from a Gulp + AngularJS to a more modern setup more tricky. On top of that, every developer has their own opinions based on what they've used. Convincing a group of people that X library is better than what they are using takes a lot of effort. Because changing a library/framework isn't as simple as changing your package.json and a few lines of code. These libraries/frameworks are investments. There is always a cost to adopting a new technology. So balancing costs and benefits of a certain technology is tricky when introducing a technology stack.

Originally we started out with “simple” jQuery user interfaces. As our product grew, we wanted to scale our user interfaces. AngularJS was the best choice for us at the time and we paired it with Grunt to create a mono-repo of AngularJS apps. And with a mono-repo of apps, we needed a build system to build every app. Grunt would help us convert CoffeeScript, SASS, and Haml into JavaScript, CSS, and HTML, respectively. We eventually switched to Gulp for our build system, which lasted us a long time.

But, as you can see from the title of this blog post, we eventually ended up picking Vue over all the other awesome frameworks/libraries out there. Before going into why we picked Vue, I wanted to talk about our steps leading into committing to Vue and adding support for it in our build system. Changing the build system would be required for anything that we would have picked since everything has moved towards modules, bundling and code splitting. We can't get away with the string concatenation of the scripts anymore.

Another convention of the newer frameworks/libraries is using component-based architectures. All of the user interface is built using components. These components are expressed like HTML elements and can be easily reused. Components authors can set specific APIs for their components and allow for more predictable user interfaces. Since we already had a number of applications written in AngularJS, we decided to start by adopting a component-based architecture inside of our current systems. This made developers start planning and architecting their user interfaces with components instead of giant monolithic controllers. As we switched to Vue/React/Angular, we can use that same concept. AngularJS added support for components in version 1.5. This was exciting and refreshing. It really made AngularJS more enjoyable and maintainable. I updated our docs and added support for AngularJS components during our Hack days so our developers can start building components.

While making progress on componentizing our apps, newer frameworks and libraries were becoming more and more popular. Every other day there would be blog posts about React, Vue, or Angular. Internally in our tech department, discussions on what we should use next started coming up. Teams were starting to plan new projects. People felt that it would be a good opportunity to look into alternatives to AngularJS.

As our tech department grew, the difficulty of maintaining our front-end application also grew. With global concatenated scripts, it was becoming really difficult to keep track of things. Since AngularJS automatically injects services into a controller with Dependency Injection, it was often harder to track these services across different modules---the assumption developers made with concatenated scripts was that the injected service was somewhere in the script.js. It also made it more difficult to debug. Our bundles were pretty big. We were shipping a lot of unused code. It was pretty easy to make AngularJS perform poorly. We eventually added ESLint and John Papa's Angular style guide to improve our code, but that was limited to the JS code. It didn't check the templates, and it was hard to enforce it on existing code bases. The linter eventually was pretty noisy and fixes would take additional time. Overall, we were ready to try something else.

For the successor for AngularJS in our stack, our goal was to pick something developers could adopt quickly and wouldn’t have to go through a huge mental shift. Something familiar would definitely win the hearts of more developers. React was ruled out due to JSX and a complete different way of doing things compared to AngularJS. Angular (2+) was opposed due to being completely different than AngularJS and TypeScript. In the end, Vue seemed like a good alternative to AngularJS. It has similar template syntax and a lot of shared concepts (Directives, Filters, and Components). It’s also easier to learn than React or Angular (2+) coming from AngularJS.

The learning curve wasn't the only part of Vue that attracted us. A lot of our developers found the documentation to be extremely helpful. Everything is organized nicely and the code examples are easy to understand. After reading through the docs extensively, picking up and building something with Vue is relatively easy. Different code samples and examples really cover a lot of ground. I personally benefited a lot from the documentation.

People joke around and say, "There is a new JS framework every five minutes." It's a bit exaggerated and partly correct. If you are not actively following JS Twitter, the rapid pace of development of new tools and technologies can be overwhelming. It's hard to tell if a new library will stick. So far the sticking factor has been the community behind a framework. AngularJS and Ember had set a good example.

Fortunately with Vue we didn't have to worry about that part. The vibrant community around Vue gave us a ton of confidence. It's not Yet Another Framework™. It's being used by a lot of people and it is growing pretty fast. As of December 31st, 2018, Vue has been downloaded 23 million times on npm, vs 1.7 million in 2017, Vue Devtools had about 700k users, vs 84k in 2017, and the Vue Github repository has 130k stars, vs 37k in 2017. Evan You, creator of Vue, mentions a lot of these stats during his State of Vue talks.

By this point we realized that Vue was the perfect candidate for us. After winning the hearts of the people in our Tech Department with Vue, there was still a lot of work before we could deploy Vue code to production.

Now the difficult part is fitting Vue into our build system. I started working on this during our Hack days again. Vue CLI v2 uses webpack and includes different things based on the template. All of our front end apps live in a single git repository and Gulp builds all of them with different plugins, so throwing webpack into the mix was tricky. Eventually, I used one of the best features of npm: npm scripts. By default, Vue CLI adds a handful of npm scripts to develop locally, build for production (minify, uglify, tree-shake, etc.), run tests and lint the JavaScript, CSS, and HTML code. I took advantage of this to have Gulp build Vue apps by calling the correct npm scripts. This way I didn't have to integrate webpack with Gulp. This made a lot of things easier and it will allow us to swap frameworks/libraries easily as long as the correct npm scripts are available. Once I had a working example, I presented it to our developers and everyone was excited.

Months after polishing and fixing bugs in the integration with Vue, we shipped our first Vue app to production on March 2018. Right after that, other teams started building their new apps with Vue and the feedback has been awesome. With the help of Vue's documentation, our developers were able to pick up Vue in a pretty short amount of time. Some of our developers took online courses and some just learned it on the fly. Thanks to code splitting from webpack, our bundles are much smaller and we are lazy loading all of our non-critical code. These performance improvements are going to make the user experience of our applications better by loading faster.

So that's it, right? Have we fixed all of our front end problems by adding Vue and webpack? Of course not. Once we have more teams on Vue, I next want to focus on transitioning the initial webpack setup from Vue CLI v2 to Vue CLI v3. This will allow us to drop all the repetitive webpack configs and have simpler apps.

There is always something to improve and upgrade. This is our first blog post, and we have a lot of awesome posts coming up. I hope you follow us to keep up with what we’re up to! Thank you for reading!

Easy access control in your Vue apps

Muzafar Umarov — Tue, 19 Mar 2019 20:42:09 +0000

As you start growing your application and have more users, you will want to add some access control to some part of your application. It's a pretty common problem to stumble upon when you are building sophisticated applications

Let's say you are building an application for a retail store and you will have different levels access.

Salesperson
Manager

The salesperson will be able to checkout people, but won't be able to provide a discount to a customer who needs a discount. The manager can come in, authenticate themselves and be able to see the user interface to allow them to give a discount.

This type of a use-case can happen in any environment that we build user interfaces for. So coming up with a solid solution will help you delivery more effective apps.

How would we do something like this in Vue?

`v-if`

Let's say we have a component that applies a discount:

<customer-discount :order="order" @discount-applied="onDiscountApplied" />

This component could include an <input> field with a <button> to apply the discount.

A basic solution might be to add a v-if check to hide this component if the user is not allowed to give discounts.

<customer-discount
  v-if="user.canApplyDiscount"
  :order="order" 
  @discount-applied="onDiscountApplied" />

This will work fine for most use-cases. If you are already following this pattern, continue doing it. There is nothing wrong with it.

Using v-if everywhere you need access control could become cumbersome. You will end up repeating the logic in multiple places. This will be worse once you want to share the behavior across different Vue apps. For modularity and re-usability, we will need to do it differently.

What is a better solution then?

`<slot />`

With <slot>s in Vue, you can create some really awesome components. They allow you to compose and add features to your apps using templates.

In this example, we will create a component called <access-control />. This component can accept a role that a user has to have in order to see what's inside the component. What's inside the component will be toggled based on a logic inside <access-control />.

Let's look at the implementation:

<template>
  <div v-if="hasRole">
    <slot />
  </div>
</template>

<script>
export default {
  props: {
    roles: { type: Array, default: () => [] },
    role: { type: String, default: '' }
  },
  computed: {
    hasRole () {
      return this.roles.length === 0 || this.roles.includes(this.role)
    }
  }
}
</script>

All the magic happens in the hasRole computed property. Everything is powered by the props that are passed into this component. You can drop this component anywhere in your app and reuse with other roles.

<access-control :roles="['salesperson']" role="manager">
  <customer-discount :order="order" @discount-applied="onDiscountApplied" />
</access-control>

Let's say, you want to now show a component based on multiple roles. You could refactor the props to accept an array of roles as the requirement. Instead of doing that, you can compose <access-control />.

Here is an example of a component that allows the user to order inventory:

<access-control :roles="userRoles" role="manager">
  <access-control :roles="userRoles" role="team-lead">
    <order-inventory />
  </access-control>
</access-control>

That looks pretty cool. One downside is the repeating of :roles="userRoles". If you are using Vuex, you can use a mapGetter to get the user roles. So that will clean up your templates and just allow you to pass the required role.

Now, I can already hear functional component enthusiasts typing below about how I could have used a functional component here instead. And they are right!

Enter `functional: true`

I created the same example with a functional component. It's shorter as well. Since it's functional, Vue doesn't create a new component object for functional components. It also makes it an even better candidate for composing for multiple roles.

<script>
export default {
  functional: true,
  props: {
    roles: { type: Array, default: () => [] },
    role: { type: String, default: '' }
  },
  render (_, { props: { roles, role }, children }) {
    if (roles.length === 0 || roles.includes(role)) return children
  }
}
</script>

Believe or not, that's the whole component. You can import it and use it the same way as the non-functional version. This one will be super light-weight and powerful.

Here is Codesandbox that shows both versions:

So here you go. A simple component you can use in any Vue app that requires some access control. It's easy to use and light-weight.

I hope you enjoyed reading this post. Let me know if you have done something like this! It's a pretty common problem. I stumbled upon it recently and create a component for it at work.

DEV Community: Muzafar Umarov

Dynamic DNS sync with Cloudflare

Dynamic DNS sync with Cloudflare

Assumptions

Get started

Cloudflare Domain Settings

Cloudflare API Token

Cloudflare Worker

Architecture

Code

Cloudflare Worker

Docker Container

Stop exposing your Node.js metrics 🛑

Exposing metrics

Running a second instance

Wrap up

Why we chose Vue

Easy access control in your Vue apps

How would we do something like this in Vue?

v-if

<slot />

Enter functional: true

`v-if`

`<slot />`

Enter `functional: true`