DEV Community: Victor

18 Cards with form design tips

Victor — Thu, 27 May 2021 12:57:34 +0000

Hey devs!

I made 18 cards with tips of common mistakes when designing web forms.

I've also posted them on Twitter, so if you're a Twitter user you can make a bookmark there.

Here we go

How to design almost any UI element. A curated list of 58 articles.

Victor — Thu, 15 Apr 2021 11:55:01 +0000

Hi there!

Recently I posted on Twitter a list of 58 links related to different UI elements. It turned out that the tweet was very helpful, but it's not very convenient to read the links as a thread.

So I wanted to share them here, on dev.to, in a single list.

Buttons

7 Basic Rules for Button Design

Button Design — UI component series

UI cheat sheet: buttons

Text fields

UI cheat sheet: text fields

Text fields & Forms design — UI components series

The Anatomy of Input Field

Checkboxes & Toggles

Checkbox vs Toggle Switch

Toggle-Switch Guidelines

Toggle switch design: the full run through

38 Checkbox Designs

Radio Buttons

Selection controls — UI component series

Radio Buttons UX Design

Radio button design: easy selection and decision-making

Tables

Design better data tables

The Ultimate Guide to Designing Data Tables

Designing better data tables for enterprise UX

Datepickers

How to Design a Perfect Date Picker Control?

Date Picker Design Best Practices

A hunt for the perfect date picker UI

Sliders

Designing The Perfect Slider

Slider design UI patterns and examples

Slider Design: Rules of Thumb

Tabs

Module Tabs in Web Design: Best Practices and Solutions

12 Tabs Design guidelines

Dropdowns

UI cheat sheet: dropdown field

Dropdowns: Design Guidelines

Drop down list design: the complete guide

Pagination

Paging, Scrolling, and Infinite Scroll

UX: Infinite Scrolling vs. Pagination

Users' Pagination Preferences and "View All"

Search inputs

Best UX practices for search inputs

Design a Perfect Search Box

Site Search Suggestions

Breadcrumbs

Breadcrumbs: 11 Design Guidelines for Desktop and Mobile

Are breadcrumbs still fresh for UX?

Breadcrumb examples for inspiration

Carousels

Carousel/slider design best practices (with examples)

Carousel Usability: Designing an Effective UI for Websites with Content Overload

Designing a User-Friendly Homepage Carousel

Modals

Best Practices for Designing UI Overlays

Big, bold UX—using modal windows for in-app user engagement

Modal & Nonmodal Dialogs: When (& When Not) to Use Them

Modal dialogs

Cards

Card UI design: fundamentals and examples

Simple Design Tips for Crafting Better UI Cards

Designing cards

Tooltips

Tooltip Guidelines

Designing Better Tooltips For Mobile User Interfaces

Tooltips: your secret weapon for improving feature discovery

Navigation

Navigation design: Almost everything you need to know

UX Design for Navigation Menu

The Fastest Navigation Layout for a Three-Level Menu

Loaders

Progress Indicators Make a Slow System Less Insufferable

Stop Using A Loading Spinner, There’s Something Better

Best Practices For Animated Progress Indicators

Forms

Design Better Forms

Form Design: 13 Empirically Backed Best Practices

The UX behind designing better forms

That's it. Hopefully, it'll be useful for web devs. If you wish, follow me on Twitter, I post a lot about UI/UX there.

4 Things you didn't know about text

Victor — Tue, 23 Mar 2021 17:34:59 +0000

Hi there! 👋

Text is an essential part of most interfaces. It doesn’t matter if it’s a landing page or a web application.

Here are four things you probably didn’t know about it.

Understanding them might help you to make your texts look nicer and more balanced.

Lest level up your UI skills 💪

Rags

A “rag” in typography is the uneven side of a paragraph where the text is aligned on the other side. So if the text is right-aligned, the rag is on the left side and vice-versa.

A poor rag creates distracting shapes in the white space of the margin.

Compare these two images.

The left text feels less balanced than the right. To fix rags, you can adjust the text width and hyphenations.

Rivers

