몇 개월 간의 오픈 소스: 차세대 요청 도구를 유지 관리하는 방법

2년 전 저는 alovajs라는 JavaScript 요청 전략 라이브러리를 설계하고 개발했습니다. 2023년 4월 프로모션 이후 전 세계 개발자들로부터 호평을 받았으며, 주요 기업 전문가들의 인정을 포함해 2700개 이상의 별을 획득했습니다.

현재 alova@3.x가 출시되어 "간단한 작업 흐름을 위한 차세대 요청 도구"로 자리매김했습니다.

30개월 동안 무보상으로 유지하고 있는데 버전이 3.x가 되었습니다. 이 기간 동안 저는 끊임없는 반성과 거부, 재검토를 통해 다른 요청 도구가 하지 못한 일을 성취하고, 프론트엔드 개발에 진정으로 도움이 될 수 있는 도구가 되는 것을 목표로 삼았습니다. 확실한 방향을 찾았다고 봅니다.

즉, API 통합 프로세스를 간소화하여 프런트 엔드 개발에 대한 지원을 극대화하는 "간단한 워크플로를 위한 차세대 요청 도구"를 만드는 것입니다.

아래는 오픈소스 프로젝트의 시작부터 이야기이기도 한 alovajs의 탐험 이야기입니다.

Alovajs에 관심이 있으신 분들은 커뮤니티에 가입하셔서 함께 발전해 나가시기를 진심으로 바랍니다.

• Discord 커뮤니티에 참여하세요

alovajs는 소규모 프로젝트에서 시작되었지만 그 사명은 바다를 항해하는 것입니다.

2022년 3월의 어느 날, 어떤 사정으로 인해 '골의 콘'이라는 앱을 개발하겠다는 생각이 떠올랐습니다. 일부 앱에서 영감을 받아 "Con of goal"이 지연 없는 데이터 요청 및 제출, 즉 네트워크 상태가 약하거나 없는 경우에도 즉각적인 응답 모드를 달성할 수 있기를 바랐습니다. 그러나 온라인으로 검색했지만 적합한 솔루션을 찾지 못했고 유사한 낙관적 업데이트 솔루션이 요구 사항을 충족하지 못한 후 공유하고 싶은 염원으로 인해 alovajs의 출발점인 요청 라이브러리 형식으로 구현하기로 결정했습니다. 그런데 당시에는 이름이 없었어요.

alovajs 디자인하기

도서관의 시작은 디자인이나 개발이 아닌 요구사항을 명확히 하는 것입니다

프로 팁: 다음 내용을 더 잘 이해하려면 먼저 alovajs의 개요 섹션을 간략하게 이해하는 것이 좋습니다.

당시에는 제품 포지셔닝이 없었고 내 필요에 맞게 JavaScript 라이브러리를 만들었습니다. 기존 요청 라이브러리를 연구하고 다음 요구 사항을 나열했습니다.

1. 원활한 데이터 상호 작용 모드 지원, 즉 네트워크 연결이 끊어진 경우에도 사용자가 인식하지 않고도 지체 없이 제출할 수 있습니다
2. 당시 인기 있는 Hook에 맞게 디자인하여 인터페이스를 더욱 사용자 친화적으로 만들었습니다
3. 코드 세트는 Vue, React 등의 여러 프레임워크와 브라우저, React Native, UniApp, Taro 등의 JavaScript 운영 환경을 지원합니다.
4. 여러 JavaScript 환경에서 일관되게 사용
5. 리액트 쿼리의 캐싱 기능이 매우 좋다는 점을 고려하면 이것도 추가해야겠습니다
6. Axios의 영향력과 단순성으로 인해 alovajs를 시작하기 쉽게 만들고 디자인도 axios와 유사해야 합니다

그런 다음 필요에 따라 라이브러리의 API를 설계했습니다.

• Needs 1의 경우, 알로바J를 시작하게 된 계기가 되었지만 쉽지는 않았습니다. 당시 설계는 성공 콜백에 즉시 응답할 수 있는 useHook 구성에 자동 매개변수를 추가하는 것이었지만 나중에 문제가 있음이 입증되어 다시 설계되어 이제는 원활한 데이터 상호작용 전략이 되었습니다

