Rumah  >  Artikel  >  hujung hadapan web  >  Komunikasi Web Masa Nyata: Undian Panjang/Pendek, WebSockets dan SSE Explained + Next.js code

Komunikasi Web Masa Nyata: Undian Panjang/Pendek, WebSockets dan SSE Explained + Next.js code

Linda Hamilton
Linda Hamiltonasal
2024-09-23 22:30:32818semak imbas

Real-Time Web Communication: Long/Short Polling, WebSockets, and SSE Explained + Next.js code

Backstory: Soalan Temuduga Yang Tidak Dijangka

Beberapa bulan yang lalu, saya berada di tengah-tengah temuduga teknikal untuk kedudukan bahagian hadapan peringkat pertengahan. Semuanya berjalan lancar sehingga saya dipukul dengan soalan yang membuat saya sedikit terkejut.

"Bayangkan anda memerlukan satu bentuk komunikasi berterusan untuk memeriksa sesuatu setiap saat sehingga anda mendapatkan sesuatu yang anda perlukan.

Sebagai contoh, anda ingin terus menyemak sama ada pembayaran telah berjaya, seperti dalam persediaan e-dagang. Bagaimana anda akan mendekati ini?"

Saya menjawab dengan berhati-hati, "Saya rasa anda boleh melaksanakan WebSockets untuk mengendalikannya."

Pewawancara tersenyum. "Itu penyelesaian yang baik, tetapi ada pilihan lain, boleh dikatakan lebih baik, bergantung pada keadaan."

Dan ketika itulah kami menyelami perbualan tentang pelbagai pendekatan kepada komunikasi masa nyata, termasuk Tinjauan Panjang, Tinjauan Pendek, Soket Web, dan akhirnya, Acara Dihantar Pelayan (SSE), yang boleh dikatakan pilihan terbaik untuk aliran data satu arah, seperti dalam contoh pembayaran kami.

Kami juga membincangkan memilih pangkalan data yang betul untuk mengendalikan permintaan yang berterusan namun ringan ini tanpa menghabiskan sumber pelayan. Dalam konteks itu, Redis muncul, yang terkenal dengan kesederhanaan dan kecekapannya dalam mengurus jenis permintaan ini.

Perbualan ini melekat pada saya. Saya menyedari bahawa walaupun WebSockets mendapat banyak perhatian, terdapat pelbagai teknik yang, apabila difahami, boleh mengoptimumkan cara kami mengurus komunikasi masa nyata. Hari ini, saya ingin memecahkan empat pendekatan ini, bila hendak menggunakan setiap satu, dan kebaikan dan keburukannya dengan cara yang jelas dan menarik. Pada akhirnya, anda akan mempunyai pemahaman yang kukuh tentang sebab Acara Dihantar Pelayan (SSE) sering bersinar untuk komunikasi sehala, masa nyata.

Sebelum saya memulakan, terima kasih yang tidak terhingga kepada Marcos, Jurutera Perisian Kanan berpengalaman yang mengendalikan sembang itu dan memberi inspirasi kepada saya untuk menulis artikel ini beberapa bulan kemudian, yang saya amat hargai walaupun saya tidak mendapat pekerjaan itu! :)


Empat Kaedah Komunikasi Masa Nyata

Sebelum beralih ke contoh SSE, mari kita pecahkan empat kaedah yang kita bincangkan semasa temu bual itu:

1. Polling Ringkas

Tinjauan pendek mungkin kaedah yang paling mudah. Ia melibatkan membuat permintaan kepada pelayan secara berkala, bertanya, "Adakah anda mempunyai data baharu?" Pelayan bertindak balas dengan keadaan semasa—sama ada terdapat sesuatu yang baharu atau tidak.

Terbalik:

  • Mudah untuk dilaksanakan
  • Berfungsi dengan permintaan HTTP tradisional

Keburukan:

  • Memang berat sumber. Anda kerap membuat permintaan, walaupun tiada data baharu tersedia.
  • Boleh meningkatkan beban pelayan dan trafik rangkaian, yang menjadi tidak cekap untuk pemeriksaan kerap seperti kemas kini status pembayaran.

Terbaik untuk: Kemas kini data kecil dan frekuensi rendah, seperti harga pasaran saham untuk dikemas kini setiap minit atau lebih.

2. Pengundian Lama

