مقدمه ای بر کوارکوس: چرا توسعه دهندگان جاوا به سمت جاوا مافوق صوت حرکت می کنند؟

برای نزدیک به سه دهه، جاوا نیروی غالب در توسعه نرم افزار سازمانی بوده است. اکوسیستم غنی، شالوده شی گرا قوی، استقلال پلت فرم از طریق ماشین مجازی جاوا (JVM) و چارچوب های آزمایش شده در نبرد مانند Spring Boot آن را به پادشاه بلامنازع زیرساخت های باطن تبدیل کرده است.

با این حال، تغییر به سمت معماری‌های Cloud-Native، ارکستراسیون Kubernetes، Containerization (Docker)، و ** محاسبات بدون سرور (AWS Lambda، Knative)** آسیب‌پذیری شدیدی را در چارچوب‌های برنامه کاربردی جاوا سنتی نشان داد: سربار حافظه بالا و زمان راه‌اندازی کند.

هنگامی که یک میکروسرویس نیاز به مقیاس افقی از صفر تا 100 نسخه در پاسخ به افزایش ترافیک دارد، یا زمانی که یک عملکرد بدون سرور بر اساس تقاضا اجرا می‌شود، انتظار 3 تا 10 ثانیه برای بوت شدن فرآیند جاوا غیرقابل قبول است. زیرساخت‌های ابری مدرن نیازمند راه‌اندازی فوری و مصرف کم حافظه هستند - ویژگی‌هایی که به طور سنتی برای زبان‌هایی مانند Go، Rust یا Node.js محفوظ است.

Quarkus را وارد کنید: یک چارچوب جاوا بومی Kubernetes که به طور خاص برای GraalVM و OpenJDK HotSpot طراحی شده است. کوارکوس که اغلب “جاوا زیر اتمی سوپرسونیک”* نامیده می‌شود، اساساً نحوه کامپایل، راه‌اندازی و اجرای برنامه‌های جاوا را دوباره مهندسی می‌کند.

در این راهنمای غواصی عمیق، بررسی خواهیم کرد که چرا توسعه دهندگان جاوا از Quarkus استقبال می کنند، چگونه Quarkus به زمان راه اندازی فرعی دوم و ردپای حافظه میکرو، مکانیک معماری بهینه سازی زمان ساخت و نحوه ساخت یک میکروسرویس واکنشی آماده تولید در جاوا با Quarcus می پردازد.

1. معضل Cloud-Native در جاوای سنتی

برای درک اینکه چرا کوارکوس وجود دارد، باید بررسی کنیم که چگونه فریمورک‌های سنتی جاوا مانند Spring Boot یا Jakarta EE در زیر هود کار می‌کنند.

الف. هزینه سنگین اولیه سازی زمان اجرا

چارچوب‌های سنتی جاوا به شدت به بازتاب پویا در زمان اجرا، اسکن مسیر کلاس و تولید پروکسی متکی هستند:

1. اسکن مسیر کلاس: در هنگام راه اندازی، JVM هر فایل JAR را در مسیر کلاس اسکن می کند تا حاشیه نویسی هایی مانند @Component، @Service، @Controller، یا @Entity را پیدا کند.
2. پردازش حاشیه نویسی و انعکاس: این چارچوب از بازتاب (Class.forName()، getDeclaredFields()) برای ساختن یک نمودار در حافظه از دانه‌ها، ویژگی‌های پیکربندی و وابستگی‌ها استفاده می‌کند.
3. ایجاد پروکسی پویا: CGLIB یا ByteBuddy پروکسی های بایت کد پویا را در حافظه زمان اجرا تولید می کند تا از برنامه نویسی جنبه گرا (AOP)، مدیریت تراکنش پایگاه داده (@Transactional) و مرزهای امنیتی پشتیبانی کند.
4. Metaspace & RSS Inflation: تمام ابرداده ها، توصیفگرهای کلاس منعکس شده، و پراکسی های تولید شده باید در حافظه متاس فضای JVM و اندازه مجموعه مقیم (RSS) حفظ شوند.

