DEV Community: Yury Troynov

Graphql easy/lazy documentation

Yury Troynov — Tue, 28 Feb 2023 10:30:45 +0000

Hi, today I wanted to share with you an easy way to visualize your Graphql schema.

Prefer watching to reading, :) here is video for ya :)

When you hear word documentation, you're probably picturing something which reminds you Apollo studio doc page or swagger doc page.

And don’t get me wrong, those kinds of documentation are good enough, but when I think about it, I think that I would like to see something like a bird eye view of your documentation,

where you could quickly jump between different parts of your visualized schema and see what is connected to what.

For example, something like bird eye view VS Code

or something a little bit closer to what we will have at the end of this tutorial, something like SQL builder in PhpMyAdmin :)

So what I wanted to share with you today is Voyager.

There are a few ways to integrate it into your project. Here I will show you how to do it as a standalone application.

I choose standalone version cause:

Don’t want to mix documentation with actual BE or FE code
Don’t want to rebuild it after any changes to schema (kinda build once, use always)
Don’t want to extend CI time even with few extra seconds

But if you want to integrate it to build process, feel free to check voyager documentation for more details. Or left a comment that you need it 🙂

So let’s start

mkdir graphql-voyager-example && cd graphql-voyager-example && npm init --yes

Install deps

npm install @apollo/server graphql serve npm-run-all

extend package.json

{
  // ...etc.
  "type": "module",
  "scripts": {
    "start:gql": "node gql-server/index.js",
    "start:serve": "serve -C voyager",
    "start": "run-p start:gql start:serve"
  }
  // other dependencies
}

create GQL server

mkdir gql-server && touch gql-server/index.js && touch gql-server/schema.js

schema.js

  type Root {
        query: Query
        mutation: Mutation
    }

export const typeDefs = `#graphql
    type Todo {
        id: ID!
        content: String!
        completed: Boolean!
    }

    type Query {
        todos: [Todo!]!
    }

    input AddTodoMutationInput {
        content: String!
    }

    input UpdateTodoMutationInput {
        id: ID!
        content: String
        completed: Boolean
    }

    type Mutation {
        addTodo(input: AddTodoMutationInput! ): Todo!
        updateTodo(input: UpdateTodoMutationInput!): Todo!
    }
`;

server index.js

import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';
import { typeDefs } from './schema.js'

const server = new ApolloServer({
    typeDefs,
    resolvers: {},
});

const { url } = await startStandaloneServer(server, {
    listen: { port: 4000 },
});

console.log(`🚀  Server ready at: ${url}`);

voyager/index.js

const introspectionProvider = (introspectionQuery) => fetch('http://localhost:4000', {
    method: 'post',
    headers: {
        Accept: 'application/json',
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({
        query: introspectionQuery,
    }),
})
    .then((response) => response.json())

// Render <Voyager /> into the body.
GraphQLVoyager.init(document.getElementById('voyager'), {
    introspection: introspectionProvider,
    displayOptions: {
        rootType: 'Root',
    }
});

voyager/index.html

<!DOCTYPE html>
<html>

<head>
    <script src="https://cdn.jsdelivr.net/npm/react@18/umd/react.production.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/react-dom@18/umd/react-dom.production.min.js"></script>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/graphql-voyager/dist/voyager.css" />
    <script src="https://cdn.jsdelivr.net/npm/graphql-voyager/dist/voyager.min.js"></script>
</head>

<style>
    #voyager {
        height: 95vh;
    }
</style>

<body>
    <div id="voyager">Loading...</div>
    <script src="./voyager.js"></script>
</body>

</html>

You could use a standard approach and install everything through NPM, but I think this approach is enough for such a small project.
Source code (GitHub)

Detox LinkedIn Feed :)

Yury Troynov — Sat, 12 Mar 2022 09:23:30 +0000

Problem
wen you add new connection in LinkedIn you automatically start follow person (nobody asks if you want to). And then you have feed full of unwanted posts.

It's not comfortable to go and unfollow each time and there is no button unfollow all.

Solution

open page where you have a list of contacts you follow (here)
open browser developer tools console and paste below script there :)

