2025. 4. 7. 11:35ㆍ현 프로젝트 시작단계
왜 하나? 현재 flutter+ 서버리스로
지도와 프론트엔드는 만들었다. 근데
커뮤니티 부분은 spring 을 이용해 RESTful api 를 이용해
flutter 와 연결 시켜 놓을려고 한다.
이미 지도는 만든상황에 서버리스로 만들었고 생각보다
호출량이 많이 나온다. 여기서 커뮤니티까지 만들어 버리면
호출량이 어마 무시하게 나올것이다. 사람이 없는 서비스라도 호출량만 엄청 나올것이고
10명이 쓰는데 서버 부하가 올것이라 생각했다.
그래서 간단한 커뮤니티를 서버단에 빼버리면 조금 나을 거같다.
내가 지도부분을 spring으로 만들었다면 문제가 없었겠지만 이건
기술 문제라고 생각했다. 그래서 커뮤는 무조건 간단하지만 프론트엔드인 나에게 어려운일을
해보려한다.
먼저 백엔드 연결을 위해
마리아 디비를 다운 받아줍니다. hs를 키면
디비 설정과 마이 바틱스 경로를 설정해줘야합니다.
연결해준 암호를 넣어주면 연결됩니다.
application.yml 파일에 코드를 추가해줍니다.
mybatis:
mapper-locations: mappers/**/*.xml
spring:
application:
name: GreenGramVer2
datasource:
driver-class-name: net.sf.log4jdbc.sql.jdbcapi.DriverSpy
url: jdbc:log4jdbc:mariadb://localhost/modir
username: root
password: 자기가 설정한 마리아디비 번호
servlet:
multipart:
max-file-size: 15MB
✅ req 와 res 는 뭐야?
- req = request (요청)
- res = response (응답)
👉 "프론트엔드가 서버한테 보내는 것"이 req,
👉 "서버가 프론트한테 돌려주는 것"이 res 에요!
res와 req과정
✅ 1. 글쓰기 요청 (프론트 → 서버)
👉 req = 요청 데이터
프론트에서 사용자가 게시글을 작성하고 "등록" 버튼을 누르면,
서버로 이런 JSON 형식의 요청이 들어갑니다:
POST /feed {
"title": "오늘의 스타일",
"content": "오늘은 청청패션!",
"uuid":
"user1234"
}
✅ 2. 글보기 응답 (서버 → 프론트)
👉 res = 응답 데이터
서버는 글을 DB에 저장하고, 다시 프론트에게 정보를 줄 수 있어요:
롬복 라이브러리가 필요한 이유 잠깐 설명
여기 코드 를 보면 이렇게 일일이 다적어줘야되는데
public class SellUserRes {
private String uuid;
private String username;
private String email;
public String getUuid() {
return uuid;
}
public void setUuid(String uuid) {
this.uuid = uuid;
}
// username, email 도 동일하게 get/set 메서드 작성 필요
}
이걸 해결 해주는 방법은
롬복 라이브러리의 getter ,setter 을 쓰면된다.
@Getter
@Setter
public class SellUserRes {
private String uuid;
private String username;
private String email;
}
👉 @Getter, @Setter는 코드를 짧게 하고 자동으로 getter/setter 생성하게 해주는 마법 같은 도구입니다.
- @Getter만 쓰면 읽기 전용 (set은 못함)
- @Setter만 쓰면 외부에서 값만 넣을 수 있음
현재 바텀바 에서 지도 기능은 서버리스를 이용해서 불러온다.
근데 커뮤니티리는 spring으로 만들어야 되겠다는 생각을 했다.
DB처리 → Mapper → Service → Controller 순서로 작성하기
DB 처리 로직이 핵심이니까, 가장 밑바닥부터 쌓아올리는 느낌으로 만든다.
Mapper 및 DB처리
XML 파일에 어떻게 처리 할것인지 적어준다.
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
"https://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.example.modir.user.UserMapper">
<insert id="InsUser">
INSERT INTO `user`
SET `uuid` = #{uuid},
username = #{userName},
email = #{email}
</insert>
<select id="sellUser">
SELECT `uuid`, username, email
FROM `user`
</select>
</mapper>
그리고 매퍼를 적어준다.
package com.example.modir.user;
import com.example.modir.user.model.InsUserReq;
import com.example.modir.user.model.SellUserRes;
import org.apache.ibatis.annotations.Mapper;
@Mapper
public interface UserMapper {
int InsUser(InsUserReq req);
SellUserRes sellUser();
}
이 메서드는 XML 파일에서 id="InsUser"인 SQL과 자동으로 연결
@Mapper가 붙으면 Bean으로 등록돼서, 서비스에서 주입해서 쓸 수 있게 된다는 게 핵심
🔧 스프링에서의 "Bean" 이란?
먼저, Bean이라는 건 스프링이 관리해주는 객체예요.
스프링이:
- 객체를 대신 만들어주고
- 필요한 곳에 자동으로 주입(injection)해줘요.
이렇게 하면 UserMapper 객체를 직접 new 하지 않아도,
스프링이 알아서 만들어서 등록해줍니다.
프링이 대신 객체를 만들어서 자동으로 넣어주는 방식
( 서비스에 적을때 private final UserMapper userMapper; // 자동 주입됨 )
직접 new 방식 지금 방식
요리 재료를 직접 사고 요리 | 배달앱으로 시켜먹는 느낌 🍕 |
구현체를 직접 만들어야 함 | 스프링이 자동으로 만들어줌 😎 |
코드 많고 귀찮음 | 코드 깔끔하고 유지보수 쉬움 👍 |
여기까지가 mapper -> service 의존성주입까지 의 내용이다 다음은 서비스 컨트롤러 까지
Service
- @RequiredArgsConstructor: final로 선언된 필드(userMapper)를 자동으로 생성자에 넣어줘요.
→ UserService가 생성될 때 UserMapper도 자동으로 들어옴!
@Service
@RequiredArgsConstructor
public class UserService {
private final UserMapper userMapper;
}
✅ 사용자 등록 (postUser)
- 프론트에서 사용자 데이터를 보냄 (req)
- userMapper.InsUser(req)가 DB에 INSERT 쿼리를 실행
- 결과(영향 받은 행 수)를 res에 저장해서 리턴
public int postUser(InsUserReq req){
int res = userMapper.InsUser(req);
return res;
}
✅ 사용자 조회 (getUser)
- DB에서 사용자 한 명의 정보를 불러옴
- 그 정보를 SellUserRes에 담아서 리턴
public SellUserRes getUser(){
SellUserRes res = userMapper.sellUser();
return res;
}
Controller
@RestController
@RequiredArgsConstructor
@RequestMapping("user")
- @RestController: 이 클래스는 API 응답용 컨트롤러다! (@Controller + @ResponseBody)
- @RequiredArgsConstructor: final 필드인 userService를 자동으로 생성자에 주입
- @RequestMapping("user"): 이 컨트롤러는 /user로 시작하는 URL 처리
✅ POST /user → 사용자 등록
- 프론트에서 사용자 정보 보내면 → InsUserReq req로 받음
- userService.postUser(req)로 DB에 저장
- 성공하면 ResultResponse 객체로 응답 (resultMessage, resultData 포함)
@PostMapping
public ResultResponse<Integer> postUser(InsUserReq req){
int result = userService.postUser(req);
return ResultResponse.<Integer>builder()
.resultMessage("회원가입")
.resultData(result)
.build();
}
예시 요청
POST /user
Content-Type: application/json
{
"uuid": "user123",
"username": "곰돌이",
"email": "bear@example.com"
}
✅ GET /user → 사용자 정보 조회
- 프론트에서 /user로 GET 요청하면 → DB에서 사용자 정보 가져옴
- userService.getUser() 호출 → 매퍼 통해 조회
- ResultResponse로 포장해서 응답
@GetMapping
public ResultResponse<SellUserRes> getUser(){
SellUserRes res = userService.getUser();
return ResultResponse.<SellUserRes>builder()
.resultMessage("사용자 조회")
.resultData(res)
.build();
}
✅ ResultResponse는 뭐야?
공통 응답 포맷을 만들기 위한 클래스예요.
API 결과를 일정한 형식으로 보내려고 만든 거예요.
예를 들어 이런 식:
{
"resultMessage": "회원가입",
"resultData": 1
}
{
"resultMessage": "사용자 조회",
"resultData": {
"uuid": "user123",
"username": "곰돌이",
"email": "bear@example.com"
}
}
'현 프로젝트 시작단계' 카테고리의 다른 글
14. 스프링부트 좋아요 만들기 (0) | 2025.04.10 |
---|---|
13. 스프링부트 파일 등록하기 (0) | 2025.04.09 |
11. 로그인상태 유지 ,세션유지 (0) | 2025.03.19 |
10. 매장 리스트 만들기 (0) | 2025.03.18 |
9. 스프링 테스트 / 진행사항 (0) | 2025.03.15 |