Rivers are the white gaps that can appear in the text (especially justified ones) when there is too much space between words on consecutive text lines.

Usually, they appear when you justify your text. So you can easily fix it by aligning the text to the left side.

Widows

A widow is a paragraph-ending line that falls at the beginning of the following page or column, separated from the rest of the text.

One of the possible solutions to avoid widows is to insert an early page break.

Orphans

Orphan is a paragraph-opening line that appears at the bottom of a page, separated from the rest of the text.

Orphans and widows are very similar to each other.

I found controversial definitions and mnemonic rules to remember who is who. One of the funniest was “Widows have a past but no future, while orphans have no past but a future.”

But it doesn’t matter much what do you call them. It’d be better if you fix them. Same as for widows, page break can help.

Conclusion

These four problems described above make text un-balanced and look no that good as it could be.

I’m pretty sure it won’t matter that much if you have a widow or rivers in the text on your landing page.

BUT REMEMBER: Interface consists of many things. Everything can look good and bad. Everything can be convenient to work with and not that convenient.

When we see an interface, we experience certain emotions. And if you cared about most things, it’d be a pleasure for the user.

There is a special effect that describes this behavior:

“The aesthetic–usability effect describes a paradox that people perceive more aesthetic designs as much more intuitive than those considered to be less aesthetically pleasing.”

If you want to learn more, follow me on Twitter, I tweet a lot about UI/UX stuff :)

Interview questions. Are they wrong?

Victor — Tue, 10 Nov 2020 11:20:39 +0000

In this article, I'm going to share a controversial opinion about interview questions. I understand that I may be wrong, and I'm not claiming that this is 100% true for most cases.

It's applied not only for web development but since I'm a web dev, I'll show examples based on my experience.

What's wrong with the interview questions?

I've been working as a web dev for almost ten years. I've started working in 2011 when I graduated. My tech stack hasn't changed from that time. I still use PHP/MySQL & javascript mostly.

From time to time, I hear about interview questions asked in small/mid-sized companies.

And here is the confusion: while I've been developing web apps, I really haven't used or written such code samples as interviewers ask me to write or explain.

I don't understand this.

For example, a company develops some web apps, maybe a CRM or analytics apps.

Nowadays, a lot of systems are written using frameworks.

In 90% of cases, typical tasks which devs do are:

Install framework
Build UI with components
Set handlers for UI elements
Send requests using Axios or another library
Provide feedback to the user, depending on the results of the requests
Use some libs for common stuff, like charts/validation/date pickers/etc
HTML/CSS stuff
Working with external APIs
etc

Now, I've rarely had to:

Deal with complex type conversion in javascript
Deal with algorithms. I understand that for Google, or for really complex systems (if you make a game, develop 3D graphics, etc.), they a must. But not for a typical web app.
Use prototypes. I use them but rarely
Write tricky code when I don't know what "this" points to. When I started working with frameworks, I rarely had problems with "this"
Remember that typeof something is something not logical. Since javascript is not easy to remember and understand if we talk about types. I really forget all the time what's the type of array (Object?) and why NaN is not NaN

Let's check some interview questions, and I'll be more clear.

Example questions

I've just googled "tricky javascript questions," and here what I got. Companies might not ask exactly these questions, but they are in the same category, tricky questions.

function foo() {
  let a = b = 0;
  a++;
  return a;
}

foo();
typeof a; // => ???
typeof b; // => ???

I've never in my life written let a = b = 0. Non-readable, who knows how this works in javascript.

Oh, "b" is global in this case? Nice. I didn't know about it. And didn't have to deal with it, never.

Next.

const clothes = ['jacket', 't-shirt'];
clothes.length = 0;

clothes[0]; // => ???

I'm not sure I've ever changed the length of the array. I change the array itself, not its length. But in case I did change it and had some problems with it, I'd console.log the result and know immediately what's going on.

function arrayFromValue(item) {
  return
    [item];
}

arrayFromValue(10); // => ???

What? No comments.

let i;
for (i = 0; i < 3; i++) {
  const log = () => {
    console.log(i);  }
  setTimeout(log, 100);
}