• 필요 2를 위해 세 가지 핵심 useHook, 즉 useRequest, useWatcher 및 useFetcher가 설계되었습니다. ahooks의 useRequest, vueuse의 useAsyncState, React-query, swr 등 누구에게나 익숙한 기능인데, 말할 필요도 없이 매우 편리합니다.

• useHook 디자인을 사용하기 때문에 프레임워크마다 상태 관리가 다르지만, 반응 쿼리처럼 프레임워크마다 JavaScript 라이브러리를 만들고 싶지는 않습니다. 따라서 Needs 3에 대해서는 StateHook 어댑터, 요청 어댑터, 스토리지 어댑터에 대한 사양을 설계하고 사양에 따라 서로 다른 어댑터를 작성하여 프레임워크 환경과 런타임 환경 관련 로직을 별도의 모듈로 분리할 수 있습니다.

• 니즈 4에 대해서는 메소드 인스턴스 프록시 패턴을 설계하였고, 메소드 인스턴스 프록시는 서로 다른 어댑터의 Hook 기능을 호출하므로 어떤 애플리케이션을 개발하더라도 낯설지 않게 alovajs를 시작할 수 있고, 이식도 원활하게 가능합니다.

• 필요 5의 경우 유사한 JavaScript 라이브러리가 사용자 정의 키 형태로 캐싱을 구현하지만 내 생각은 요청 정보에 집중하는 것입니다. 일반적인 시나리오는 동일한 요청 방법과 매개변수로 동일한 인터페이스를 요청할 때 마지막 응답 데이터를 적중해야 하는 것입니다. 이러한 요청 정보를 캐싱 키로 사용하면 어떨까요? 따라서 alovajs는 GET 요청 시 기본적으로 활성화되는 자동 캐싱 메커니즘을 설계했습니다.

• 필요6에 대해서는 Axios를 참고하고 배우세요.

이러한 디자인은 실제로 시간이 지남에 따라 입증되었습니다. alovajs는 어댑터 방식을 통해 Vue, React, Svelte 프레임워크와 완벽하게 호환되며, 일관된 사용 방식을 유지하면서 브라우저, React Native, UniApp, Taro 등 다양한 JavaScript 환경에서도 실행할 수 있다는 점이 조금은 아쉬웠습니다. 바랍니다.

이후 몇 달 동안 alovajs가 출시되었지만 홍보가 이루어지지 않았습니다. 한편으로는 "Con of goal" 프로젝트에서 사용했기 때문입니다. 이번 프로젝트에서는 완화되고 개선되었지만 여전히 매우 불완전하고 포지셔닝이 명확하지 않습니다. 초기 버전 소개는 이렇습니다.

나중에 'Con of goal' 프로젝트는 중단됐지만, alovajs는 여전히 지속되고 있습니다.

alovajs의 방향 탐색

한때 인터넷 제품 관리자였다는 집착으로, 여전히 알로바즈를 차별화된 제품으로 만들고 싶습니다. 나는 종종 스스로에게 질문합니다. alovajs와 다른 요청 라이브러리의 차이점은 무엇입니까? 사용자가 alovajs를 사용해야 하는 이유는 무엇입니까? 디자인 면에서 다른 라이브러리와 확실히 다른 점은 바로 대답할 수 있는 질문이 아닙니다. 나중에 요청 라이브러리의 방향을 '경량 요청 라이브러리'와 '멀티엔드 통합 요청 라이브러리'로 포지셔닝하려고 했지만 개발자에게 실질적인 도움을 줄 수 없고 개발자에게 실질적인 도움을 줄 수 없기 때문에 모두 스스로 거부했습니다. 장점이라고 할 수 있습니다.