Tinjauan panjang memerlukan pengundian pendek selangkah lagi. Pelanggan berulang kali meminta maklumat daripada pelayan, tetapi bukannya pelayan bertindak balas serta-merta, ia memegang sambungan sehingga data baharu tersedia. Sebaik sahaja data dihantar semula, pelanggan segera membuka sambungan baharu dan mengulangi proses tersebut.

Terbalik:

  • Lebih cekap daripada tinjauan singkat kerana pelayan hanya bertindak balas apabila perlu - ia sangat pantas.
  • Serasi dengan penyemak imbas dan protokol HTTP/HTTPS.

Keburukan:

  • Masih memerlukan pembukaan semula sambungan berulang kali, yang membawa kepada ketidakcekapan dari semasa ke semasa - sumber yang mahal.
  • Sedikit lebih kompleks daripada tinjauan singkat.

Terbaik untuk: Situasi di mana komunikasi masa nyata diperlukan tetapi WebSockets/SSE mungkin berlebihan (cth., aplikasi sembang).

3. Soket Web

WebSockets ialah penyelesaian yang lebih moden yang menyediakan komunikasi dupleks penuh antara pelanggan dan pelayan. Setelah sambungan dibuka, kedua-dua pihak boleh menghantar data secara bebas tanpa mewujudkan semula sambungan - yang mentakrifkan komunikasi dua hala.

Terbalik:

  • Komunikasi masa nyata sebenar dengan kependaman minimum.
  • Sesuai untuk komunikasi dua arah (cth., permainan masa nyata, apl sembang).

Keburukan:

  • Lebih kompleks untuk dilaksanakan daripada pengundian atau SSE.
  • WebSockets tidak selalunya sesuai untuk komunikasi sehala atau kemas kini yang kurang kerap, kerana ia boleh menggunakan sumber dengan mengekalkan sambungan terbuka.
  • Mungkin memerlukan konfigurasi tembok api.

Terbaik untuk: Aplikasi yang memerlukan komunikasi dua hala yang berterusan, seperti permainan berbilang pemain, alatan kolaboratif, aplikasi sembang atau pemberitahuan masa nyata.

4. Acara Dihantar Pelayan (SSE)

Akhir sekali, kami datang ke Acara Dihantar Pelayan (SSE), wira contoh pembayaran kami. SSE mencipta sambungan sehala di mana pelayan menghantar kemas kini kepada klien. Tidak seperti WebSockets, ini adalah satu arah—pelanggan tidak menghantar data kembali.

Terbalik:

  • Sesuai untuk strim data sehala seperti suapan berita, penanda saham atau kemas kini status pembayaran.
  • Ringan dan lebih mudah untuk dilaksanakan daripada WebSockets.
  • Menggunakan sambungan HTTP sedia ada, jadi ia disokong dengan baik dan mesra tembok api.

Keburukan:

  • Tidak sesuai untuk komunikasi dua arah.
  • Sesetengah penyemak imbas (terutamanya versi IE yang lebih lama) tidak menyokong SSE sepenuhnya.

Terbaik untuk: Kemas kini masa nyata di mana pelanggan hanya perlu menerima data, seperti skor langsung, pemberitahuan dan contoh status pembayaran kami.


SSE dalam Tindakan: Status Pembayaran Masa Nyata dengan Next.js

Mari kita ke inti masalah. Saya membina apl Next.js yang mudah untuk mensimulasikan proses pembayaran masa nyata menggunakan Acara Dihantar Pelayan (SSE). Ia menunjukkan dengan tepat cara anda boleh menyediakan komunikasi sehala untuk menyemak status pembayaran dan memberitahu pengguna apabila pembayaran berjaya atau gagal.

Agak pening untuk menyediakannya untuk Seterusnya kerana ia berfungsi sedikit berbeza daripada js biasa supaya anda boleh berterima kasih kepada saya kemudian!

Berikut ialah persediaan:

Bahagian Hadapan: Komponen Kawalan Transaksi

Dalam komponen berikut, kami mempunyai UI ringkas yang memaparkan butang untuk mensimulasikan pelbagai jenis transaksi yang akan datang daripada API get laluan sebenar (Pix, Stripe dan pembayaran kad kredit yang gagal). Butang ini mencetuskan kemas kini status pembayaran masa nyata melalui SSE.