این حلقه بازتاب زمان اجرا به چرخه های CPU قابل توجهی نیاز دارد و مصرف حافظه پشته را افزایش می دهد. یک سرویس اولیه CRUD REST در جاوای سنتی می‌تواند به راحتی 140 مگابایت تا 300 مگابایت رم را در حالت بیکار مصرف کند و 3 تا 8 ثانیه طول بکشد تا شروع شود.

ب. جریمه مالی در رایانش ابری

در محیط‌های بدون سرور و کانتینری، ارائه‌دهندگان ابر بر اساس دو معیار محاسبه می‌کنند: حافظه تخصیص یافته (GB) و مدت زمان اجرا (میلی ثانیه).

• شروع سرد: اگر یک عملکرد بدون سرور 5 ثانیه طول بکشد تا راه اندازی شود، کاربران نهایی تاخیر قابل توجهی را تجربه می کنند و شما برای 5 ثانیه محاسبه راه اندازی بیکار هزینه می پردازید.
• تراکم و مقیاس پذیری پاد: در یک خوشه Kubernetes با گره کارگر دارای 16 گیگابایت رم، شما فقط می توانید 40 نمونه میکروسرویس سنتی Spring Boot را قبل از اتمام حافظه اجرا کنید. اگر هر نمونه فقط 15 مگابایت رم مصرف کند، همان گره می تواند بیش از 800 نمونه** را میزبانی کند.

2. معماری کوارکوس: تغییر کار از زمان اجرا به زمان ساخت

کوارکوس معضل بومی ابر را از طریق یک تغییر پارادایم معماری رادیکال حل می کند: ** انتقال عملیات پویا از زمان اجرا به زمان ساخت **.

پردازش زمان ساخت (بهینه سازی پیش از زمان)

به جای اجرای اسکن مسیر کلاس، تجزیه حاشیه نویسی و سیم کشی گراف لوبیا هر بار که برنامه راه اندازی می شود، کوارکوس تمام این عملیات سنگین را یک بار در مرحله ساخت (mvn package یا ./gradlew build) انجام می دهد.

1. معماری افزونه و مراحل ساخت: کوارکوس از یک چارچوب افزونه قابل اتصال استفاده می کند. هنگام کامپایل برنامه، برنامه های افزودنی Quarkus حاشیه نویسی را تجزیه می کنند، بایت کد استاتیک بهینه سازی شده را تولید می کنند و نمودارهای تزریق وابستگی را از قبل حل می کنند.
2. فراداده از پیش پخته شده: همه فراداده های تزریق وابستگی از قبل محاسبه شده اند. هنگامی که برنامه شروع می شود، Quarkus مستقیماً کلاس های از پیش کامپایل شده را بدون فراخوانی بازتاب یا اسکن مسیرهای کلاس نمونه سازی می کند.
3. Dead Code Elimination (Tree Shaking): در طول فرآیند ساخت، Quarkus کلاس ها، متدها و کتابخانه هایی را که توسط برنامه شما استفاده نمی شوند را شناسایی کرده و آنها را کاملاً حذف می کند.

تا زمانی که برنامه JAR یا باینری بومی شما تولید شود، تمام سربار زمان اجرا حذف شده است. JVM به سادگی بایت کدهای استاتیک از قبل سیم کشی شده را بارگیری می کند و بلافاصله شروع به کار می کند.

3. GraalVM Native Image در مقابل OpenJDK HotSpot

Quarkus یک مدل اجرای دوگانه ارائه می‌کند: در OpenJDK HotSpot استاندارد فوق‌العاده سریع اجرا می‌شود، اما وقتی در یک GraalVM Native Image کامپایل می‌شود، به حداکثر پتانسیل عملکرد خود می‌رسد.