This one is a prevalent question. I always forget why it works that way, but I'm aware of this case. Not sure if I have ever written something like this, but after let was introduced, it's not a problem.

Let's go ahead:

Why 018 - 017 equals 3?

NEVER used the octal system. Okay, guys who are attentive enough may notice the leading zero in the numbers. But another dev, who can be very responsible & experienced, might not notice this and might not remember that the octal system exists at all.

Again, I don't claim that my opinion is absolute, immutable truth.

But when I hired people, I asked only questions like these:

What is computed/methods/filters/watchers in vuejs?
Which library do you use for working with API?
Which API you worked with?
OS experience, do you know Linux? Are you okay with bash?
Do you have examples of your work?
Which IDE / OS you use, comfortable with?
HTTP verbs/headers/codes
Ways of optimizing site?

etc

I think I never ask "What the code will output". Do you want to know what the code will output? console.log :)

SAME for logical quizzes, you know all these quizzes about coins & scales etc.

I never solved them, but I can write an HTTP request in a minute.

Do you need a coin/scale-solver or you need to display results of an API request to your users?

Validate it. The right way.

Victor — Tue, 03 Nov 2020 10:28:37 +0000

Intro
Composing error messages
Selecting the right place
Validation modes
- Aggressive
- Passive
- Lazy
- Eager
Help your users
Practical examples
- Facebook
- Steam
- Name.com
Afterword

Intro

Forms are essential parts of any user interface. They differ from a single input and a button, ending with huge complex forms containing multiple sections.

The validation process often accompanies forms. For developers, it might be clear how the form should be filled.

But remember that there are so many circumstances you have to take into account.

Your users can be children. They can be old. They can be tired. They can be drunk.

They can fill the form from mobile. From tablet. From desktop.

In a car. In a cafe. At home.

They can even be drunk, in a car, with children, and filling the form from a tablet. 😊

Once I worked in a company that specialized in real estate searching. They had a site where you could place an advertisement when you wanted to sell a house.

I worked in the company as a UX-intern for a month. The whole month we were researching how users fill the advertisement form and their mistakes. Just imagine, the whole month...😱

At first, validation might look like a simple process.

You find some javascript library, put validation rules, and that's it.

However, validation is a very complex process in terms of user experience, which is often underestimated.

The aim of validation is not to pass your data to the server correctly. It's about helping users fill it with less effort. Your server still needs validation.

The main aim is to reduce interaction costs.

Here I want to show you some useful tips regarding the validation process.

Composing error messages

First of all, the messages themselves should be explicit. This means that you should clearly indicate what's wrong with the data user entered.

Bad example: "Your password is wrong."
Good example: "Your password should contain at least 6 characters."

Then, the messages should indicate what user should do. This rule is applied to the whole UX area. When the user received a message, he shouldn't be left with no clues of what to do next.

Bad example: "Something went wrong, sorry!"
Good example: "Looks like someone has already used your email, please, use another email address."

I don't claim that my English is good. My purpose here is to show that there should be some indication of what to do next.

This is quite common when you get an error message in an app, which says that something went wrong, but it doesn't provide any information on what to do next. Apps just leave users alone, and this doesn't help them to do their tasks.

The messages should be human-readable, meaning that you write for users, not for machines.

Bad example: "Ooops, the server responded with 500 code."
Good example: "Something went wrong on our side, we already received the error & our team is working on it. If it's urgent, contact our support at support@app.com."

Again, I may be way too wordy here, but I want to transmit the main idea.

Selecting the right place

There are two main principles of showing validation errors: inline and after the user submits the form.

In the case of inline validation, the error messages are shown next to the input fields. While in the case "after the user submits the form" it may vary: you can show all validation errors at once next to every input or show them in the beginning/at the end of the form.

The best place to show validation errors is inline. The reasons are obvious:

User will notice it as soon as he makes a mistake
He can fix it as soon as he notices it
No need to scroll & find inputs which are filled incorrectly

When user types in a certain field, he is in the context of this field. So if we show him an inline validation error, we will not switch the context: he knows which field we are talking about.

