Forem: Yurich

My own Tinkerwell-like Script

Yurich — Wed, 05 Mar 2025 23:21:07 +0000

I like the idea of Tinkerwell. It looks very convenient when you need to execute a query or command using Laravel syntax.
Especially, I missed this when I needed to run a query on staging or production.

I do not recommend running any queries on production. In general, no one should have easy access to production. But there are situations where it really helps.

Usually, you need to log into production via SSH, find the necessary container, and, if needed, switch to the correct node.

Let's create our own script to handle this task.

Creating the script file

Create a file outside of Git, for example:

touch ./storage/framework/testing/tinko.php

With the code that you want to execute on production. For example:

<?php
$user = App\Models\User::inRandomOrder()->first();
dd($user->email);

You can run it locally very easily:

php artisan tinker tinker storage/framework/testing/tinko.php

Running it on production

To run this on production, create a script in the same folder that will execute this code:

touch ./storage/framework/testing/tinko.sh

With the following content:

#!/bin/sh
SERV=root@name-of-your-server-or-ip.com
cat ./storage/framework/testing/tinko.php | sed 's/<?php//g' | ssh -t $SERV "php artisan tinker"

What is happening here?

We store the production server path in the SERV variable.
The last command takes our PHP script, removes <?php, and passes it for execution in Tinker via SSH.

Don't forget to give execution permissions to the script:

chmod +x ./storage/framework/testing/tinko.sh

Run the command and see the result:

./storage/framework/testing/tinko.sh

Some issues

The full content of the file is dumped into the console.
There is no syntax highlighting.

But these are minor issues that can be tolerated.

You can add an alias for the command to avoid typing the full path or even create a separate Run configuration in your IDE.

Running a new Docker container for the script

Sometimes, you may need to start a new Docker container to execute the script. In that case, do the following:

#!/bin/sh
SERV=root@name-of-your-server.com
COMMAND="docker run -i --rm image_name php artisan tinker"
cat ./storage/framework/testing/tinko.php | sed 's/<?php//g' | ssh -t $SERV "${COMMAND}"

Finding a container ID before execution

If you need to find the container ID before executing the script, you can use the following script:

STAGE=root@name-of-your-server.com

CONTAINER_ID=$(ssh $STAGE "docker ps --format '{{.ID}}\t{{.Image}}'" | grep -E 'app.' | awk '{print $1}' | head -n 1)

cat ./storage/framework/testing/tinko.php | \
sed 's/<?php//g' | \
ssh -t $STAGE "docker exec -i $CONTAINER_ID php artisan tinker"

Use with caution.

Crafting a Modular Laravel API for Effective SPA Interaction

Yurich — Sun, 17 Mar 2024 11:19:17 +0000

Let's create Laravel app

composer create-project laravel/laravel example-app

or laravel new example-app

go to app folder cd example-app

Now you can run php artisan serve and visit http://127.0.0.1:8000 to verify that the website is working.

Remember that we need to adjust the .env file, specifically to configure the database connection and specify the correct URL APP_URL=http://127.0.0.1:8000.

If we don't have API routes it can be easily fixed by running the command php artisan install:api.

Let's proceed to create a modular structure. The modules will be located in the Modules folder, so let's create them in the app directory.

First of all, let's dynamically include all routes. To do this, go to app.php and add the following code:


use Illuminate\Support\Facades\Route;

if (!defined('API_PREFIX')) define('API_PREFIX', 'api/v1');  

$modules_folder = app_path('Modules');  
$modules = array_values(  
    array_filter(  
        scandir($modules_folder),  
        function ($item) use ($modules_folder) {  
            return is_dir($modules_folder.DIRECTORY_SEPARATOR.$item) && ! in_array($item, ['.', '..']);  
        }  
    )  
);  

foreach ($modules as $module) {  
    $routesPath = $modules_folder.DIRECTORY_SEPARATOR.$module.DIRECTORY_SEPARATOR.'routes_api.php';  

    if (file_exists($routesPath)) {  
        Route::prefix(API_PREFIX)  
            ->middleware(['auth:sanctum'])  
            ->namespace("\\App\\Modules\\$module\Controllers")  
            ->group($routesPath);  
    }  
}

To make the SPA works, you need to add one more route at the end of the web.php file.

Route::view('/{any}', 'spa')->where('any', '^(?!api).*');

We also need to create a Blade template spa.blade.php for the main route where Vue will be connected with libraries.