+-----------------------------------------------------------------------+
|                         Java Source Code (.java)                      |
+-----------------------------------------------------------------------+
                                    |
                                    v (Standard javac)
+-----------------------------------------------------------------------+
|                            Bytecode (.class)                          |
+-----------------------------------------------------------------------+
                       /                         \
                      /                           \
                     v                             v
   +----------------------------------+   +----------------------------------+
   |      OpenJDK HotSpot JVM         |   |     GraalVM Native Image (AOT)   |
   |  - JIT Compilation (C1/C2)       |   |  - Substrate VM                  |
   |  - Dynamic Class Loading         |   |  - No Classpath Scanning          |
   |  - Fast throughput, longer boot  |   |  - Millisecond boot, tiny RAM    |
   +----------------------------------+   +----------------------------------+

کامپایل و بسترسازی VM پیش از زمان (AOT).

GraalVM Native Image بایت کد جاوا را می گیرد و آن را مستقیماً در یک باینری اجرایی مستقل مخصوص سیستم عامل (باینری ELF در لینوکس، Mach-O در macOS، EXE در ویندوز) کامپایل می کند.

• فرض دنیای بسته: GraalVM فرض می کند که همه کدها، کلاس ها و منابع قابل دسترسی در زمان ساخت شناخته شده اند.
• Substrate VM: فایل اجرایی بومی یک موتور زمان اجرا مینیاتوری به نام Substrate VM را تعبیه می کند که مدیریت حافظه، زمان بندی رشته ها و جمع آوری زباله را بدون راه اندازی یک نمونه کامل JVM انجام می دهد.
• سربار انعکاس صفر: از آنجا که کوارکوس تنظیمات بازتاب و تعاریف پراکسی را در طول زمان ساخت آماده می کند، کامپایل تصویر بومی GraalVM بدون نیاز به فایل های پیکربندی دستی که از لحاظ تاریخی توسط بیلدهای مادری GraalVM مورد نیاز بوده است، به راحتی انجام می شود.

4. معیارهای عملکرد: شواهد تجربی

برای نشان دادن تضاد کامل در عملکرد، اجازه دهید مقایسه استاندارد صنعت را در بین سه پیکربندی زمان اجرا جاوا که یک سرویس استاندارد REST + Database CRUD را اجرا می‌کنند، بررسی کنیم:

1. ** پشته سنتی Cloud-Native ** (JVM سنتی / بوت بهار)
2. Quarkus در OpenJDK HotSpot
3. Quarkus در GraalVM Native Image

جدول خلاصه عملکرد

توجه داشته باشید که Quarkus در یک تصویر بومی در 14 میلی ثانیه - سریعتر از یک چشم به هم زدن - کامپایل می شود و تنها 13 مگابایت رم مصرف می کند. این باعث می شود جاوا به طور کامل با Go and Rust برای استقرارهای بدون سرور و بومی ابری رقابت کند.

5. موتور دو هسته ای واکنشی و امری

از لحاظ تاریخی، توسعه دهندگان جاوا مجبور بودند بین دو مدل برنامه نویسی منحصر به فرد یکی را انتخاب کنند:

1. Imperative (Thread-per-Request): کد مسدودسازی ساده و قابل خواندن با استفاده از درایورهای استاندارد JDBC و نقاط پایانی REST همزمان.
2. واکنشی (حلقه رویداد): کد ناهمزمان و غیر مسدود کننده (مثلاً RxJava، Project Reactor) با توان عملیاتی بالا، اما برای زنجیره های برگشت تماس پیچیده و اشکال زدایی دشوار بدنام است.