2022년 9월, Vue, vue-request 기반의 훌륭한 요청 라이브러리를 발견한 기회가 있었습니다. usePagination과 useLoadMore는 나에게 즉시 영감을 주었습니다. 이러한 형태의 페이지 매김 구현을 통해 이것이 바로 내가 원하는 것임을 깨달았습니다. 동시에 useHook의 위력을 깨닫게 해주었습니다. 요청 시나리오에 따라 모듈을 나누고 시나리오마다 다른 useHook을 사용할 수 있으며 이전에 구현한 원활한 데이터 상호 작용은 실제로 시나리오 중 하나입니다. 이것이 방향이라면 개발자는 다양한 요청 시나리오에 따라 다양한 useHooks를 선택할 수 있습니다. 이는 개발 효율성을 높이고 코딩 복잡성을 줄일 뿐만 아니라 주니어 프런트 엔드가 비효율적인 코드를 작성하는 것을 방지하고 핵심 기능을 더 잘 활용할 수 있습니다. alovajs는 더 나은 성능과 더 적은 서버 부담을 달성합니다. 요청 기능은 지금까지 제가 선택한 "경량 요청 전략 라이브러리"입니다.

그리고 alovajs의 향후 디자인 방향을 안내하기 위해 alovajs의 요청 시나리오 모델(RSM)도 다듬고 추상화했으며, 주로 다음 4가지 프로세스로 구분됩니다.

Request timing -> Request behavior -> Request event -> Response processing

해보자, 나는 이 포지셔닝에 따라 alovajs 2.0을 재구성하기 시작했고, 1.0에서 원활한 데이터 상호작용 기능을 분리했으며, 더 많은 요청 시나리오 전략 useHooks의 개발에 적응할 수 있는 미들웨어 메커니즘을 설계했으며, 페이지네이션 전략과 원활한 데이터 상호작용 전략을 연구하고 개발했습니다.

• alovajs의 pagination 전략은 제가 생각하는 가장 유용한 사용법이라고 생각합니다. alovajs의 캐싱 기능을 사용하여 앞 페이지 및 뒷 페이지 데이터 사전 로드, 페이지 매김 데이터 검색, 요청 수준 디바운싱을 수행하고, 새로운 편집 및 삭제 기능의 자동화된 관리와 지정된 페이지 코드의 데이터 새로 고침을 제공합니다. 재설정하지 않고.

• 원활한 데이터 상호작용 전략을 세우는 데 4개월이 걸렸고, 끊임없이 막다른 골목에 부딪히고 끊임없이 결과를 재설계했습니다. 네트워크가 약하거나 단절된 환경에서도 사용자가 지연 없이 데이터와 상호 작용할 수 있도록 하는 전략을 달성했으며, 요청의 성공도 보다 안정적으로 보장할 수 있습니다. 나는 응답 전 응답 데이터의 자리 표시자로 사용할 수 있는 가상 데이터 사물을 설계하여 사용자가 즉각적인 응답임을 느끼게 하고, 응답이 성공한 후에는 가상 데이터를 실제 데이터로 대체합니다. 현재 탐색 결과에 따르면 사용 시나리오는 편집기와 유사한 애플리케이션, 시스템 설정 모듈 및 일부 간단한 목록이 될 수 있습니다.

나중에 useForm, useAutoRequest, useSSE 등의 요청 전략 모듈도 추가했지만 이것만으로는 부족합니다.

차세대 요청 도구의 아이디어

2023년 5월 13일 github에서 이런 문제를 받았습니다

처음에는 이 문제에 크게 관심을 두지 않고 단순히 openAPI의 요청 코드 자동 생성 기능만 이해하고 아주 좋다고 생각했는데 에너지가 부족해서 깊이 생각하지 못했습니다. 그 당시에는 alovajs의 방향에 대해 생각하지 않았습니다. 그런데 최근에는 alovajs의 방향에 대해 가끔 생각하게 되었는데, 아직까지 미해결 상태인 이 이슈가 늘 생각나다가 조용히 이 이슈의 라벨을 "feature-request"에서 "feature-request:confirmed"로 바꿨습니다. .