<!DOCTYPE html>  
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">  
    <head>        
        <meta charset="utf-8">  
        <meta name="viewport" content="width=device-width, initial-scale=1">  
        <meta name="csrf-token" content="{{ csrf_token() }}">  
        <title>{{ config('app.name') }}</title>  
    </head>  
    <body>
        <div id="app"></div>  
    </body>
</html>

Now, all routes that do not start with /api will be directed to this template. This will enable front-end routing.

Building a Restful API

Following the modular system laid out in the article My point of view on SPA modularity using Laravel and Vue.js, let's create the first module.

To begin, let's create a folder app\Modules.

Let's assume our CRM will have a system for managing static pages, meaning we need CRUD functionality for this.

Execute the command to create a model and migration

php artisan make:model Page -m

Edit the created files

Add the name field to both the migration file and the model. The code for the files will look accordingly.

Migration:

<?php  

use Illuminate\Database\Migrations\Migration;  
use Illuminate\Database\Schema\Blueprint;  
use Illuminate\Support\Facades\Schema;  

return new class extends Migration  
{  
    /**  
     * Run the migrations.     *     * @return void  
     */  
    public function up()  
    {  
        Schema::create('pages', function (Blueprint $table) {  
            $table->id();  
            $table->string('name');  
            $table->timestamps();  
        });  
    }  

    /**  
     * Reverse the migrations.     
     *     
     * @return void  
     */  
    public function down()  
    {  
        Schema::dropIfExists('pages');  
    }  
};

Model:

<?php  

namespace App\Models;  

use Illuminate\Database\Eloquent\Factories\HasFactory;  
use Illuminate\Database\Eloquent\Model;  

class Page extends Model  
{  
    use HasFactory;  

    const COLUMN_ID = 'id';  
    const COLUMN_NAME = 'name';  

    protected $guarded = [self::COLUMN_ID];  
}

Let's run the migrations: php artisan migrate.

In the Modules directory, create a folder named Page, which will contain the following files:

routes_api.php

<?php  

use Illuminate\Support\Facades\Route;  

Route::apiResource('pages', 'PageController');

Controllers/PageController.php

<?php  

namespace App\Modules\Page\Controllers;  

use App\Http\Controllers\Controller;  
use App\Models\Page;  
use App\Modules\Page\Requests\PageRequest;  
use App\Modules\Page\Resources\PageResource;  
use Exception;  
use Illuminate\Database\Eloquent\Builder;  
use Illuminate\Http\JsonResponse;  
use Illuminate\Http\Request;  
use Illuminate\Http\Resources\Json\AnonymousResourceCollection;  

class PageController extends Controller  
{  
    /**  
     * Display list of resources     
     *     
     * @param  Request  $request  
     * @return AnonymousResourceCollection  
     */  
    public function index(Request $request)  
    {  
        [$column, $order] = explode(',', $request->input('sortBy', 'id,asc'));  
        $pageSize = (int) $request->input('pageSize', 10);  

        $resource = Page::query()  
            ->when($request->filled('search'), function (Builder $q) use ($request) {  
                $q->where(Page::COLUMN_NAME, 'like', '%'.$request->search.'%');  
            })  
            ->orderBy($column, $order)->paginate($pageSize);  

        return PageResource::collection($resource);  
    }  

    /**  
     * Store a newly created resource in storage.     
     *
     * @param  PageRequest  $request  
     * @param  Page  $page  
     * @return JsonResponse  
     */  
    public function store(PageRequest $request, Page $page)  
    {  
        $data = $request->validated();  
        $page->fill($data)->save();  

        return response()->json([  
            'type' => self::RESPONSE_TYPE_SUCCESS,  
            'message' => 'Successfully created',  
        ]);  
    }  

    /**  
     * Display the specified resource.     
     *
     * @param  Page  $page  
     * @return PageResource  
     */  
    public function show(Page $page)  
    {  
        return new PageResource($page);  
    }  

    /**  
     * Update the specified resource in storage.     
     *
     * @param  PageRequest  $request  
     * @param  Page  $page  
     * @return JsonResponse  
     */  
    public function update(PageRequest $request, Page $page)  
    {  
        $data = $request->validated();  
        $page->fill($data)->save();  

        return response()->json([  
            'type' => self::RESPONSE_TYPE_SUCCESS,  
            'message' => 'Successfully updated',  
        ]);  
    }  

