새소식

TIL

[TIL] 240419 웹 기초

  • -

 

웹 서비스

  • 웹에서 제공되는 서비스
  • 웹 서비스 개발자 : 웹 서비스를 설계/제작/관리
  • AWS,Vercel, Netlify 등

 

  • 웹 서비스의 동작
    • 클라이언트 (요청하는 주체) : 사용자브라우저라는 매개를 이용하여 서버에 어떠한 것을 요청
    • 서버(요청받는) : 요청에 대한 처리응답을 줌 
      •   
        [출처] https://mannhowie.com/rest-api
      • 요청 → http(서로 약속된 상호작용 방법) 안에서 url + method(GET,POST,PUT,PATCH,DELETE)로 하는 것





  •  예시)
  • <클라이언트> : 네이버 접속 후 '사전' 글자 클릭 → url + method(GET)으로 요청
<button onclick="sendRequest()">사전</button>

<script>
function sendRequest() {
    fetch("https://example.com/dictionary", {
        method: "GET"
    })
    .then(response => response.json())
    .then(data => {
        console.log(data);
    })
    .catch(error => {
        console.error("Error fetching data:", error);
    });
}
</script>

 

  • <서버> : 요청을 받아 처리 준비 (spring 예시)
package com.example.demo;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

// 어노테이션을 이용해 명시
// @RestController: 해당 클래스가 RESTful 웹 서비스의 컨트롤러 역할을 하는 클래스임을 나타냅니다.
// @GetMapping: 해당 메서드가 GET 요청을 처리하는 메서드임을 나타냅니다.

@RestController
public class DictionaryController {

    @GetMapping("/dictionary")
    public String getDictionary() {
        return "사전 페이지 입니다.";
    }
}

 

 

 


 

웹 서버 (프론트엔드 + 백엔드)

(우리가 만드는 것은 웹서비스 제공을 위한 웹서버!!!)

 

>> 주요 기능 : (정적)페이지 제공, API 제공 등등

 


1. API (Application Programming Interface)

 - 여러 소프트웨어 간 정보나 기능을 공유하게 해주는 중간 매개체로 일종의 규약
 - 한 프로그램이 다른 프로그램의 기능 사용 및 정보 가져오기 가능
 - 클라이언트의 요청에 따라 "동적으로" 데이터나 정보 제공
 
- 주로 JSON이나 XML 형식으로 응답 반환

 

   (1) RESTFul API : 많이 사용되는 전통적 방식

     - 웹 서비스에서 사용하는 API 설계 방법

     - [리소스를 URL], [처리종류를 HTTP메서드]를 통해 표현
     - XML, JSON 형태로 데이터 주고 받음

 

   (2) GraphQL API : 복잡한 데이터 요구사항을 효과적으로 처리가능한 현대적 방식

     - API 쿼리 언어
     - 클라이언트가 필요로 하는 데이터 형태와 구조 요청

     - 서버가 그에 따른 데이터를 상세히 반환
     - 오버페칭 + 언더페칭 해결 

 

 

 

2. (정적) 페이지 제공

(express.js 예시)

// public/index.html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Express Static Page</title>
</head>
<body>
    <h1>Welcome to Express!</h1>
</body>
</html>

 

const express = require('express');
const app = express();
const PORT = 3000;

// 정적 파일 제공
app.use(express.static('public'));

app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

 

 

 

 

 

프론트엔드

- 사용자가 웹사이트에서 직접 보고 상호작용하는 부분

- 웹 페이지의 디자인, 버튼 클릭, 입력 폼 등 사용자 인터페이스(ui)와 관련된 모든 것

 

백엔드

- 서버, 데이터베이스, 어플리케이션 로직 등 사용자의 눈에 안보이는 부분 관리

- 사용자가 웹사이트에서 정보 요청 시, 해당 정보를 처리하거나 db에서 가져와 프론트엔드에 전달

 

 

  프론트엔드와 백엔드를
각각 구성하여 각각 배포하는 방법
→ 웹서버 2개
프론트엔드와 백엔드를
동시에 구성하는 방법
in 웹서버 1개
백엔드만 구성하여
배포하는 방법
→ 웹서버 1개
프론트엔드만 구성하여
배포하는 방법

