DEV Community: Isa Ozler

Grafana Pareto Plugin

Isa Ozler — Thu, 17 Sep 2020 01:17:06 +0000

With the introduction of React to Grafana Plugins, development has changed drastically. Don't want to go too much in details but, transforming, visualising, thresh-holding, opting, dashboard data is much more fun now. In combination with typescript you can create complex but also durable plugins which can be easily maintained and build up-on by the community.

[Code] Feel free to download and try it out!

In this view you can see a pretty standard Pareto-chart, with custom options like for setting the vital few and the trivial many, the visibility of the axis en bar paddings. These are small and basic features, but currently we don't need more... :)

Will be updating this post during the development. So I will try to give you guys a bit more insights. But, if you have any comments, questions or feedback, please share...

Some Context

One of my latest challenges was to help create a dashboard in Grafana where they also needed a Pareto-chart.

To our surprise this wasn't developed yet... There was a request, which wasn't picked up by anyone. So I was able to get my hands dirty :D

Conditional {i18n}

Isa Ozler — Fri, 12 Jun 2020 02:55:27 +0000

For a statistics/analytics dashboard we needed a bit more advanced and customizable localization tool. Due to restriction of external packages, I had to create one :D (Github link / Try it out!)

Basically this is a string interpolation tool which fill the placeholders with data on the fly.

I think what makes this tool nice is that you can have conditional outputs.

Basic example


import i18n from 'dynamic-i18n-io';

// some data
const data = {
  greeting: {
    isMale: true,
    name:   'Joe',
    age:    42
  },
};

// en.js
const format = {
  greeting: {
    // template contains the placeholders text
    template:   `Hello {isMale} {name} {age}`,

    // options is where you put all your values / refs
    // so if
    // greeting.options.name === true ? data.greeting.name
    // will be set to the {name} in the greeting.template literal
    options: {
      isMale: ['Sir', 'Madam'],
      name:   ['{name}', ''],
      age:    ['({age})', '']
    },

    // when condition returns true options[key][0] is set
    // otherwise options[key][1]
    // you can add logic to determine selection with a callback
    conditions: {
      isMale: (props) => props.isMale,
      name:   true,
      age:    (props) => props.isMale || props.age < 20,
    }
  }
};

const { greeting } = i18n(data, format);

// data = { isMale: true, name: 'Joe', age: 42 }
// > 'Hello Sir Joe (42)'

// data = { isMale: false, name: 'Joelle', age: 42 }
// > 'Hello Madam Joelle'

// data = { isMale: false, name: 'Joelle', age: 18 }
// > 'Hello Madam Joelle (18)'

Feel free to fork and improve based on your needs!

Or try it out!

Reusable Tagged Templates

Isa Ozler — Sun, 07 Jun 2020 12:57:17 +0000