    /**  
     * Delete the specified resource.     
     *     
     * @param  Page  $page  
     * @return JsonResponse  
     *  
     * @throws Exception  
     */  
    public function destroy(Page $page)  
    {  
        $page->delete();  

        return response()->json([  
            'type' => self::RESPONSE_TYPE_SUCCESS,  
            'message' => 'Successfully deleted',  
        ]);  
    }  
}

It would be convenient to add constants in App\Http\Controllers\Controller so they can be used for response status.

const RESPONSE_TYPE_SUCCESS = 'success';
const RESPONSE_TYPE_INFO = 'info';
const RESPONSE_TYPE_WARNING = 'warning';
const RESPONSE_TYPE_ERROR = 'error';

Requests/PageRequest.php

<?php  

namespace App\Modules\Page\Requests;  

use App\Models\Page;  
use Illuminate\Foundation\Http\FormRequest;  

class PageRequest extends FormRequest  
{  
    /**  
     * Determine if the user is authorized to make this request.     
     *     
     * @return bool  
     */  
    public function authorize()  
    {  
        return true;  
    }  

    /**  
     * Get the validation rules that apply to the request.     
     *     
     * @return array  
     */  
    public function rules()  
    {  
        return [  
            Page::COLUMN_NAME => 'required|string',  
        ];  
    }  
}

Resources/PageResource.php

<?php  

namespace App\Modules\Page\Resources;  

use Illuminate\Http\Request;  
use Illuminate\Http\Resources\Json\JsonResource;  

class PageResource extends JsonResource  
{  
    /**  
     * Transform the resource into an array.     
     *     
     * @param  Request  $request  
     * @return array  
     */  
    public function toArray($request)  
    {  
        return parent::toArray($request);  
    }  
}

Currently, this class doesn't provide much assistance, but it will set a standard response and unload the controller in the future.

Our Restful API for managing the Page entity is ready.
The list of routes for this module you can find running this command

php artisan route:list --path=pages

If you comment out the line ->middleware(['auth:sanctum']) in the api.php file, you can easily test this functionality using Postman.

Groundwork SPA with a full-fledged CRUD generator

Yurich — Mon, 19 Feb 2024 00:00:00 +0000

In the previous article, I described the SPA modules and provided you with a foundation for developing such an application. Now let's dive deeper into this project and its capabilities.

https://github.com/Yurich84/laravel-vue3-spa

For the project, I chose Laravel and Vue3 with Composition API. Since the application is planned to be large, we will need a state manager system like Pinia. For authentication, we'll use Vue-Auth, Axios, and Sanctum.

For rapid development, the ElementPlus UI Kit was used. Also, there are libraries without which no large project can do:

Lodash js utilities
Day.js time manipulations
FontAwesome 6 icons
VueRouter
VueI18n

Since the modules are entirely independent, I created a set of templates for each module file and a command that allows generating a fully functional CRUD ready to use.

By executing the command php artisan make:module {ModuleName}, all necessary files will appear, including the model and migrations for a fully functional CRUD operation. You just need to execute migrations php artisan migrate, and everything will work. Along with this, a file with functional tests is generated to cover this CRUD. Most likely, you will need to add additional fields, so before migrating, don't forget to add them to the model, migration, and also display them in vue.

The first version of the application used older technologies but was no less useful. Here it is: https://github.com/Yurich84/laravel-vue-spa-skeleton.

In the new project, I decided to change several libraries:

Replaced Vuex with Pinia
Moved to Vue3 Composition API
Replaced moment.js with the lighter day.js
Used Vite instead of webpack for the builder.

Initially, this groundwork was developed for my needs, but now I hope it will be useful for other users.

My point of view on SPA modularity using Laravel and Vue

Yurich — Mon, 12 Feb 2024 15:43:28 +0000

Working on various SPA projects, I noticed that I often have to do the same actions repeatedly. We repeatedly connect the same libraries, make familiar configurations, establish the known application structure, and create similar modules. I decided to optimize this process and created a foundation for a large SPA using Laravel and Vue3.

In this article, I will share my perspective on the SPA structure using Laravel and Vue.js. We will design and establish the application architecture to make it flexible and scalable from the outset. Later, we will select the appropriate libraries to use throughout the development process. We will create CRUD and lay down modularity suitable for developing various CRMs.

I want this application to meet the following criteria:

Reduce project maintenance time and code navigation
Reduce the start project time
Avoid high cohesion between modules
Be understandable for programmers with little experience
Help avoid code duplication
Be easily extensible
Lay the groundwork for writing high-quality code in the future