کوارکوس هر دو جهان را تحت یک موتور منسجم که توسط Eclipse Vert.x و Netty نیرو می گیرد، متحد می کند.

                      +---------------------------------+
                      |     Client HTTP Request         |
                      +---------------------------------+
                                       |
                                       v
                      +---------------------------------+
                      |       Eclipse Vert.x I/O        |
                      |          (Event Loop)           |
                      +---------------------------------+
                                   /       \
                                  /         \
                                 v           v
                 +-------------------+   +-------------------+
                 | Reactive Endpoint |   |Blocking Endpoint  |
                 | (Event Loop)      |   | (Worker Thread)   |
                 | - Mutiny (Uni/Multi)| | - Standard JDBC   |
                 | - Non-blocking    |   | - Imperative Code |
                 +-------------------+   +-------------------+

در کوارکوس، ورودی/خروجی غیرمسدود پایه است. اگر کد مسدودکننده سنتی را بنویسید، Quarkus به طور خودکار اجرا را به یک مخزن نخ مدیریت شده کارگر ارسال می کند. اگر از انواع واکنش‌پذیر مانند SmallRye Mutiny (Uni<T> و Multi<T>) استفاده می‌کنید، اجرا روی رشته حلقه رویداد غیرمسدود کننده با کارایی بالا باقی می‌ماند.

6. Developer Joy: Live Coding & Dev Services

فراتر از عملکرد زمان اجرا، Quarkus یک تجربه توسعه‌دهنده انقلابی را ارائه می‌کند که برای حذف حلقه بازخورد خسته‌کننده-آزمایش-راه‌اندازی مجدد طراحی شده است.

الف. برنامه‌نویسی زنده بدون راه‌اندازی مجدد (quarkus:dev)

هنگام اجرای mvn quarkus:dev، Quarkus حالت کدگذاری زنده را راه اندازی می کند. می‌توانید فایل‌های جاوا را ویرایش کنید، ویژگی‌ها را تغییر دهید، قالب‌های HTML را تغییر دهید یا طرح‌واره‌های پایگاه داده را به‌روزرسانی کنید.

دفعه بعد که درخواست HTTP را در مرورگر یا ترمینال خود راه اندازی می کنید، Quarkus تغییرات فایل را شناسایی می کند، مراحل ساخت را مجدداً اعمال می کند و برنامه را در زیر 500 میلی ثانیه مجدداً بارگذاری می کند. شما هرگز نیازی به توقف دستی و راه اندازی مجدد سرور برنامه خود در طول توسعه ندارید.

B. Quarkus Dev Services (ظروف آزمایشی با پیکربندی صفر)

اتصال یک میکروسرویس به پایگاه داده PostgreSQL، بروکر کافکا یا کش Redis معمولاً نیازمند نوشتن یک فایل docker-compose.yml و پیکربندی پورت های پایگاه داده محلی است.

با خدمات Quarkus Dev:

• اگر Quarkus وابستگی پایگاه داده را تشخیص دهد (به عنوان مثال، quarkus-reactive-pg-client) اما هیچ URL پایگاه داده در application.properties پیکربندی نشده باشد، Quarkus به طور خودکار یک ظرف Docker در حال اجرا PostgreSQL از طریق Testcontainers در پس‌زمینه می‌چرخد.
• اعتبار اتصال را به طور خودکار به برنامه در حال اجرا شما تزریق می کند.
• وقتی حالت dev را متوقف می کنید، ظرف خود را به طور تمیز پاک می کند.

7. پیاده سازی عملی: ایجاد یک سرویس کوارکوس واکنشی آماده تولید

بیایید یک میکروسرویس Quarkus تمیز و با کارایی بالا در جاوا بسازیم که یک REST API متصل به پایگاه داده PostgreSQL را با استفاده از Hibernate Reactive با Panache در معرض دید قرار می دهد.

