단일 페이지 애플리케이션 또는 모바일 애플리케이션을 빌드 할 때 일반적으로 프런트 엔드와 백엔드를 연결하기 위해 웹 API (REST, GraphQL 등)를 구현해야 합니다. 기술적으로는 그리 어렵지 않지만 불행한 결과가 있습니다.
두 개의 행성을 상상해보십시오. "frontend"행성은 JavaScript를 사용하고 "backend"행성은 JavaScript 또는 기타 고급 언어를 사용합니다.
이제 이 행성들이 "응용 프로그램"이라는 전체를 형성하기 위해 광범위하게 협력해야 한다고 가정 해 보겠습니다.
안타깝게도 행성은 모국어를 사용하여 서로 직접 통신 할 수 없으며 훨씬 덜 정교한 언어를 사용하는 "웹 API"라는 타사에 의존해야 합니다.
실제로 대부분의 웹 API의 언어는 URL, 몇 가지 HTTP 동사 (GET, POST, DELETE 등) 및 일부 JSON의 조합으로 제한됩니다.
GraphQL을 사용하는 웹 API는 더 발전되었지만 JavaScript와 같은 프로그래밍 언어의 가능성보다 훨씬 뒤떨어져 있습니다.
프론트 엔드와 백엔드 사이에 기초적인 언어를 배치하면 많은 상용구가 추가되고 개발 경험이 망가집니다.
또 다른 문제는 웹 API가 걱정할 추가 레이어라는 것입니다. 그것은 설계, 구현, 테스트, 문서화 등을 거쳐야 합니다. 그리고 이 모든 것은 솔직히 엉덩이에 고통입니다.
그러나 가장 나쁜 것은 웹 API를 구축하면 일반적으로 코드베이스의 품질이 저하된다는 것입니다. 실제로 프런트 엔드와 백엔드가 웹 API로 분리되어있을 때 코드를 건조하고 일관성 있게 유지하는 것은 매우 어렵습니다.
이제 웹 API를 제거 할 수 있다고 상상해보십시오. 프런트 엔드가 모국어를 사용하여 백엔드와 직접 통신 할 수 있다고 상상해보십시오. 대단하지 않을까요?
좋은 소식은 Layr라는 라이브러리 세트 덕분에 오늘날 가능하다는 것입니다.
https://dev.to/mvila/good-bye-web-apis-2bel
안녕, 레이어!
Layr를 사용하면 프런트 엔드와 백엔드가 물리적으로 분리되어 있지만 (다른 환경에서 실행 됨) 논리적으로 재결합됩니다 (동일한 환경에 있는 것처럼).
어떻게 작동합니까?
내부적으로 Layr는 RPC 메커니즘에 의존합니다. 따라서 표면적으로는 CORBA, Java RMI 또는 .NET CWF와 같은 것으로 볼 수 있습니다.
그러나 Layr는 근본적으로 다릅니다.
Layr는 JavaScript / TypeScript로 여정을 시작하지만, 해결하는 문제는 보편적이며 모든 객체 지향 언어로 이식 될 수 있습니다.
예
Layer를 사용하여 전체 스택 애플리케이션을 빌드 하는 것이 어떻게 보이는지 확인하기 위해 고전적인 "Counter"예제를 구현해 보겠습니다.
먼저 백엔드에서 "데이터 모델"과 "비즈니스 로직"을 구현합니다.
// backend.js
import {
Component,
primaryIdentifier,
attribute,
method,
expose
} from '@layr/component';
import {ComponentHTTPServer} from '@layr/component-http-server';
class Counter extends Component {
// We need a primary identifier so a Counter instance
// can be transported between the frontend and the backend
// while keeping it's identity
@expose({get: true, set: true}) @primaryIdentifier() id;
// The counter value is exposed to the frontend
@expose({get: true, set: true}) @attribute() value = 0;
// And the "business logic" is exposed as well
@expose({call: true}) @method() increment() {
this.value++;
}
}
// Lastly, we serve the Counter class through an HTTP server
const server = new ComponentHTTPServer(Counter, {port: 3210});
server.start();어머! 간단한 "카운터"예제를 위한 모든 코드? 물론 과도하게 보이지만 실제로는 데이터 모델, 일부 비즈니스 로직 및 모든 것을 노출하는 HTTP 서버로 풀 그레이드 백엔드를 구현했습니다.
이제 백엔드가 있으므로 프런트 엔드에서 사용할 수 있습니다.
// frontend.js
import {ComponentHTTPClient} from '@layr/component-http-client';
(async () => {
// We create a client to connect to the backend server
const client = new ComponentHTTPClient('http://localhost:3210');
// We get a proxy to the Counter backend class
const Counter = await client.getComponent();
// Lastly, we consume the Counter
const counter = new Counter();
console.log(counter.value); // => 0
await counter.increment();
console.log(counter.value); // => 1
await counter.increment();
console.log(counter.value); // => 2
})();여기서 무슨 일이 일어나고 있습니까? counter.increment() 메서드를 호출하면 카운터 값이 증가합니다. 이 메서드는 프런트 엔드에 존재하지 않습니다. 백엔드에서 구현되므로 이 환경에서 실행됩니다. 그러나 프런트 엔드의 관점에서 실제 실행 환경은 중요하지 않습니다. 메소드가 원격으로 실행된다는 사실은 구현 세부 사항으로 볼 수 있습니다.
프런트 엔드의 Counter 클래스를 확장하여 프런트 엔드와 관련된 기능을 구현할 수 있습니다. 다음은 카운터가 특정 값에 도달 할 때 메시지를 표시하도록 increment() 메서드를 재정의 하는 방법의 예입니다.
class ExtendedCounter extends Counter {
async increment() {
// We call the `increment()` method in the backend
await super.increment();
// We execute some additional code in the frontend
if (this.value === 3)
console.log('The counter value is 3');
}
}
}이것이 프론트 엔드와 백엔드가 재결합했을 때의 모습입니다. 꽤 멋지지 않나요?
캐치는 무엇입니까?
웹 API 없이도 모든 사람이 웹 API를 구축하는 이유는 무엇입니까?
웹 API를 구현해야 하는 한 가지 좋은 이유는 REST와 같은 확립 된 프로토콜을 통해 일부 외부 개발자에게 백엔드를 노출하려는 경우입니다. 하지만 솔직히 말해서 대부분의 응용 프로그램에는 이러한 요구 사항이 없습니다. 웹 API가 필요한 것으로 판명되면 모든 내부 요구에 대해 "API 없는"접근 방식을 계속 사용하면서 나중에 추가 할 수 있습니다.
또 다른 이유는 수백만 명의 사용자가 있는 대규모 애플리케이션에서 작업하는 경우입니다. 실제로 Layr가 제공하는 편리함은 비용 없이 제공되지 않으므로 가능한 가장 최적화 된 응용 프로그램을 원한다면 하위 수준의 솔루션을 사용하는 것이 좋습니다.
마지막으로 JavaScript 이외의 언어로 프런트 엔드 또는 백엔드를 구현하려는 경우 스택의 한쪽에서 Layr를 계속 사용할 수 있지만 그런 다음 Deepr 프로토콜을 말할 수 있는 API 클라이언트 또는 서버를 구현해야 합니다. 스택의 다른 쪽.
결론
웹 API를 제거하면 코드베이스의 품질을 높이면서 풀 스택 애플리케이션을 훨씬 빠르게 빌드 할 수 있습니다.
일부 프로덕션 프로젝트를 포함하여 여러 프로젝트에 Layr를 사용하여 코드 양을 평균 50 % 줄이고 생산성을 크게 높일 수 있었습니다.
또 다른 중요한 측면은 개발 경험입니다. 프론트 엔드와 백엔드가 더 이상 웹 API로 분리되지 않기 때문에 독립형 애플리케이션을 개발하는 것과 비슷한 느낌을 받고 훨씬 더 재미 있습니다.
등록된 댓글이 없습니다.