To make life easier and not get lost in the project, it is necessary to structure it correctly. Initially, the application should be divided into responsibility levels, such as user interface, database, and business logic.

Next, each layer should be divided first by functionality - these will be separate modules. And then the code of each module should be divided into files according to the chosen pattern.

Inspired by the DDD philosophy, I decided to divide both the front-end and back-end into semantic modules. But these are not classical domains described by Evans. His model is also not ideal. In any application, there are always relationships between components — relationships between models.

Backend models will remain a separate layer because they duplicate the database with all its relationships.

Let's move into the module the files we always create when developing new functionality. These are routes, controllers, request classes, and resource classes.

{ModuleName}/
│  
|── routes_api.php  
│  
|── Controllers/
|   |
│   └── {ModuleName}Controller.php  
│  
|── Requests/
|   |
│   └── {ModuleName}Request.php
|
|── Resources/
    |
    └── {ModuleName}Resource.php

Other design patterns like events, jobs, policies, etc., are used less frequently, and you can decide whether to keep them as a separate layer or include them in modules.

We will also build the frontend part following this modular logic. The structure of one module will be as follows:

{moduleName}/
│
├── routes.js
│
|── {moduleName}Api.js
│
|── {moduleName}Store.js
│
|── components/
    |── {ModuleName}List.vue
    |── {ModuleName}View.vue
    └── {ModuleName}Form.vue

The module will contain a routes.js file, {moduleName}Api.js - a file where all promises and backend calls will be located. {moduleName}Store.js - a separate file will host the Store, where actions, getters, and other application state variables will be located. And we will need a folder with components. All of this should be connected automatically without unnecessary movements. All manipulations with dynamically loading modules are done to minimize coupling between them. This allows adding and removing modules without consequences.

I will explain how all of this works in the next articles, and for now, I leave a link to the ready-made groundwork here. This project also has its own module generator, which will create all necessary files for you.

https://github.com/Yurich84/laravel-vue3-spa

I will describe this project in more detail in my next article.

Comparison of barcode scanner libraries

Yurich — Tue, 18 Apr 2023 09:38:15 +0000

I was working on a web application that needed a barcode scanner that would work on all devices and platforms.

5 powerful libraries were selected. Three paid and two free.
Let's look at their main characteristics and highlight the pros and cons.
To compare how accurately they recognize the barcode, I chose different products with codes of different sizes and scanned them one by one without paying attention to the lighting.
For the experiment, I used two browsers on a 2011 Macbook and two browsers on an Android phone.

The results were evaluated on a 4-point scale and displayed in the table.

@ericblade/quagga2

Free
Weekly Downloads - 16000
The new version of quagga is just now being developed and maintained
Works well, but needs tweaking and testing
Many different settings, integrates quickly

Since it is free, it also showed itself poorly in tests, worse than the rest
You can try it here

html5 qrcode

You can test it here

Weekly Downloads - 12000
Free
Big community
Powerful enough
Easy to implement
Flexible setup

dynamsoft-javascript-barcode

https://www.npmjs.com/package/dynamsoft-javascript-barcode
Cons: paid
10,000 barcode scan bundle - $1,249
50,000 barcode scan bundle - $2,999
100,000 barcode scan bundle - $4,999

At first glance, less flexible, but everything you need is out of the box.
It takes a little longer to set up than other paid options.
Weekly Downloads - 9000
It's solutions for various platforms and languages and supports many different code formats.
7-day free period to try
You can test it here
Actually, it doesn't work in Safari version 13 and below. But such users are less than 0.5%.

scanbot.io

Cons

Paid: $25,000 per year
A young library, so I did not pay attention to it.
They have not had time to promote it yet, so a very small community. There are few stars on GitHub. And few downloads.
Large library size

Pros

There is a demo where you can test
There is a trial license for 7 days.
With many versions for different devices, it is frequently updated and supported.
It works fast enough, not inferior to scandit-sdk. But there are no on-screen prompts and there is a little lack of interactivity.

Although it performed best in the tests, I would put it in second place.

And the Oscar goes...

scandit-sdk

https://www.npmjs.com/package/scandit-sdk
Cons: Paid solution, $25,000 per year

Pros

It is a popular library
Weekly Downloads - 47,000
Easy to implement, with many functions out of the box
Maybe not be as flexible as quagga2, but powerful and works with different kinds of codes.
There are solutions for different platforms
Showed good results in tests.
You can test it here