(() => {
    const selectors = {
        followingButton: "button.is-following",
        followName: ".follows-recommendation-card__name",
    };

    const waitAround = (timeout = 100) =>
        new Promise((resolve) => {
            const randomTimeout =
                Math.random() * (timeout - timeout / 2) + timeout / 2;

            setTimeout(resolve, randomTimeout);
        });

    const getAllFollowingButtons = () =>
        Array.from(document.querySelectorAll(selectors.followingButton));

    const getPendingUnfollowAll = async () => {
        const buttons = getAllFollowingButtons();

        for (const button of buttons) {
            const name = button.parentElement.querySelector(
                selectors.followName
            ).innerText;

            console.log(`Unfollow ${name}`);

            window.scrollTo(0, button.offsetTop - 260);

            button.click();
            await waitAround(300);
        }
    };

    const start = async () => {
        await getPendingUnfollowAll();

        window.scrollTo(0, document.body.scrollHeight);

        await waitAround(500);

        const buttons = getAllFollowingButtons();

        if (buttons.length) {
            await start();
        }
    };

    start().then(() => {
        console.log("unfollow all done !");
    });
})();

hit enter and enjoy clean feed line :)

What's your chrome day to day extensions list?

Yury Troynov — Sun, 19 Dec 2021 19:36:04 +0000

For many years I've been installing and removing a bunch of different chrome extensions in order to boost productivity, reduce distractions.

Here is my most used list.

Extension manager

Nowadays typical chrome user has a bunch of extensions always enabled, even if some of those extensions are not needed right now, they still there eating your ram.

Here extension manager comes to the game :) it allows you group extensions and enables them conditionally only when needed :)

ex. I have a set of extensions that I enable only when I'M at work, another set when I'm at home :) or you can enable/disable some of them based on different conditions :)

BitWarden

Amazing free open-source password manager :) works everywhere. Personally, I use it on my android, windows, mac. It's just works that's it :) also have the possibility to be deployed to personal VPS if needed.

Checker plus for Google calendar

As a developer I have meetings at my work and it's always difficult to track them, and this amazing extension simplifies this giving you constant notification how much time is left for the next meeting right on the icon, or calendar bird eye if you click on this, also brings pop-ups and notifications for events with an ability to postpone notifications for 1,2... etc. minutes.
This extension saved my ass so many times :)

AdGuard

One of the best ad blocker extensions so far (IMO), can block ads not only on web pages but also right in you tube videos ❤

GridRuller

Simple but very useful extension for those who work with frontend :) It brings guidelines like in Photoshop right into a web page (helps to fight with designers)

Dimensions

Another very useful ruler 📏 for web developers. Together with Grid Ruler (1) becomes super power.

Toby

Extension manager bro but for tabs :) helps organize tabs into namespaces, groups, workspaces. Also, you can create a team there and share tabs, groups within the team.

Notion

Notion is my own personal Wikipedia to organize everything I need to organize :) it has a free account for 1 user.

What are your day-to-day extensions which make your life easier?

Lodash import - done Right!

Yury Troynov — Sat, 10 Oct 2020 22:01:20 +0000

Lodash one of the most popular libraries which helps to optimize common things and not reinvent the wheel.

When we write code often we import lodash in different ways but is there any difference? is it influences our app?

in order to answer these questions, let's make an experiment.

So first as usual we need a playground, in this case, I will use simple CRA.

npx create-react-app lodash-import-experiment --template typescript && cd lodash-import-experiment && yarn add lodash

before we start to do something lets measure the base size and dependencies structure. analyzing-the-bundle-size, to make the experiment clear I will add some test code which later will be used with Lodash.

Interesting part starts HERE

here is our awesome app code

and its results

First try

import lodash from 'lodash'

Somebody told me once use destructuring import and webpack tree shaking will do the ~~sh*t~~ magic.

Second try

this time let's try to use destructuring import.

import { merge } from "lodash"

as you may see nothing has changed.

Third try

this time tried to use direct import for merge function.

import merge from "lodash/merge"