While if we show him all errors at once, it will result in high interaction costs.

Compare these two approaches:

Inline:

User types in email
Gets validation error
He knows that he has just typed his email, so he even doesn't have to read the message. If he sees something red around email input, then he knows that something's wrong with what he has just typed in
Easily fixes it

All at once:

User types in email
User types in the name
User types in the phone number
Presses submit
Gets few validation errors. He has to read them to understand what he has typed wrongly

It's clear that in the second case, we ask much more effort from him than in the first case.

Validation modes

One is the most important part of the validation process if when to trigger validation errors.

Here I love how vee-validate handles this: https://logaretm.github.io/vee-validate/guide/interaction-and-ux.html.

So there are basically four modes:

Aggressive: Triggered when the user presses a key on input.
Passive: Triggered when the form is submitted.
Lazy: Triggered when the user leaves the input (on blur or change).
Eager: This is a combination of aggressive and lazy, as it first validates when the user leaves the input (on blur or change), then if the input is invalid, it will behave aggressively until the input is valid again, and it will go back to being lazy.

Now, let's consider these modes from the UX point of view.

Aggressive

This is one of the worst.

In this case, when the user has just started typing, you immediately validate the input. Which in 99% of cases leads to the error being shown.

But the user might actually know how to fill the input correctly. He can't do this instantly.

In most cases, I wouldn't recommend this approach.

Passive

This one is better.

In this case, you show validation errors when the user presses submit. I believe for simple forms that contain a couple of inputs it may be applicable.

But if you have a large form containing multiple inputs divided into different groups, don't use this mode.

Imagine the user has copied bank account information from a paper to the form, as well as email, password, random other fields. And then after submitting the form, he gets a dozen errors? Looks scary.

Lazy

In Lazy mode, the validation is triggered when the user leaves the input.

It is much less annoying than aggressive mode and, in my opinion, is pretty nice.

The user finished typing, decided that he has typed everything correctly, and then switched to the next input.

But this approach has one significant drawback. In case the user made a mistake and returned to the input to correct it, the validation will trigger only when he switches to the next input.

Imagine the user typed the wrong email, returned to the input to correct it, corrected it but hasn't yet switched to another input and still sees the error. That's not nice.

Eager

The eager mode is a combination of aggressive and lazy, as it first validates when the user leaves the input.

If the input is invalid, it will behave aggressively until the input is valid again and will go back to being lazy.

So, how it works:

User typed an email. While he was typing it, we do not validate his data
User switched to another input. If he made a mistake in an email, we show him an error (like in lazy mode) and turn the input in aggressive mode.
User returned to the email input and started fixing his mistake. As soon as he fixed the error, we remove the validation message. We don't wait till he leaves input as in lazy mode. We're in aggressive mode.
Now, the input in lazy mode again.

Looks pretty good.

Help your users to fill the form correctly

You should help your users to fill the form as much as you can. What can you do?

Break large forms into groups of inputs
Indicate which fields are required
Pre-fill inputs when possible
Provide masks when possible (e.g., phone number format, dates, etc.)
Provide hints. For example, when the user types in a password, which should have some complexity, you can always show the user how well he does.

Consider showing the user that he has filled an input correctly.

For tiny forms, like the login form, it might not be necessary. However, if the form is complex, it might be a good idea to show users right away that he's doing well.

Another example: you have a signup form. Your site is popular, so there is a high probability that the email is already taken.

The user has entered the email and switched to the password field. And nothing happened. He might be a bit worried if the email is taken or not.

To reduce possible stress, you can show right away if the email is acceptable or not.

Practical examples

I'm not that good at writing. Instead, I'd better show some examples of poorly designed validation forms I found on the Internet.

Facebook

Here is the Facebook signup form.

Apart from making labels inside inputs, which is generally considered a bad practice, Facebook also hid validation error messages under icons.

So to understand what I've done wrong, I need to click (not even hover) the icon.

Instead, it'd be better to show the messages explicitly.