Di sinilah keajaiban SSE berlaku. Apabila pembayaran disimulasikan, pelanggan membuka sambungan SSE untuk mendengar kemas kini daripada pelayan. Ia mengendalikan status yang berbeza seperti belum selesai, dalam transit, berbayar dan gagal.

"use client";

import { useState } from "react";
import { PAYMENT_STATUSES } from "../utils/payment-statuses";

const paymentButtons = [
  {
    id: "pix",
    label: "Simulate payment with Pix",
    bg: "bg-green-200",
    success: true,
  },
  {
    id: "stripe",
    label: "Simulate payment with Stripe",
    bg: "bg-blue-200",
    success: true,
  },
  {
    id: "credit",
    label: "Simulate failing payment",
    bg: "bg-red-200",
    success: false,
  },
];

type transaction = {
  type: string;
  amount: number;
  success: boolean;
};

const DOMAIN_URL = process.env.NEXT_PUBLIC_DOMAIN_URL;

export function TransactionControl() {
  const [status, setStatus] = useState<string>("");
  const [isProcessing, setIsProcessing] = useState<boolean>(false);

  async function handleTransaction({ type, amount, success }: transaction) {
    setIsProcessing(true);
    setStatus("Payment is in progress...");

    const eventSource = new EventSource(
      `${DOMAIN_URL}/payment?type=${type}&amount=${amount}&success=${success}`
    );

    eventSource.onmessage = (e) => {
      const data = JSON.parse(e.data);
      const { status } = data;

      console.log(data);

      switch (status) {
        case PAYMENT_STATUSES.PENDING:
          setStatus("Payment is in progress...");
          break;
        case PAYMENT_STATUSES.IN_TRANSIT:
          setStatus("Payment is in transit...");
          break;
        case PAYMENT_STATUSES.PAID:
          setIsProcessing(false);
          setStatus("Payment completed!");
          eventSource.close();
          break;
        case PAYMENT_STATUSES.CANCELED:
          setIsProcessing(false);
          setStatus("Payment failed!");
          eventSource.close();
          break;
        default:
          setStatus("");
          setIsProcessing(false);
          eventSource.close();
          break;
      }
    };
  }

  return (
    <div>
      <div className="flex flex-col gap-3">
        {paymentButtons.map(({ id, label, bg, success }) => (
          <button
            key={id}
            className={`${bg} text-background rounded-full font-medium py-2 px-4
            disabled:brightness-50 disabled:opacity-50`}
            onClick={() =>
              handleTransaction({ type: id, amount: 101, success })
            }
            disabled={isProcessing}
          >
            {label}
          </button>
        ))}
      </div>

      {status && <div className="mt-4 text-lg font-medium">{status}</div>}
    </div>
  );
}

Bahagian Belakang: Pelaksanaan SSE dalam Next.js

Di bahagian pelayan, kami mensimulasikan proses pembayaran dengan menghantar kemas kini status berkala melalui SSE. Semasa transaksi berjalan, pelanggan akan menerima kemas kini sama ada pembayaran masih belum selesai, telah selesai atau telah gagal.

import { NextRequest, NextResponse } from "next/server";

import { PAYMENT_STATUSES } from "../utils/payment-statuses";

export const runtime = "edge";
export const dynamic = "force-dynamic";

// eslint-disable-next-line @typescript-eslint/no-unused-vars
export async function GET(req: NextRequest, res: NextResponse) {
  const { searchParams } = new URL(req.url as string);
  const type = searchParams.get("type") || null;
  const amount = parseFloat(searchParams.get("amount") || "0");
  const success = searchParams.get("success") === "true";

  if (!type || amount < 0) {
    return new Response(JSON.stringify({ error: "invalid transaction" }), {
      status: 400,
      headers: {
        "Content-Type": "application/json",
      },
    });
  }
  const responseStream = new TransformStream();
  const writer = responseStream.writable.getWriter();
  const encoder = new TextEncoder();
  let closed = false;

  function sendStatus(status: string) {
    writer.write(
      encoder.encode(`data: ${JSON.stringify({ status, type, amount })}\n\n`)
    );
  }

  // Payment gateway simulation
  async function processTransaction() {
    sendStatus(PAYMENT_STATUSES.PENDING);

    function simulateSuccess() {
      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.IN_TRANSIT);
        }
      }, 3000);

      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.PAID);

          // Close the stream and mark closed to prevent further writes
          writer.close();
          closed = true;
        }
      }, 6000);
    }

    function simulateFailure() {
      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.CANCELED);

          // Close the stream and mark closed to prevent further writes
          writer.close();
          closed = true;
        }
      }, 3000);
    }

    if (success === false) {
      simulateFailure();
      return;
    }

    simulateSuccess();
  }

  await processTransaction();

  // Return the SSE response
  return new Response(responseStream.readable, {
    headers: {
      "Access-Control-Allow-Origin": "*",
      Connection: "keep-alive",
      "X-Accel-Buffering": "no",
      "Content-Type": "text/event-stream; charset=utf-8",
      "Cache-Control": "no-cache, no-transform",
      "Content-Encoding": "none",
    },
  });
}