→ 웹서버 1개
설명 - 리액트 프로젝트 만들어
  Vercel 등에 별도 배포
- 스프링/노드 프로젝트 만들어
   ec2 등으로 별도 배포
프로젝트 디렉토리(폴더) 안에 리액트와 스프링/노드 폴더가 각각 존재하여 한번 배포, 끝! 백엔드에서 정적 페이지와 API 함께 제공 프론트엔드만 배포하여 서비스
특징 - 페이지 전달 → 리액트
- API 제공 → 스프링/노드
- 페이지 전달 → 리액트
- API 제공 → 스프링/노드
- 페이지 전달 → 스프링/노드
- API 제공 → 스프링/노드-express/nest
 페이지 전달 → 리액트
- API 제공 → 없거나 next 사용
장점 - FE와 BE를 독립적으로 스케일 아웃 가능
- 한쪽에 문제가 발생해도 다른쪽에 영향 X
- 배포 및 관리 간단
- 네트워크 통신 오버헤드가 없거나 적음
- FE의 별도배포 필요X
- 설정 및 관리 비교적 간단
- 백엔드 없이 순수한 클라이언트 사이드 렌더링 활용 가능
- FE 리소스만 관리하면 되므로 간단한 웹사이트나 앱에 적합
단점 - 배포 및 관리 복잡
- FE와 BE 간 통신 오버헤드 발생 가능성
- FE와 BE가 동일한 리소스 공유하여 성능 이슈 발생 가능성
- 스케일 아웃의 어려움
- 모던 프론트엔드 프레임워크의 이점 제대로 활용 어려울 수도.
- BE 리소스가 정적 페이지 제공에도 사용되므로 퍼포먼스 이슈 발생 가능성
- 데이터 처리나 복잡한 기능 구현 위해 별도의 BE 서비스 필요
- SEO 최적화를 위해 서버 사이드 렌더링 필요 시 별도의 설정 및 구성 필요
예시 전자 상거래 웹사이트 :
React로 제작된 프론트엔드 웹사이트와
Express로 구축된 백엔드 API 서버.
사용자는 React 웹사이트를 통해 상품을 검색하고, 주문하며,
Express 백엔드는 상품 데이터나 주문 처리와 같은 서비스를 제공합니다.
블로그 시스템 :
스프링 백엔드에 React로 작성된 프론트엔드를 결합하여 하나의 웹 서버에서 작동하게 하는 블로그 시스템.
React는 블로그 포스트를 표시하는 프론트엔드,
스프링은 데이터베이스에서 포스트를 가져오는 백엔드 역할.
간단한 회사 홈페이지 :
스프링 프레임워크를 사용하여 회사 소개, 연락처, 서비스 정보 등의 정적 페이지와 함께 간단한 문의 폼을 제공하는 웹사이트.
모든 페이지는 스프링의 JSP 기능을 통해 제공.
포트폴리오 웹사이트 :
개인의 스킬과 경험을 소개하는 포트폴리오 웹사이트.
React로 작성되었으며, GitHub Pages나 Netlify와 같은 정적 사이트 호스팅 서비스를 사용하여 배포.
데이터는 공개 API나 정적 데이터 파일을 사용하여 가져옴.

 

 

 

 

현재 대한민국의 개발 환경

 

  • 다양한 백엔드 아키텍처
    • Monolithic에서 Microservices로의 전환
    • 서버리스 아키텍처, 그래프QL 등 등장
  • 풀스택 프레임워크의 등장
    • Nest.js와 같은 백엔드 프레임워크 등장
    • Next.js와 같은 서버 사이드 렌더링(SSR)을 지원하는 프론트엔드 프레임워크 등장
    • 이를 통해 개발의 효율성과 성능 최적화 가능
  • Jamstack
    • 프론트엔드와 백엔드의 완전한 분리를 추구하는 아키텍처
    • 정적 사이트 생성기와 헤드리스 CMS가 주요 트렌드
  • 개발환경의 표준화와 자동화
    • Docker, Kubernetes와 같은 컨테이너 기술 등장
    • 개발과 배포 프로세스 표준화&자동화
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.