Next, Facebook has special rules for user passwords. In case the user didn't follow the rules, he'll get the next error: "Enter a combination of at least six numbers, letters and punctuation marks (such as ! and &)."

However, it'd be better to show how the user is doing when he's typing the password. Something like this:

Steam

Let's check out Steam's register form:

Okay, so, a simple sign up form took the whole screen...🤔

Why not tell me that I've typed the wrong email as soon as I did this?
Why should I confirm the email address if, after submitting the form, you'll send me a verification link? It looks like I should verify my email twice for you?
All errors are placed at the top in a single message. It takes time for me to look up at the error alert and then figure out what fields are wrong.
"And find more errors highlighted below." Okay, you're a machine, why you require me to do the work of finding errors? Tell me right away. I understand that you highlighted the fields, but still...
By the way, you haven't highlighted the captcha

Name.com

Honestly, I got no idea what's the site is about. I've just typed in "create your account" on google, and it seems like it's a popular site :)

But it has quite a few validation errors.

So, let's take a look at the form.

Woah, your form looks really big. It's okay. Sometimes we have to ask the user a lot of questions. But again, why not show validation errors as soon as I've filled an input?

See, I've made so many mistakes: wrong phone number, wrong email, wrong zip code. After I click the submit button, you don't even bother to scroll me to the first invalid input!

By the way, this is awesome hint: if the user clicks submit and some inputs are wrong, scroll him to the first error! There are plenty of solutions:

https://github.com/logaretm/vee-validate/issues/2395
https://stackoverflow.com/questions/60870424/vuetify-vee-validate-scroll-to-the-first-validation-error

But back to the form. Here is a list of mistakes:

Show errors inline, as soon as the user has finished entering data in an input
Provide masks for phone number/zip code. If possible.
My own preference: I'd make the form more compact, way too large.

Good thing you show me how good I am at entering my password though!

Afterword

The main thing you should take from this article: always follow common sense. EVERY rule can be broke. There are really MANY circumstances which you should consider.

Your users are developers who are using vim for writing their essays? They use the console browser, maybe lynx? Oh well...

Or maybe your users are old citizens? Then make your inputs BIGGER. They might not have a good vision.

Or maybe your users are children? Then make your inputs colorful. They will entertain them!

Just think about who your users are and research how they might use your app.

Thank you, Victor

P.S. I tweet about UI/UX stuff from time to time https://twitter.com/vponamariov 😊

Typical interface mistakes developers make

Victor — Sat, 24 Oct 2020 11:37:33 +0000

I’ve been working on web applications for more than ten years now. As a developer, it was always hard for me to make my interfaces look good and user friendly. But I still wanted them to be so.

Now, as a solo founder, I realize that you might not have money for a designer. However, in order to make decent interfaces, it’s not necessary to have one.

It’s now popular to talk about people who don’t have CS degrees but have become developers. I’m convinced that the same applies to developers who want to build beautiful interfaces: you don’t need a design degree.

Here are some of the most frequent mistakes I meet when I browse random web apps.

Complexity over simplicity

It often happens that developers design interfaces for their convenience. They might be quite complicated but easy to use for their creator.

While the title seems to be way too abstract, I can show some examples of what I mean by complexity over simplicity.

For example, sometimes devs try to fill the empty space in their app or provide some additional hints which aren’t necessary.

Remember: a good interface doesn’t need an explanation.

Sometimes people use excessive wording, e.g., “Your Email” while it is obvious that the app asks for your email, so you can simply put it as “Email”.

Have a large form? Break it into groups.
Have a large number of groups? Make a wizard, breaking the * process of filling the form into steps.
Need to provide a broad explanation? Put it into a popup, which is hidden by default.
Have complex filtering or advanced settings? Hide them by default

Wrong grouping

One of the essential things in user interfaces is the rule of grouping. I don’t know if there is a particular term for this, but here is the illustration which will help you understand what I mean.

If you have two logical groups of elements, the distance between these groups should be bigger than the distance of the elements inside these groups.

While it may seem pretty obvious, I often come across interfaces that violate this principle. A few days ago, a fellow asked me to check his design. Here is an example of a violation