مرحله 1: وابستگی های پروژه (pom.xml)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.ghaznix.quarkus</groupId>
    <artifactId>user-service</artifactId>
    <version>1.0.0-SNAPSHOT</version>

    <properties>
        <compiler-plugin.version>3.13.0</compiler-plugin.version>
        <maven.compiler.release>21</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
        <quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
        <quarkus.platform.version>3.15.1</quarkus.platform.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>${quarkus.platform.group-id}</groupId>
                <artifactId>${quarkus.platform.artifact-id}</artifactId>
                <version>${quarkus.platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <!-- RESTEasy Reactive for high-performance HTTP endpoints -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-resteasy-reactive-jackson</artifactId>
        </dependency>

        <!-- Hibernate Reactive with Panache for active-record data access -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-hibernate-reactive-panache</artifactId>
        </dependency>

        <!-- Reactive PostgreSQL Driver -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-reactive-pg-client</artifactId>
        </dependency>

        <!-- Quarkus SmallRye OpenAPI / Swagger UI -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-smallrye-openapi</artifactId>
        </dependency>

        <!-- Testing -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-junit5</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.rest-assured</groupId>
            <artifactId>rest-assured</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>${quarkus.platform.group-id}</groupId>
                <artifactId>quarkus-maven-plugin</artifactId>
                <version>${quarkus.platform.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

مرحله 2: تعریف موجودیت واکنشی (UserEntity.java)

Quarkus دسترسی به داده ها را با Panache، یک الگوی Active-Record در بالای Hibernate، ساده کرد.

package com.ghaznix.quarkus.entity;

import io.quarkus.hibernate.reactive.panache.PanacheEntity;
import io.smallrye.mutiny.Uni;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.Table;
import jakarta.validation.constraints.Email;
import jakarta.validation.constraints.NotBlank;
import java.time.Instant;

@Entity
@Table(name = "users")
public class UserEntity extends PanacheEntity {

    @NotBlank(message = "Username cannot be blank")
    @Column(unique = true, nullable = false)
    public String username;

    @Email(message = "Email must be valid")
    @Column(unique = true, nullable = false)
    public String email;

    @Column(nullable = false)
    public String role;

    @Column(name = "created_at", nullable = false, updatable = false)
    public Instant createdAt = Instant.now();

    /**
     * Helper method to find a user reactively by email.
     */
    public static Uni<UserEntity> findByEmail(String email) {
        return find("email", email).firstResult();
    }
}

مرحله 3: اجرای Reactive REST Resource (UserResource.java)

با استفاده از RESTEasy Reactive و SmallRye Mutiny، نقاط پایانی HTTP ما به طور کامل به صورت ناهمزمان بر روی رشته های غیر مسدود کننده عمل می کنند:

package com.ghaznix.quarkus.resource;

import com.ghaznix.quarkus.entity.UserEntity;
import io.quarkus.hibernate.reactive.panache.Panache;
import io.smallrye.mutiny.Uni;

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.validation.Valid;
import jakarta.ws.rs.*;
import jakarta.ws.rs.core.MediaType;
import jakarta.ws.rs.core.Response;
import java.net.URI;
import java.util.List;

@Path("/api/v1/users")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@ApplicationScoped
public class UserResource {

    @GET
    public Uni<List<UserEntity>> getAllUsers() {
        return UserEntity.listAll();
    }

    @GET
    @Path("/{id}")
    public Uni<Response> getUserById(@PathParam("id") Long id) {
        return UserEntity.<UserEntity>findById(id)
                .onItem().ifNotNull().transform(user -> Response.ok(user).build())
                .onItem().ifNull().continueWith(() -> Response.status(Response.Status.NOT_FOUND).build());
    }

    @POST
    public Uni<Response> createUser(@Valid UserEntity user) {
        return Panache.withTransaction(user::persist)
                .replaceWith(() -> Response.created(URI.create("/api/v1/users/" + user.id))
                        .entity(user)
                        .build());
    }

    @DELETE
    @Path("/{id}")
    public Uni<Response> deleteUser(@PathParam("id") Long id) {
        return Panache.withTransaction(() -> UserEntity.deleteById(id))
                .map(deleted -> deleted 
                        ? Response.noContent().build() 
                        : Response.status(Response.Status.NOT_FOUND).build());
    }
}

مرحله 4: پیکربندی برنامه (application.properties)

# Quarkus Application Configuration
quarkus.application.name=user-service
quarkus.http.port=8080

# Database Schema Management (Automatically managed by Dev Services in dev mode)
quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.hibernate-orm.log.sql=true

# SmallRye OpenAPI & Swagger UI Configuration
quarkus.smallrye-openapi.path=/swagger-ui
quarkus.swagger-ui.always-include=true

توجه داشته باشید که ** URL های پایگاه داده، نام کاربری یا رمز عبور را پیکربندی نکردیم**! هنگامی که ./mvnw quarkus:dev را اجرا می کنید، Quarkus به طور خودکار PostgreSQL را شناسایی می کند، یک ظرف Docker راه اندازی می کند، جدول های طرح پایگاه داده را تنظیم می کند، و Swagger UI را در http://localhost:8080/swagger-ui باز می کند.

مرحله 5: ساخت و اجرای فایل های اجرایی بومی

برای اجرا در حالت برنامه نویس Live-Coding فوری:

./mvnw quarkus:dev

برای ساختن یک باینری لینوکس بومی با استفاده از GraalVM در داخل یک ظرف داکر (بدون نیاز به نصب محلی GraalVM):

./mvnw package -Dnative -Dquarkus.native.container-build=true

برای راه اندازی باینری به دست آمده مستقیماً در سیستم عامل:

./target/user-service-1.0.0-SNAPSHOT-runner

__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2026-08-26 01:37:15,102 INFO  [io.quarkus] (main) user-service 1.0.0-SNAPSHOT native (powered by Quarkus 3.15.1) started in 0.016s. Listening on: http://0.0.0.0:8080
2026-08-26 01:37:15,103 INFO  [io.quarkus] (main) Profile prod activated. 
2026-08-26 01:37:15,103 INFO  [io.quarkus] (main) Installed features: [cdi, hibernate-reactive, panache, reactive-pg-client, resteasy-reactive, resteasy-reactive-jackson, smallrye-openapi]

راه اندازی 0.016 ثانیه!

8. مقایسه ویژگی های استراتژیک: کوارکوس در مقابل چکمه فنری

9. نتیجه گیری: آیا زمان تغییر به کوارکوس رسیده است؟

Quarkus صرفاً یک چارچوب وب دیگر نیست. این نشان دهنده تکامل جاوا برای عصر بومی ابری است. کوارکوس با ترکیب بهینه‌سازی زمان ساخت با کامپایل بومی GraalVM، این کلیشه قدیمی را که جاوا برای میکروسرویس‌های مدرن و توابع بدون سرور بسیار کند یا بیش از حد حافظه سنگین است، باطل می‌کند.

چه زمانی باید کوارکوس را انتخاب کنید؟

• برنامه های بدون سرور و رویداد محور: اگر میکروسرویس ها را برای AWS Lambda، GCP Cloud Run یا Knative استقرار می دهید، باینری های بومی Quarkus به طور کامل مشکلات شروع سرد را حذف می کنند.
• خوشه های Kubernetes با چگالی بالا: اگر هزینه زیرساخت شما تحت تسلط مصرف رم خوشه ای باشد، انتقال سرویس ها به Quarkus می تواند هزینه های حافظه را تا 75% کاهش دهد.
• Microservices Reactive: اگر سیستم‌هایی با توان عملیاتی بالا می‌سازید که نیاز به پخش جریانی غیرمسدود دارند (کافکا، gRPC، WebSockets)، کوارکوس عملکرد بالاتری را از جعبه ارائه می‌دهد.

جاوا دیگر توسط استارت‌آپ‌های آهسته یا زمان‌های اجرای متورم متوقف نمی‌شود. با Quarkus، توسعه‌دهندگان جاوا می‌توانند اپلیکیشن‌های بومی ابری را با سرعت مافوق صوت و ردپای زیراتمی بسازند.