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

웹서비스

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

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

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

2.(정적)페이지제공

프론트엔드

백엔드

현재대한민국의개발환경

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

새소식

인기 검색어

[TIL] 240419 웹 기초

웹 서비스

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

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

2. (정적) 페이지 제공

프론트엔드

백엔드

현재 대한민국의 개발 환경

당신이 좋아할만한 콘텐츠

티스토리툴바

단축키

내 블로그

블로그 게시글

모든 영역

	<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>

	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 "사전 페이지 입니다.";
	}
	}

	// 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}`);
	});