Conclusion

Everything very much depends on the camera, device, browser, lighting, code size, and quality.
Of course, paid ones work faster, more reliably, and better, but free ones are also not much inferior to them.
Scandit-sdk seemed to me the best lib, it recognized the maximum number of codes on all devices and dealt with them very quickly. It is flexible but also expensive.

Other paid options showed no worse results and also deserve attention.

Among the free options, the Html5-code lib showed itself better, on Android in Chrome it was almost as good as paid solutions, but showed itself a little worse.
Of the four, Quagga2 screwed up the most. Although it is flexibly configured and looks good, it recognized the codes the least of all.

The article does not claim objectivity. The list of libraries may not be complete, so if you know of other libraries, feel free to comment.

From Callback Hell to Promise Chains

Yurich — Fri, 07 Apr 2023 12:49:18 +0000

When programming in JavaScript, we often have to make requests to the server. And as we know, the JS machine does not wait for the request to be done and continues to execute the next code. This approach in JS is called asynchrony.
All requests to the server are promises. Although they do not return any result at the same time, they promise that they will return something, or they will throw an error.

I want to consider an example of when we need to make several requests to the server or call several promises. Let's create an array of promises.

const promises = [
   Promise.resolve(1),
   ...
   Promise.resolve(n)
]

I just want to call all these promises from a regular loop

for (const promise of promises) {
  promise.then(r => console.log(r))
}

And it will work if we don't have to wait for the result. But most likely we need the data that returns the promises. A special case may be when each subsequent promise must depend on the data of the previous one.
The first thing that comes to mind is to call each subsequent promise in the .then method of the previous one.

promises[0].then(result => {
  console.log(result)
  promises[1].then(result => {
    console.log(result)
    promises[2].then(result => {
      console.log(result)

     ...
    })
  })
})

If you continue to nest promises one inside the other, then such code will be very difficult to read. And only indents help to orientate a little. This approach creates Callback Hell.

In this case, it would be better if the promise returns another promise. So this code can be reformatted in the promise chain.

promises[0]
  .then(result => {
    console.log(result)
    return promises[1]
  })
  .then(result => {
    console.log(result)
    return promises[2]
  })
  ...
  .then(result => {
    console.log(result)
  })

This approach is much more readable and resembles the Chain of Responsibilities design pattern.

But when working with arrays, it is still easier and clearer to use loops. Let's do it. To do this, we need to create a separate function and use the async/await syntax.

const run = async () => {
  for (const promise of promises) {
    const result = await promise
    console.log(result)
  }
}

run()

This is much shorter and clearer. This approach will work in most cases and will be understandable to a developer of any level.

The fact is that all promises are executed synchronously one after the other and it takes more time than if all requests were executed simultaneously. And in the case when the next promise does not depend on the previous one, and we want to work with the results of all requests, it is better to use special methods all, allSettled, race, any

Let's redesign this functionality so that it works more efficiently.

Promise.all(promises).then((responses) => {
  for (const response of responses) {
    console.log(response);
  }
})
.catch(error => console.error(error))

This is much better, and all promises inside Promise.all are executed asynchronously.
We have considered several approaches to working with the array of promises and their main pros and cons.
I hope this article helps you better understand promises and write better code.

Laravel MailGun with template, tags, and variables

Yurich — Tue, 04 Apr 2023 22:16:05 +0000

Laravel is a great framework with a large ecosystem. There you can find tools for various services. But sometimes official libraries, and even more so unofficial ones, do not have all the functionality we need.

Mailgun is one of the popular email services and Laravel has a driver to use this service. Although Mailgun has a powerful tool for managing templates, such an option is not included in the library.
I found other libraries on the Internet that offer work with templates, but I wanted to work with the official library and use Mail class. That's why I decided to add the create Mailgun trait that expands the capabilities of the library.

namespace App\Traits;

trait Mailgun
{
   public function template($name = 'general'): self
   {
       return $this->withSymfonyMessage(function ($message) use ($name) {
           $message->getHeaders()->addTextHeader('X-Mailgun-Template-Name', $name);
       });
   }

   public function variable($name, $value): self
   {
       return $this->withSymfonyMessage(function ($message) use ($name, $value) {
           $message->getHeaders()->addTextHeader('X-Mailgun-Variables', json_encode([$name => $value]));
       });
   }