동시에 이 문제를 통해 저는 alovajs가 프런트엔드와 백엔드 간의 협업 거리를 좁히고 프런트엔드 개발 워크플로를 더욱 단순화할 수도 있다는 것을 깨달았습니다. 이것이 제가 alovajs 3.0을 위해 설정한 개발 방향입니다:

alovajs는 개발자가 API 통합 워크플로를 최대한 단순화하는 데 도움이 되며, 사용할 API만 지정하면 됩니다(이 역시 3개월 동안 고민한 결과입니다)

구체적인 계획은 다음과 같습니다.

1. 위 그림의 1, 2, 3, 4, 6단계는 API 코드를 자동 생성하여 해결되지만, 우리의 생성 계획은 openapi-generator와 같은 도구에 비해 더 발전할 것입니다. js 프로젝트이든 ts 프로젝트이든 관계없이 완전한 ts 유형, 완전한 설명 요청 기능을 자동으로 생성하므로 소개할 필요가 없으며 개발자가 location.reload를 직접 호출하는 것처럼 편리하게 호출할 수 있으며 요청 기능은 직접 볼 수 있습니다. 전체 설명 및 요청 매개변수 유형 프롬프트가 표시됩니다.

2. 자동으로 생성된 요청 함수에는 완전한 설명과 유형 프롬프트가 있으므로 vscode 플러그인은 필요한 API를 신속하게 검색하는 대화형 방식을 완성하므로 더 이상 API 문서를 참조할 필요가 없습니다.

3. 프런트엔드와 백엔드 협업 격차 문제를 해결하고, 인터페이스 변경 사항이 자동으로 프런트엔드에 통보됩니다. 프로젝트 구축 중에 변경 사항이 발견되면 오류가 발생하여 구축을 중지합니다. TS 프로젝트인 경우 컴파일 시에도 오류가 발생하며, 변경 기록은 vscode 플러그인을 통해서도 볼 수 있습니다.

vscode 확장 기능의 데모 영상입니다.

6단계 "복잡한 요청 로직 작성"을 해결하는 방법은 무엇입니까? 물론 고성능, 장면 기반의 특성을 지닌 요청 전략 모듈을 사용하기 위함이며, 사용자는 아주 적은 양의 코드로도 다양한 장면 요청 기능을 구현할 수 있습니다.

2024년 3월 alova@3.0의 개발 계획이 수립되었으며, 핵심 멤버인 MeetinaXD를 포함하여 거의 전체 프로젝트를 재구성하는 데 4개월이 걸렸으며 많은 최적화가 이루어졌습니다.

1. 기본 아키텍처가 재설계되었으며 Vue, React, Svelte는 물론 Vue 옵션 스타일에서도 후크 세트를 동시에 사용할 수 있습니다.

2. 서버측으로 사용 가능 범위가 늘어났습니다. express, koa, Nestjs 등의 서버사이드 프레임워크에서 alova를 사용할 수 있으며 새로운 서버사이드 요청 전략 서버 후크가 추가되었습니다.

3. alova@2.x의 10가지 구성이 더 이상 사용되지 않으며 9가지 디자인이 최적화되었습니다.

또한 3.0의 가장 중요한 부분인 핵심 멤버인 czlin을 담당하는 vscode 플러그인도 사용할 수 있으며 기본적으로 처음에 설정한 목표를 달성했습니다.

현재 alova@3.0은 베타기간을 통과하여 프로덕션 환경에서 안정적으로 사용이 가능합니다.

지속적인 탐구를 통해서만 우리는 더 나아질 수 있습니다

당시 '당신의 액시오스를 교체할 때가 됐다'는 비판을 받은 기사가 화제가 되기도 했습니다.

사실 막 출시됐을 때는 그다지 좋지 않았지만, 모든 제품이 하루아침에 이루어지지 않고, 침전하는 데 시간이 필요하다는 것을 알고 있습니다.

애플1 컴퓨터는 처음에는 케이스도 없었어요

Vue의 개발 여정은 지속적인 탐구와 발전의 과정이기도 합니다