As you can see, the “Features” label is placed between two blocks. While we read from top to bottom, we can guess that the features come after the title, but it still takes some minimal amount of time to verify this.

In complex applications, it can be worse.

So pay special attention to the margins and paddings. Even if it’s a matter of a couple of pixels, our eye can catch this.

A large number of elements inside one group

Our mind cannot operate a large number of elements inside one group. This may be applied to anything: starting from buttons ending with menu links.

Do you remember the days when the interfaces looked like this?

This is a good illustration of the violation of two principles: wrong spacing between groups and many elements inside one group.

Right now I’m writing this article in Google docs. The toolbar is broken into logical groups. Each group does not contain many elements, up to 5-7.

So, if you have a group of elements that contain too many elements (more than 6-7), then try to break them into separate groups.

Lack of contrast

The picture above demonstrates the problem with contrast. You can often read a text inside a button, but you don’t realize that it has low contrast. You just got used to the text, but new users will feel some tension.

Sometimes this is pretty easy to fix. When you’re developing your site in a web browser, you can check contrast using dev tools.

Not enough attention to UX

There are plenty of examples when people have nice looking interfaces but forget about the UX side.

This keyboard has “power” and “delete” buttons next to each other. But people often use the del button, while almost don’t use the power button. So you can accidentally click on the wrong button and turn your laptop off.

Everybody knows how it’s frustrating to work with Excel cell formatting...

Not everyone does UX research before designing their interfaces…

So these are just some examples of typical mistakes I can think of for this article.

If you want to get more such stuff, check out my Twitter https://twitter.com/vponamariov :)

Cheers,
Victor.

How I built architecture of uptime monitoring service

Victor — Thu, 17 Sep 2020 18:47:56 +0000

Intro
Requirements
VPS Provider and Servers
Technologies used
How a node works
How the core server works
To sum up
What didn't work
Why it took so long?

Intro

Hi there!

This is my first article so it might not be perfect 😇

Almost a year ago I decided to build an uptime monitoring service, which resulted in https://pingr.io.

It is a web app that continuously checks that your URL responds with 200 OK or any other response code you prefer.

So the idea is pretty straightforward. You might think that it's not that hard to make an HTTP request after all.

But it took me a year. 😱

In this article I want to describe how it works.

I don't claim that the architecture is good.

The architecture is somewhat the compromise between launching your product asap and having excellent architecture.

I didn't want to spend yet another year of making it perfect, since it's pretty hard to keep motivation during the development.

I'd love to hear what can be improved and where I did it completely wrong.

Let's dive in.

Requirements

At first, it seems like it's an easy task to make an HTTP request. However, there are a lot of requirements for what the service should do. Here are some of them:

The URL should be checked from multiple nodes distributed around the world.
Minimum check frequency is 1 minute
You should be able to add new nodes
Every node should make a decent number of HTTP requests per minute. At first, I was okay with 500-1000. But when the user number grows, it might be much more.
Apart from HTTP checks, the service should also check SSL certificates (if they are valid/expires soon, etc.)
The UI showing URL status should be updated in realtime
The user should be notified of uptime/downtime events via different ways depending on his choice

VPS Provider and Servers

I think that if you want to have your product up and running as soon as possible, it's okay to pay more for services which you you are comfortable with.

So I tried both ScaleWay and Digital Ocean but eventually moved all my servers to Digital Ocean since I liked it more.

What I have:

Ubuntu VPS with MySQL. 3 GB / 1 vCPU
5 Ubuntu VPS which are located in different parts of the world. 3 GB / 1 vCPU
Ubuntu VPS for the core server. 4 GB / 2 vCPUs
Redis database: 1 GB RAM / 1vCPU

Regarding MySQL. In the beginning, I used their RDS, since it's meant to be used as a database, and everything should've been cool. But when I wanted to change my.cnf I realized that I couldn't do that. And I like to have control of everything, at least in the beginning while I'm learning.

So, for now, I decided to have just a VPS with MySQL installed since it gives me more control.

Why MySQL? No idea. I've just worked only with this database.
Why Ubuntu? No idea. I've just worked only with this OS. 😝