   public function tag($name): self
   {
       return $this->withSymfonyMessage(function ($message) use ($name) {
           $message->getHeaders()->addTextHeader('X-Mailgun-Tag', $name);
       });
   }
}

Connect this trait to the mail class and now we have the template, tag, and variable methods available.

class MessageMail extends Mailable implements ShouldQueue
{
   use Queueable, SerializesModels, Mailgun;

   /**
    * Create a new message instance.
    *
    * @return void
    */
   public function __construct(
       private User $user,
   )
   {
   }

   /**
    * Build the message.
    *
    * @return $this
    */
   public function build()
   {
       return $this
           ->subject('Email Subject')
           ->to($this->user->email)
           ->html('')
           ->tag('my_custom_tag')
           ->template('mailgun_template')
           ->variable('name', $this->user->name)
           ->variable('link', config('app.url'))
           ->variable('email', $this->user->email);
   }
}

I hope that soon such an opportunity will appear out of the box. Or I finally send a Pull Request.

Communications between servers

Yurich — Sun, 02 Apr 2023 08:39:58 +0000

In today's interconnected world, communication between servers is essential for businesses to operate smoothly. Whether it's transferring data, executing commands, or exchanging messages, there are several ways to communicate between servers. This article will discuss the most common ways to communicate between servers and the protocols on which each one is based.

Protocols

HTTP/HTTPS

The Hypertext Transfer Protocol (HTTP) and its secure version (HTTPS) are the most common protocol for server communication. They are used to exchange data between web servers and clients, and can also be used for server-to-server communication. HTTP and HTTPS are best suited for web-based applications and APIs.

FTP/SFTP

The File Transfer Protocol (FTP) and its secure version (SFTP) are commonly used for transferring files between servers. FTP is best suited for transferring large files or batches of files that do not need to be transmitted in real-time.

SSH

Secure Shell (SSH) is a protocol for securely connecting to remote servers and executing commands. SSH is best suited for managing servers and executing commands on them.

TCP/IP

Transmission Control Protocol (TCP) and Internet Protocol (IP) are the most common protocols for transferring data between servers over the internet. TCP/IP is best suited for real-time applications that require fast, reliable communication.

UDP

User Datagram Protocol. It is a connectionless, lightweight transport layer protocol that is used to send and receive datagrams over a network. UDP is a member of the Internet Protocol (IP) suite, and it is often used in applications where speed and efficiency are more important than reliability.

Technologies

Message Queues

Message Queuing provides a mechanism for asynchronous communication between servers. Message Queues can be used to decouple processes, distribute work across multiple machines and recover from failures. Message Queues are best suited for applications that require high reliability and fault tolerance.

WebSockets

WebSockets are a protocol for two-way communication between a client and a server over a single TCP connection. WebSockets can be used to provide real-time communication between servers. WebSockets are best suited for applications that require real-time data exchange, such as online games, chat applications, and financial trading systems.

API calls

REST (Representational State Transfer) is an architectural style for building web services that uses HTTP methods to retrieve and manipulate data. RESTful APIs are commonly used for communication between web services.
SOAP (Simple Object Access Protocol) is a messaging protocol that defines how XML-based messages are exchanged between web services. It uses XML to encode the message and HTTP as the transport protocol.
GraphQL is a query language for APIs that was developed by Facebook. It allows clients to specify the data they need and receive only that data, reducing the amount of unnecessary data transfer between services.

Remote Procedure Calls (RPC)

RPCs allow one server to call a method on another server as if it were a local method call. RPCs can be implemented using various protocols like HTTP, TCP, and UDP. RPCs are best suited for applications that require high performance and low latency, such as scientific simulations and financial trading systems.

In conclusion, there are several ways to communicate between servers, and the choice of communication method depends on the specific use case and the requirements of the system. Message Queues, WebSockets, API calls, and RPCs are all viable options depending on the application's needs. By understanding the strengths and weaknesses of each communication method, businesses can choose the most appropriate one for their specific use case, resulting in faster and more reliable communication between servers.

How to speed up your web application

Yurich — Sun, 26 Mar 2023 22:49:10 +0000

It often happens that with the growth of the code base, the web application (site) starts to work more slowly. The page takes a long time to load. All of this annoys the end user, causing churn and less popularity. On the Internet, you can find many tips and ways to eliminate this deficiency. But I will also give some non-standard solutions that can be very appropriate in certain situations. I want to encourage the reader to make an optimized app from the very beginning.