So as you may see this is the game-changer. import cost is only 12.39 kb vs 71.15 for both destructuring and classic imports. The only bad thing here that you will end-up with import hell.

At this point I started to remember that somebody told me once, "use lodash/fp always it has better tree shaking and there will be no import hell + FP functions written more optimized way so import cost will be definitely less.

So let's check if it's true.

Forth try

import { merge } from 'lodash/fp'

as you may see despite it doesn't help it even brings an additional +8.57kb of weight comparing to destructuring import from lodash. So my pall was definitely wrong.

So I could stop here but I decided to check all cases as in the first part of the experiment with lodash.

Fith try

(to kill curiosity and keep no answered questions)

classic import lodash from "lodash/fp"

also, let's check direct import merge from "lodash/fp/merge"

again as you may see import cost with direct import less comparing to classic and destructuring import.

to sum-up things, I've created a table.

Conclusion

Always use direct imports (keep only things you need)
Use fp-funcs only when you really need FP patterns and behavior

Accessibility, why? how? (part.1)

Yury Troynov — Mon, 11 Nov 2019 21:23:53 +0000

WHY?

1.social aspect
In the modern world, the web should provide equal access and opportunity for people with or without diverse abilities.

Accessibility perspectives

Accessibility is obligatory in most of the countries

There is a UN Convention on the Rights of Persons with Disabilities which recognizes access to information and communications technologies, including the Web, as a basic human right.

3.Business case
There is also a strong business case for accessibility. Accessibility stands in one line with other best practices such as mobile web design, device independence, multi-modal interaction, usability, design for older users, and search engine optimization (SEO). Case studies show that accessible websites have better search results, reduced maintenance costs, and increased audience reach, among other benefits. Developing a Web Accessibility Business Case for Your Organization details the benefits of web accessibility.

There are some examples when adding accessibility brings significant business value.

HOW?

while code:

Eslint plugin:

Must have

{
  "extends": [..., "plugin:jsx-a11y/recommended"]
}

Nice to have

{
  "extends": [..., "plugin:jsx-a11y/strict"]
}

While testing code:

jest-axe

examples:

Enzyme

const React = require('react')
const App = require('./app')

const { mount } = require('enzyme')
const { axe, toHaveNoViolations } = require('jest-axe')
expect.extend(toHaveNoViolations)

it('should demonstrate this matcher`s usage with enzyme', async () => {
  const wrapper = mount(<App/>)
  const results = await axe(container.getDOMNode())

  expect(results).toHaveNoViolations()
})

React Testing Library

const React = require('react')
const App = require('./app')

const { render, cleanup } = require('@testing-library/react')
const { axe, toHaveNoViolations } = require('jest-axe')
expect.extend(toHaveNoViolations)

it('should demonstrate this matcher`s usage with react testing library', async () => {
  const { container } = render(<App/>)
  const results = await axe(container)

  expect(results).toHaveNoViolations()

  cleanup()
})

verify In Browser

chrome-extension

IMPORTANT according to research made by GDS team, all automated tools will cover only about 30% issues. Rest you need to test manually.

Debugging TypeScript (Node.js) in IntelliJ IDEA

Yury Troynov — Sun, 11 Aug 2019 18:02:54 +0000

Some time ago I've started to write typescript on server-side. and right after I've faced a problem with debugging it, after searching how to do it on the internet I found out that some of the tutorials are not working or not full, so I decided to create my own. which is working :) and contains everything you need :) So let's do it.

Dependencies:

typescript
ts-node
tsconfig-paths

let's install them:

npm i -S typescript ts-node tsconfig-paths

create index.ts file touch index.ts

Now we need to add some example code for our debugging, we add it to index.ts file:

function examplefunc(num1:number, num2: number){ const a = num1; const b = num2; const c = a + b: return c; }

create debug listener config in ide

create config -> attach to Node.js/Chrome

create run config for index.ts

NodeParameters: --inspect --require ts-node/register -r tsconfig-paths/register

javascript file: index.ts

start debugger listener config debuggerListener

drop breakpoint in code and run debugts config

now execution will stop at the breakpoint, now we can easily debug ts files in IntelliJ :)