Technologies I used

Laravel for backend
VueJS for frontend
MySQL for Database
Redis for queues
cURL for sending requests (Guzzle library)
Supervisord for keeping my workers up and running
...
PROFIT!

Listing of artisan commands

When I was writing this article, I realized that it might help a lot if I list all the Laravel's commands which I use here:

php artisan monitor:run-uptime-checks {--frequency=1} - Dispatches uptime checks jobs. Ran by cron every frequency minutes
php artisan checks:push - Fetches check results from the local Redis database to the temporary MySQL table. Kept running continuously by Supervisord
php artisan checks: pull - Fetchs check results from the temporary MySQL table and calculates monitor status/uptime/other indexes. Kept running continuously by Supervisord.

How a node works

This is one of the most important parts of the article, which describes how a single node works.

I should note that I have a Monitor entity, representing a URL that should be checked.

Getting monitors ready for uptime check

The php artisan monitor:run-uptime-checks command fetches monitors from the database based on some conditions.

One of the requirements is uptime check frequency, which means how often we should check the monitor. Not every user wants to check their sites every minute.

Then, using Laravel scheduling mechanisim, it's easy to setup running this command with different frequencies.

Passing frequency as an argument helps me to get only the monitors I need to check, depending on what frequency the user has set.



// In the RunUptimeChecks command, we fetch monitors by frequency specified by the user

$schedule->command(RunUptimeChecks::class, ['--frequency=1'])
         ->everyMinute();

$schedule->command(RunUptimeChecks::class, ['--frequency=5'])
         ->everyFiveMinutes();

$schedule->command(RunUptimeChecks::class, ['--frequency=10'])
        ->everyTenMinutes();

$schedule->command(RunUptimeChecks::class, ['--frequency=15'])
         ->everyFifteenMinutes();

$schedule->command(RunUptimeChecks::class, ['--frequency=30'])
         ->everyThirtyMinutes();

$schedule->command(RunUptimeChecks::class, ['--frequency=60'])
         ->hourly();

Filling up the queue

Then I put the uptime check jobs into the Redis queue for every monitor I have. This is what happens in RunUptimeChecks command:



foreach ($monitors as $monitor) {
    RunUptimeCheck::dispatch(
        (object) $monitor->toArray(), 
        $node->id
   );
}

👉 You may notice here something strange: (object) $monitor->toArray().

At first, I passed the Monitor model to the job. However, there is a significant difference: when you pass a model to a job, it stores just a model id in the queue. Then, when the job is being executed, Laravel connects to the database to fetch the model, which resulted in hundreds of unnecessary connections.

This is why I passed an object instead of the actual model, which serialized quite well.

Another possible approach is removing the SerializesModels trait from the job, which also might work, but I haven't tried that.

So after this operation, we have some number of jobs in the queue ready to be executed.

Running uptime checks

To execute the jobs, we need to run the php artisan queue:work command.

What we also need is:

Many instances of the command running, because we need to do as many checks as we can per minute
If the command fails, we need to revoke it and run again.

For this purpose, I used Supervisord.

What it does is it spawns N number of PHP processes, every process is queue:work command. If it fails, Supervisord will rerun it.

Depending on VPS Memory and CPU cores, we might vary the number of processes. Thus, we can increase the number of uptime checks performed per minute.

Storing the temporary result

Now, after we ran a check, we need to store it somewhere.

First, I store the check result in the local Redis database.
Since there might be many processes that continuously push data to the queue, it fits perfectly for this purpose, since Redis is an in-memory database and is very fast.

Then I have another command php artisan checks:push that fetches the checks from the Redis database and does the batch insert into the raw_checks MySQL table.

So I got two tables: monitor_checks and raw_checks. The first one contains the latest successful check of a monitor and all of its failed checks. I do not store every check of every node per minute, since it'll result in billions of records and it doesn't provide much value for end-users.

The raw_checks table serves as a bridge between the core server and all nodes servers.

After each check we need to do a lot of stuff:

