오리 오리 이동 예

대규모로 관리하는 방법을 풀기 시작하기 위해 만든 첫 번째 예는 Duck Duck Go API에 대한 기본 호출이었습니다. 마이크로 프런트엔드를 작성할 때 다음 사항을 고려하는 것이 중요합니다.

다른 프로젝트에서 재사용할 수 있습니까, 아니면 일회용입니까? 재사용은 훌륭하지만 다른 사용 사례와 해당 사이트 내부에만 있는 것을 구상할 때 API 복잡성이 증가합니다.

이것은 시각적 구현입니까 아니면 비시각적 구현입니까? 너무 긴밀하게 결합되는 것을 피하기 위해 여러 가지 비시각적 구현으로 시각적 구현을 ​​만들어야 합니다.

사용자 입력을 받거나 시스템 질문에 답합니까? 사용자의 요청을 충족해야 합니까, 아니면 사용자가 버튼을 클릭하고 현재 페이지에서 데이터를 변경하여 답변을 형성해야 합니까?

중요한 서비스입니까 아니면 있으면 좋은 서비스입니까? 중요한 서비스(로그인 버튼) 또는 있으면 좋음(PDF 이 페이지), 어느 쪽이든 마이크로 서비스가 응답하지 않는 경우를 대비한 대체 계획이 있어야 합니다.

덕덕고

live example in storybook

frontend, tho purely example

backend code for vercel

프런트 엔드 구현에서 시작하여 백엔드로 돌아가 보겠습니다. 이것은 매우 예제 중심이므로 기본 양식 입력일 뿐입니다.

<div>
        <label>Duck duck go</label>
        <input type="text" id="search" />
        <button id="searchbtn">Search</button>
        <div id="ddgresult"></div>
      </div>

사용자가 검색어를 입력하면 검색 버튼의 클릭 이벤트를 통해 캡처합니다.

      this.shadowRoot
        .querySelector("#searchbtn")
        .addEventListener("click", () => {
          const params = {
            q: this.shadowRoot.querySelector("#search").value,
          };
          MicroFrontendRegistry.call("@core/duckDuckGo", params, this.ddgCallback.bind(this));
        });

그런 다음 MicroFrontendRegistry라는 추상화/프런트엔드 미들웨어 클래스를 호출합니다. 이를 위해 API를 구성하는 방법에 대해 다른 게시물을 작성하겠지만 아이디어는 끝점을 호출하는 대신 함수에 대한 개발자 이름을 호출하고 환경에서 실제 전체 주소를 알아내도록 하는 것입니다.
q 매개변수가 마이크로서비스로 전송된 후 엔드포인트의 응답 데이터로 ddgCallback가 실행됩니다.

마이크로서비스

Vercel은 익스프레스와 관련된 특정 구성 설정을 가정할 뿐만 아니라 모든 배포 마법을 처리합니다. 배운 몇 가지 교훈(백엔드 API 구조에서 다룸)과 결합하여 DDG 요청을 처리하기 위한 매우 깨끗한 끝점을 얻습니다.

// duckduckgo.js
// this is an example to fork from that uses common, simple conventions
// for getting data, validating data, and responding in a consistent way.
import { stdPostBody, stdResponse, invalidRequest } from "../../../utilities/requestHelpers.js";
import fetch from "node-fetch";
export default async function handler(req, res) {
  // destructing GET params after ? available in this object
  var { q } = req.query;
  // use this if POST data is what's being sent
  const body = stdPostBody(req);
  // fallback support for post
  if (!q && body && body.q) {
    q = body.q;
  }
  // need to know what we're searching for otherwise bail
  if (q) {
    // we import fetch just to simplify endpoint creation but its just node-fetch
    const searchResults = await fetch(`http://api.duckduckgo.com/?q=${q}&format=json`).then((d) => d.ok ? d.json(): {});
    // standard response is how all transactions end
    // this will assume 200 response code unless defined otherwise
    // response data is passed in as searchResults here
    // if type is not set in the options, then it is assumed JSON response
    // and is added to a data param
    res = stdResponse(res, searchResults, {cache: 86400, methods: "OPTIONS, POST" });
  }
  else {
    // invalidate the response and provide a reason
    // this optionally takes in a status code otherwise default is 400
    // vercel will through a 500 if there was any bricking issue so we don't
    // need to throw that most likely
    res = invalidRequest(res, 'missing `q` param');
  }
}

여기서 우리는 duck duck go API로 보내기 전에 간단한 입력 유효성 검사를 가져오는 것을 볼 수 있습니다. stdResponse 그런 다음 JSON 데이터를 가져와 프런트 엔드로 다시 보내기 전에 적절한 응답을 설정합니다. 위의 내용은 잘 문서화되어 있으므로 진행 상황을 읽어보지만 res 및 req 작업에 대한 사소한 추상화로 매우 간단합니다.

결과 표시 시간

따라서 백엔드가 이 JSON Blob을 다시 보내면 프런트엔드Promise가 ddgCallback에서 확인되고 반환된 data로 실행됩니다.

ddgCallback(data) {
    console.log(data.data.RelatedTopics);
    this.shadowRoot.querySelector("#ddgresult").innerHTML = 
    `<code><pre>
    ${JSON.stringify(data.data.RelatedTopics, null, 4)}
    </pre></code>`;
  }

여기에서 문자열화된 버전을 페이지에 간단히 인쇄하는 것을 볼 수 있습니다.

이것은 내 건물의 여러 건물에서 마이크로프론트엔드와 함께 나타나는 다소 단순한 패턴입니다.

입력 있음

표준 방식으로 전화 걸기(Promise 원하는 대로 async/await)

표준 방식으로 호출 받기, 표준 방식으로 데이터 반환( json w/data param)

표시/입력에 반응

이제 간단한 예제가 있으므로 웹 서비스 호출을 단일 회선 호출로 요약하기 위해 작성한 프런트 엔드 추상화로 들어가 보겠습니다.