It all depends on the type of web application and the specific situation, but I will tell you how to make the web application faster and more responsive. I divided the optimization of the web application into two parts: front-end optimization and back-end optimization.

Front-end optimization

Everything you need to optimize from the point of view of search engines will tell you https://pagespeed.web.dev/

Images compression

The user does not need pictures in the maximum quality, it is enough that they are sharp. To achieve even greater results, you can convert images to WebP format, files in this format are 26% smaller than jpeg.

Reduce the number of requests to the server

That is, combine all js files into one file or make them all download in parallel. The same for CSS files. Reduce the amount of icons using inline icons.

Minification JS, CSS, HTML

Webpack minifies JS and CSS files by default when we build them in production mode. But it does not remove useless styles or classes. For this, you can use libraries like https://purgecss.com/
Do not forget to check the dependency, connect only the functionality that you use.

Browser’s cache

PWA is one of the tools that allows you to cache your data in the browser to the extent that you can work with the web application completely without the Internet. But if you don't want to dive into it too much, you can just set the Expires HTTP header and the static files will be automatically cached in the browser.
You can also use Local Storage, Cookies, Session storage, IndexedDB, Web SQL, Cache storage as you see fit. The different storages have its advantages and disadvantages.

Web sockets

Websocket is a very powerful technology that allows you to listen to the server and update the data coming from the server in real time. They allow you to reduce the number of requests to the server and change small pieces of data with it.

Lazy loading

It is not necessary to download all the content of the page at once. Content that is off-screen, inside accordions, tabs, or otherwise hidden can be loaded later using AJAX requests or websockets.
Keep in mind that this can affect the indexing of pages by search engines, although they say that they know how to work with such pages.

CDN

The closer the end user is to the server, the faster the content will be loaded, so it makes more sense to put static data on a CDN server.
In short, a CDN is a group of servers to which your files are duplicated. These servers are located in different geographical areas and when requested, the user receives files from the nearest one.

Backend optimization

OpCache

If you're developing in PHP, you can safely enable it in most cases.
Since the code of the entire site does not change so quickly, it does not need to be constantly compiled from scratch. PHP can cache already compiled code, which makes his work much faster.

Zip or Gzip compression

Web servers such as apache and nginx can compress data on the fly.

It could be easily done with Nginx

server {
    ...
    gzip off;
    ...
}

Two modules are responsible for compression in Apache. The first module is called mod_deflate and the second mod_gzip, only one of them needs to be enabled. But this puts an additional load on the server. With mod_gzip, you need to compress each file yourself and upload it to the site root.

Database optimization

Usually, the server itself works quickly and in most cases, the long response of the server occurs due to heavy and numerous requests to the database.
In this case, it is necessary to check whether the N+1 request problem does not arise for example when the requests occur in a cycle. If this problem is fixed, it is necessary to check whether all the necessary indexes are inserted. Database optimization is a separate big topic, which I will not spotlight on in this article.
Data handling approaches such as data caching and queuing some requests play an important role. I will talk about this in detail in the next two points.

Data caching

Most of the data changes infrequently enough that it will be correct to cache it using high-speed data stores. Depending on the speed, reliability, cost, and amount of data, there are different storages, such as File, Memcache, Redis, etc.

Queues

All functionality that is not required to work at the same moment when the request is made must be queued.
For example, we save the order, and as a result - we need to get the order number. Saving the order in the database, transferring information about it to the managers via a third-party API, sending a letter to the client and the store administrator - all this functionality must be queued. This will help not only to unload the server but also to reduce the load on the database.

Scaling

If none of this helps, maybe the server simply does not cope with a large load, then you need to take a more powerful server. This is the simplest scaling (vertical scaling).
But eventually, you need to think about horizontal scaling. It is also different, depending on where the load is most significant. Raise several server instances and install a load balancer to balance the load between these servers. But suppose there are bottlenecks where the server's capacity is used to the maximum, such as rendering, conversions or file generation, etc. In that case, such functionality is transferred to a separate service, which, in turn, will be scaled separately. There are now many tools and services that can automatically scale your app according to its load.
There is also an option to switch to serverless technology, which will allow you not to think about scaling.
It also happens that it is necessary to scale the database horizontally, in this case, different replication approaches are used.

I described the main solutions that can improve the speed of the web application. In any case, it is necessary to look for a problem and choose approaches, taking into account the type of web application, its structure, and its purpose.