Recalculate uptime of every node
Recalculate the average response time of every node
Recalculate monitors uptime/response time based on nodes info
Send notifications if needed

It would be much more reasonable to fetch many checks at once and do all calculations on a server located close to the MySQL server.

For example, the connection between the Indian node and the MySQL server located in Germany is relatively slow.

So the aim is to make the nodes as independent as they can be.

All they do regarding MySQL connection is: fetch monitors which should be checked & store results of checks. That's it.

How the core server works

At the core server, I run the php artisan:checks-pull command, which behaves like a daemon: it has an infinite loop that fetches checks from the raw_checks table and calculates such things as average uptime, response time, and some others.

Apart from that, it is responsible for queueing jobs for downtime notifications.

That's actually it: we have monitors with updated status, uptime & response time attributes.

Updating realtime data

In order to update monitor status on the web app, I use Pusher and Laravel's broadcasting feature.

So the setup is straightforward.

php artisan checks:pull gets a check from the raw table, sees if the monitor is online, and if it's not, it fires the MonitorOffline event, which is broadcasted using Pusher.
Web app sees the new event from Pushed and marks the monitor as offline

To sum up

So, to sum up:

Every node has a cron job, which fetches the monitor list and put the uptime check jobs into the local Redis queue
A lot of threads ran by Supevrisord check the queue and make the HTTP requests
The result is stored in Redis
Then bunch of checks stored in local Redis moved to the raw checks table in the MySQL server
The core server fetches the checks and do the calculations.

Every node has the same mechanism. Now, having a constant stream of checks from the raw table, the core server can do many things like calculated average response time from a node, etc.

If I want to extend the number of nodes, I'll just clone the node server, do some small configuration, and that's it.

What didn't work

At first, I stored ALL checks in the database. Both failed and successful. It resulted in billions of records. But users mostly don't need it. Now instead, I have an aggregation table which stores uptime and response time by an hour
At first, the uptime check job did all the logic itself: I didn't have any temporary/bridge databases. So it connected to the MySQL server, calculated new uptime etc. Which immediately didn't work as soon as the number of monitors increased up to ~100. Because every check job did maybe 10-20 queries. 10-20 queries * 5 nodes * 100 monitors. So yeah, it wasn't scalable at all
Using a dedicated Redis server instead of the raw_checks table. Since the raw checks table behaves like a cache, it might be reasonable to consider using Redis for this purpose. But for some reason, I kept losing checks data.

I tried both the sub/pub features of Redis and just storing the data. So I gave up and used a mechanism that is familiar for me: MySQL.

Also, I think I've read somewhere that Redis is not the best solution if we need 100% confidence in storing data.

Why did it take so long?

Because of multiple factors.

I work at a full-time job, so I could work only in the evenings.
I haven't had such experience before. Every project is a unique one.
I had some psychological problems which I've described in this article
I've checked many different ways of making this work with a high number of monitors. So I was kind of rebuilding the same thing many times
Take into account that I also built a UI and did everything alone.

DEV Community: Victor

18 Cards with form design tips

How to design almost any UI element. A curated list of 58 articles.

Buttons

Text fields

Checkboxes & Toggles

Radio Buttons

Tables

Datepickers

Sliders

Tabs

Dropdowns

Pagination

Search inputs

Breadcrumbs

Carousels

Modals

Cards

Tooltips

Navigation

Loaders

Forms

4 Things you didn't know about text

Rags

Rivers

Widows

Orphans

Conclusion

Interview questions. Are they wrong?

What's wrong with the interview questions?

Example questions

Validate it. The right way.

Table of contents

Intro

Composing error messages

Selecting the right place

Validation modes

Aggressive

Passive

Lazy

Eager

Help your users to fill the form correctly

Practical examples

Facebook

Steam

Name.com

Afterword

Typical interface mistakes developers make

Complexity over simplicity

Wrong grouping

A large number of elements inside one group

Lack of contrast

Not enough attention to UX

How I built architecture of uptime monitoring service

Table of contents

Requirements

Getting monitors ready for uptime check

Filling up the queue

Running uptime checks

Storing the temporary result