TLTR; See it in action [https://github.com/isaozler/tagged-templates-io]

Once again, I was working on a dragon component. Based on the transition and loading state the class names should change for custom transition and loading states. There is a really nice package classnames [https://github.com/JedWatson/classnames], but most of the time I find myself stating the class name between two values. If it's true ? '--visible' : '--hidden'.

const transitionClass = `app__overlay--${isTransitioning ? 'trans-start' : 'trans-end'}`
const loadingClass = `app__overlay--${isLoading ? 'visble' : 'hidden'}`

const stateClasses = [transitionClass, loadingClass].join(' ');

# React Sample
<div className={`app__overlay ${stateClass}`} />

Problem

This does the job actually, but is quite messy, not an elegant solution and not reusable. As I mentioned earlier in the classname package you can do this;

className({ foo: true }) // => 'foo'

But, then you have to do another object to get the opposite state.

const stateClass = className({
 'app__overlay--visible': isLoading,
 'app__overlay--hidden': !isLoading,
 'app__overlay--trans-start': isTransitioning,
 'app__overlay--trans-end': !isTransitioning,
});

<div className={stateClass} />

Solution

Of course, there is always room for improvement. But for now, I ended up with a very lightweight package making at least my life easier.

const stateClass = taggedTemplatesIo(
  `{0} {0}--{1} {0}--{2}`,
  [
    ['app__overlay'],
    ['trans-start','trans-end'],
    ['visble','hidden'],
  ],
  [true, isTransitioning, isLoading]
);

# React Sample
<div className={stateClass} />

GraphQL / SQL interpolations

You can always use this for other implementations of course. It was very useful for me with GraphQL / SQL interpolations. To give you an example;

SQL

const isClient = true;
const as = 'age';
const from = ['clientTable', 'relationTable'];
const fromCondition = isClient;
const where = `${as} = ${42}`;
const start = 0, end = 10;

taggedTemplates(`
  SELECT {select} AS {as}
  FROM {from}
  WHERE {where}
  LIMIT {start}, {end}
`,
  { select: 'age_col', as, from, where, start, end },
  { from: fromCondition },
)


// Outputs

SELECT age_col AS age
  FROM clientTable
  WHERE age = 42
  LIMIT 0, 10

Conclusion

With this lightweight simple helper, I can write cleaner, easier to maintain code blocks. Hope it helps others too!

Vue 3 Composition API + D3.js

Isa Ozler — Mon, 13 Apr 2020 10:46:21 +0000

Recently I created a visualization tool that gives an insight into a particular flow. For this, I used the Composition API in combination with D3.js.

There are three functionalities I took into consideration;

Initial drawing
Interactivity on the diagram elements
Updating the information based on the interactions

Initial drawing

Within the new composition API, the initialization of the diagram has to be in the setup() method. This is called after the "beforeCreated" hook and before the created hook.

In the setup hook, we use a method called useDiagram. This is where we organize all the feature code. Thanks to the composition API in Vue 3 we now can reuse most of the controllers we write, like the "useDiagram" and end up with a much cleaner code.

// index.vue

<template>
  <svg ref="diagramEl" />
  <button @click="redrawDiagram">Update Diagram</button>
</template>

<style lang="scss">
  // diagram styles
</style>

<script>
import useDiagram from './useDiagram.js';

export default {
  setup() {
    const { 
      drawDiagram,
      redrawDiagram,
      resizeDiagram
    } = useDiagram({ diagramEl });

    onMounted(()=>{
      window.addEventListener('resize', resizeDiagram);
      drawDiagram();
    });

    onUnmounted(()=>{
      window.removeEventListener('resize', resizeDiagram);
    });

    return {
      drawDiagram,
      redrawDiagram,
      resizeDiagram
    }
  }
}
</script>

// useDiagram.js

import { select } from 'd3';
import d3Sankey from './d3-sankey-extention';
import { callbackX } from 'extra-utils';

export default function({ diagramEl }) {
  const element = diagramEl.value;
  const drawDiagram = () => {
    const svg = select(element);
    // ... usual append, attr, and transform methods
    const sankey = d3Sankey();
    // ... usual append sankey links, nodes methods
    // on the links or nodes you can attach event listeners
    // .on('click / mouseenter / ...', d => callbackX)
  };

  const redrawDiagram = () => {
    // update props or the whole diagram based on use-case
  };

  const resizeDiagram = () => {
    // resize the diagram to match viewport props
  };

  return {
    drawDiagram,
    redrawDiagram,
    resizeDiagram
  }
}

That's all. Feel free to comment your thoughts or experiences.

Multi-tenant Web Application

Isa Ozler — Thu, 02 Apr 2020 03:21:29 +0000

Developing web applications, campaign websites, or whatsoever aren't often too complex tasks. But, after a while, all of these "small" applications together become unmanageable for small teams.

For this reason, I started looking for a stack that would make it easy to start and maintain these kinds of projects together on this scale. In this article, I won't dive too deep into the technologies used, but rather give you an impression of the stack.

Use cases

The use cases we've worked on, with this stack are;

Server-side rendered static websites
Web applications
Reporting and dashboard tools The variety of use cases forces us to form a stack that is flexible enough to fulfill different scenarios.

Server-side rendered static websites

Eventually, in most cases, the ideal situation for this use case would be; to start directly on the designs and frontend components. Without having to worry about the backend architecture, the content management system, packaging manager, en so fort. Working on UI components and designing exclusive user interfaces would be the most important focus points in this use case.

Web applications

Applications require more backend work. Usually, you would have to create an API or mock it in the frontend. But, either way, determining data models will take time. And, also the way storing data will be a challenge. UI development won't be our foremost concern in this use case.

Reporting and dashboard tools

In contrast to static web sites and web applications, reporting and dashboard tools require both extensive backend and frontend workload. A configuration for such use case in this stack could be;

Timeseries for IoT data, relational or non-relational database to fit the need. - Also an opportunity to use fully-managed cloud database solutions
Serverless solutions like AWS Lambda or Node.js Express APIs
Frontend frameworks with state management in combination with D3.js (data visualization library), or Grafana (open-source analytics tool)
Also for these tools like D3.js and Grafana, the private NPM registry could be used

Layers

The stack consists of the following layers (accessible via);

Database (db.local.io)
APIs / CMS (api.local.io / cms.local.io)
UI Components Library (ui-lib.local.io)
Packaging Manager (npm.local.io)
Frontend Framework (www.local.io)
Hosting

Shared UI Component Development

Based on the framework we use, often React or Vue, we create the project codebase manually or with the default command-line interfaces. Next, we will develop our new components or extend existing ones based on the "Atomic Design" pattern. We can easily publish the package through npm-scripts. Now we can import the "package" in the frontend or use it in other projects.

The directory structure would look like this;

├── .storybook
├── dist
├── src
|   ├── components
|   |   ├── atoms
|   |   ├── molecules
|   |   ├── organisms
|   |   ├── templates
|   |   └── pages
|   ├── styles
|   └── tests
├── stories
|   ├── atoms
|   ├── molecules
|   ├── organisms
|   ├── templates
|   └── pages
└── typings

You could also use one of the available open-source UI component libraries, implement, extend and, reuse it in other projects.

Frontend

Concerning the frontend framework, there are no restrictions. Gatsby is the framework I usually prefer for simple static websites. For more complex web applications, I prefer NuxtJs or Next.js.

Benefits

The benefits with this stack are, mainly the flexibility of the boilerplate and reusability of the UI components. But, also specific mixins that keep returning in projects like function compositions, curry-, utility functions like debounce-, throttle-, and localization functions.
Composing this way assists us to avoid shared-states, mutable-data, and side-effects, and keeps our functions pure.

I hope this provided some insights about multi-tenant applications.

To have some indication about the need for a more in-depth article, please give feedback one way or another.