저는 그런 제품 여정에 감동받았고, 한 가지 일을 꾸준히 하는 것이 성공하는 가장 쉬운 방법입니다. 좋은 제품은 수년간 테스트를 거쳐야 하는데, 출시된 지 1년 반 정도 밖에 안 됐고, 일부 사람들에게 연락을 받은 지 8개월 정도 된 알로바즈는 말할 것도 없다. 이 기간 동안 더 나은 솔루션을 모색하고 단계별로 발전해 왔습니다.

alovajs는 처음에 useRequest, useWatcher, useEffectWatcher, useManual, useController를 포함하는 useHook를 설계했지만 점차적으로 useRequest, useWatcher 및 useFetcher의 세 가지 핵심 후크로 축소되었습니다.

커밋 주소

병렬 요청의 설계에 있어서 Promise.all과 유사한 형태를 구현할 것인지, 아니면 현재 onSuccess 함수에 바인딩하는 형태를 할 것인지 여러 버전에 얽매이고 왔다 갔다 하며 다음과 같습니다. 그해의 버려진 응답기 디자인.

커밋 기록을 찾을 수 없습니다

IndexedDB와 같은 비동기 캐싱 방식과 호환되기 위해 처음에는 스토리지 어댑터를 비동기 기능으로 설계하려고 했으나 여러 가지 문제가 발생했고 이후 StorageConnector를 통해 이벤트 메커니즘을 구현하려고 했습니다. 아직은 완벽하지 않으며, 마침내 현재의 사용자 정의 localCache 비동기 함수 메커니즘이 탄생했습니다.

커밋 주소

또한 alovajs를 지지하고 기여해준 친구들에게도 감사드립니다. 다음은 몇 가지 스크린샷이며, 포함되지 않은 기여가 많습니다.

그리고 문서의 세부 사항을 지속적으로 보완하고 모범 사례를 개선하고, 캐시 복구 모드에 대한 캐시 버전 계획을 과감하게 시도하고, alovajs에 대한 완전한 ts 유형 프롬프트를 제공하기 위해 자동 유형 추론을 사용하여 개발자가 유형을 정의하는 데 어려움을 겪고 실제로 다양한 UI 프레임워크 등과의 최적화 및 호환을 위해 많은 노력을 기울입니다.

그 중 문서가 2~3번 크게 바뀌었습니다. 첫 번째 문서 수정 의견을 주신 @Orange Peel 님께 감사드리고, 두 번째 문서 수정 의견을 주신 @Well 님께 감사드리며, 저희 문서가 이런 평판을 얻고 있습니다.

@green tree는 제가 알로바에 대한 새로운 아이디어를 열 수 있게 도와주었습니다.

많은 것들이 더 이상 명확하지 않으며, npmjs의 기록에 따르면 146개 버전이 출시되었다고 합니다.

깃허브에도 버그를 제기하는 분들이 많이 계시는데, 저도 처음으로 답변하고 수정해 드렸습니다. 정말 감사해요. 문제를 바로 판단할 수 없다면 코드샌드박스에서도 재현해 보고, 이 데모를 유저들과의 소통의 가교로 활용하겠습니다.

끝

읽어 주셔서 정말 감사합니다. 아무리 어려워도 길은 계속되어야 합니다.

Alovajs를 알아보셨다면 Github에 가서 별표를 주세요.

알로바를 이해하고 싶다면 공식 웹사이트를 방문하세요. 여기서는 이 도구를 더 잘 이해하고 사용하는 데 도움이 되는 자세한 문서와 예제 코드를 찾을 수 있습니다.

질문이 있는 경우 다음 그룹 채팅에 참여하여 상담을 ​​받거나 github 저장소에 토론을 게시할 수도 있습니다. 문제가 발생하는 경우 github 이슈에 제출해 주시면 가장 빠른 시간에 해결해 드리겠습니다.

• Discord 커뮤니티에 참여하세요

여러분의 힘찬 기여를 환영합니다. 기여 가이드를 확인하세요.

위 내용은 몇 개월 간의 오픈 소스: 차세대 요청 도구를 유지 관리하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!