Selain itu, pastikan anda menambah fail .env.local dengan kandungan ini:

NEXT_PUBLIC_DOMAIN_URL='http://localhost:3000'

Mengapa SSE Over WebSockets dalam Kes Ini?

Sekarang kita telah melihat cara melaksanakannya, anda mungkin tertanya-tanya: mengapa menggunakan SSE melalui WebSockets untuk ini? Inilah sebabnya:

  • Komunikasi Sehala: Dalam senario kami, pelanggan hanya perlu menerima kemas kini tentang status pembayaran. Pelanggan tidak perlu menghantar data kembali ke pelayan secara berterusan, jadi kesederhanaan SSE sesuai dengan sempurna.
  • Ringan: Memandangkan SSE menggunakan sambungan HTTP tunggal untuk menstrim kemas kini, ia lebih cekap sumber berbanding WebSockets, yang mengekalkan komunikasi dupleks penuh.
  • Mesra Tembok Api: SSE lebih mudah digunakan merentasi persekitaran rangkaian yang berbeza kerana ia berjalan melalui HTTP, yang biasanya dibuka dalam tembok api, manakala sambungan WebSocket kadangkala boleh menghadapi masalah.
  • Sokongan Penyemak Imbas: Walaupun tidak disokong secara meluas seperti WebSockets, SSE disokong oleh penyemak imbas moden, menjadikannya boleh dipercayai untuk kebanyakan kes penggunaan yang memerlukan data satu arah.

Kesimpulan: Kenali Alat Anda

Soalan temu bual itu bertukar menjadi pengalaman pembelajaran yang luar biasa, membuka mata saya kepada perbezaan halus antara tinjauan panjang, tinjauan pendek, WebSockets dan SSE. Setiap kaedah mempunyai masa dan tempatnya, serta memahami masa untuk digunakan yang mana satu yang penting untuk mengoptimumkan komunikasi masa nyata.

SSE mungkin tidak begitu glamor seperti WebSockets, tetapi apabila ia berkaitan dengan komunikasi sehala yang cekap, ia adalah alat yang sesuai untuk tugas itu—sama seperti contoh pembayaran e-dagang kami. Lain kali anda membina sesuatu yang memerlukan kemas kini masa nyata, jangan hanya mencapai WebSockets secara lalai—pertimbangkan SSE untuk kesederhanaan dan kecekapannya.

Semoga menyelami teknik komunikasi masa nyata ini memastikan anda sentiasa tajam untuk projek seterusnya atau soalan temu duga yang rumit itu!


Jom kotorkan tangan kita

Repositori contoh Next.js + TypeScript: https://github.com/brinobruno/sse-next
Penerapan contoh Next.js + TypeScript: https://sse-next-one.vercel.app/

Rujukan

berikut ialah beberapa sumber dan rujukan berwibawa yang boleh anda terokai untuk mendapatkan pandangan yang lebih mendalam:

WebSockets Dan Dokumentasi SSE:

Dokumen Web MDN: API WebSockets
Dokumen Web MDN: Menggunakan Acara Dihantar Pelayan

Laluan API Seterusnya

Next.js: Laluan API


Jom sambung

Saya akan berkongsi sosial saya yang berkaitan sekiranya anda ingin menyambung:
Github
LinkedIn
Portfolio

Atas ialah kandungan terperinci Komunikasi Web Masa Nyata: Undian Panjang/Pendek, WebSockets dan SSE Explained + Next.js code. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn