#스키마

앱 배포시 백엔드 서버와의 간극 해결방법

안녕하세요! 장고로 백엔드 서버를 개발하고 RN로 프론트엔드 앱을 개발하고 있습니다..! 프로젝트 초반이라 요구 사항이 자주 변경되어서 테이블을 재설계하거나 api 응답 스키마(serializer)를 수정하는 상황이 빈번하게 발생하고 있습니다. 백엔드 서버는 배포시에 바로 반영이 되지만, 앱 배포의 경우 앱스토어의 심사 + 자동 업데이트로 인해 2~3일 정도의 간극이 발생합니다. 이로 인해 백엔드 응답 스키마가 앱의 old 버전과 일치하지 않아 문제가 발생합니다 ㅠㅠ 현업에서는 이런 문제를 사전에 어떻게 방지하는지, 배포 파이프라인을 어떻게 구성하는지 궁금합니다..! 제가 조사한 바로는 base_url에 버전을 표시하거나 (../api/v1/…), http header에 버전을 명시해서 라우팅을 해주는 것으로 알고 있는데요. 요구사항에 대한 변화가 잦다 보니 더 좋은 방법이 있을까 싶어거 여쭤봅니다..! 읽어주셔서 감사합니다😆

채팅 디비 설계 질문이요!

안녕하세요:) 저는 ! 웹소켓과 관계형디비+프리즈마 를 이용해서 백엔드를 구성하고, 리액트로 만든 프론트 와 양방향 채팅 서비스를 만들려고 합니다! 채팅방 DB스키마를 작성하는데 어려움을 겪어 질문을 남깁니다. 현재 프리즈마에서 model ChatRoom { id Int @id @default(autoincrement()) name String creatorId Int users ChatRoomUser[] messages Message[] createdAt DateTime @default(now()) updatedAt DateTime @updatedAt } model ChatRoomUser { id Int @id @default(autoincrement()) userId Int // 외부 API에서 가져올 사용자 ID chatRoomId Int chatRoom ChatRoom @relation(fields: [chatRoomId], references: [id]) createdAt DateTime @default(now()) updatedAt DateTime @default(now()) @@unique([userId, chatRoomId]) } model Message { id Int @id @default(autoincrement()) chatRoomId Int senderId Int // 외부 API에서 가져올 사용자 ID receiverId Int? // 선택적 필드, 단체 채팅에서는 null content String timestamp DateTime @default(now()) chatRoom ChatRoom @relation(fields: [chatRoomId], references: [id]) createdAt DateTime @default(now()) updatedAt DateTime @default(now()) } 이런식으로 구현하였는데 조언좀 부탁드립니다.ㅠㅠ

개발 SI 회사 파산시 제가 요청해야 할 것이 무엇이 있을까요? ㅜㅜ

안녕하세요, 다름이아니라 제가 개발을 외주로 맡기고 있었는데 외주 회사가 곧 파산을 한다고 합니다. 회사 말로는 “현상태로 개발을 종료하고 인수인계 자료를 만들어서 추후 타 개발사와 코웍하실 수 있게끔 해드리게 하겠다”라고 하는데 이 때 제가 무엇을 요청해야 하는 것이 있을까요? 참 답답하네요.. PHP, Android, Flutter, AWS(EC2,RDS), Mysql, Firebase, Codeigniter 전체 소스코드 및 문서: - 현재까지의 모든 소스코드 - 프로젝트 관리 문서, 기술 문서, 설계 문서 등의 모든 문서 - 사용된 데이터베이스의 전체 백업과 함께, 데이터베이스 스키마 또는 구조에 대한 문서

mysql 인스턴스에서 여러 스키마를 생성하는 것이 불필요한 건가요?

과거 mysql을 사용할 때 하나의 스키마 아래에 여러 테이블을 만들어 작업한 적이 있습니다. 스키마 아래로 너무 많은 테이블들이 생성되어 테이블간 연관성이나 관계를 확인하기가 쉽지 않았습니다. 이번 프로젝트에서는 과거처럼 하나의 스키마(my_db)가 아니라 연관성이 높은 테이블들을 스키마별로 모아서 연결하고 싶었습니다. 예를 들자면, user관련 테이블들은 Users스키마에, product과 연관된 테이블들은 Products스키마에, 중간테이블이 필요하면 Users_Products스키마에 테이블을 저장했습니다. 이 구조라면 하나의 mysql 인스턴스에 3개의 스키마가 생성된 것입니다. 문제는 nestjs에서 typeorm 설정을 하는 과정에서 database를 입력하는 부분에서 발생했습니다. TypeOrmModule.forRoot에서 database이름을 하나밖에 입력할 수 없었습니다.(mysql은 database와 schema를 동의어로 취급한다고 들었습니다.) 3개의 스키마를 연결하는 방법은 다음과 같다는 것을 발견했습니다. 이런 방법을 쓰는 이유를 작성자는 서비스용 database, 정보분석용 database를 나눠서 사용하기 위함이라고 말합니다. https://www.inflearn.com/questions/662388/typeorm-%EB%8B%A4%EC%A4%91-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%97%B0%EA%B2%B0 mysql로 하나의 서비스를 위해 스키마를 여러개로 나누어서 하나의 앱에 적용하는 것이 불필요한 방법일까요?

Flutter inappwebview 앱 열기 질문입니다

안녕하세요! Flutter로 앱을 개발중입니다. 인앱웹뷰로 앱을 여는데, 타 앱을 열리나 알 수 없는 스키마로 웹페이지를 열 수 없다는 에러페이지가 해당 앱 내에서는 보여집니다. 도대체 이유가 뭔지 모르겠어서 며칠간 고민하고 질문드립니다..

현업에서 foreign key(FK)를 정말 안쓰는지 궁금합니다

안녕하세요 1년차 백엔드 개발자 입니다 옛부처 많이 들어왔던 얘기입니다 FK는 현업에서 사용하지 않는다 그 이유는 1. 무결성 체크로 인한 성능 저하 가능성 2. 스키마 수정 시의 번거로움 3. FK 설정 시 제약조건 관련 테이블들의 S Lock 발생 이라고 이해했습니다 정말 현업에서는 FK를 사용하지 않는지, 사용하지 않는다면 정확히 어떤 이유인지 알고 싶습니다

도메인 모델과 영속성 모델을 분리하는 것이 어떤 상황에서 효율적인가 알고 싶습니다

개발을 공부하다 도메인 모델과 영속성 모델을 분리하는 것이 어떤 상황에서 효율적인가 판단이 되지 않아 질문드립니다 저는 도메인모델과 영속성모델을 분리할 경우에, 시간이 촉박하고 변화가 빠른 팀에는 과한 업무량을 부여할 거라고 생각을 했고, 오히려 프로그램의 생명 주기가 긴 경우에 적합하다고 판단했습니다. 하지만 좀 더 공부해보니 오히려 변화가 잦을수록 두 영역의 분리가 빛을 발한다라는 얘기를 듣고 조금 혼동이 왔습니다. 보통 회사에서 비즈니스 수정과 확장에 의해 스키마 이상의 데이터베이스 버전이나 종류, 라이브러리가 변동되는 일이 얼마나 잦은 일인지, 또 결국 그럼 영속성 모델과 도메인 모델을 분리를 명확하게 하는 것이 어떤 상황에서 적절한지에 대해 여쭙고 싶습니다

ORM 데이터베이스 스키마(컬럼) 변경시 어떻게 대처하시나요?

안녕하세요! ORM을 사용하면 데이터베이스 스키마 변경에 유연하게 대처할수있는것으로 알고있습니다! 하지만 상식적으로 생각을 했을때 데이터가 존재하는 컬럼의 컬럼명을 변경할려면 엔티티명만바꾸어서 해결될것이아니고 해당 컬럼의 데이터를 모두 이관하는 작업까지 이루어져야할거같은데 다들 어떤식으로 대처하시나요? 경험있으신 선배님분들 계실까요???

GraphQL의 장점이 무엇인가요

현재 프로젝트에 GraphQL을 도입해볼까 고민하고 있습니다. 기존 REST 방식의 Over Fetching & Under Fetching 에 비해 필요한 정보만 스키마로 정의해서 가져올 수 있다고 확인했습니다. 그런데 결국 Restful한지 GraphQL을 썼는지는 서버와 Client 간의 통신 레벨에서만 작용하는 것은 아닌가라는 생각이 듭니다. GraphQL처럼 원하는 정보만을 뽑어오는 것은 SQL projection과 Dto 사용으로 충분하다고 느껴집니다. 또한 GraphQL 을 사용한다고 저 작업을 안하는 것도 아니라고 생각이 듭니다. 제가 자료조사가 부족하거나 적절하지 못한 이해를 했을 수도 있습니다. 혹여나 다른 분들께서 설명이나 참고자료를 공유해 주실 수 있으신가요?

SI 업체 개발 스타일 풀스택

안녕하세요 최근 회사 프로젝트인 iot장비기반 관리자 웹페이지를 si업체를 통해 맡겼는데 자신들은 풀스택이라면서 프론트 메뉴 페이지 마다 사람을 할당하네요 기본적으로 프론트 / 빽이 나눠지고 SB설계 후 db스키마 잡고 api를 우선 설계해서 어느정도 만들면 퍼블된 화면에 프론트개발자들이 스웨거 활용하여 개발하는 프로젝트만 하다가 이렇게 하는게 효율적인가요? 그리고 스프링 구조잡을때 어느정도 큰 기능별로 서비스/컨트롤러를 나눈다고 알고있는데 컨트롤러 폴더에 모든 컨트롤러코드가 있고 서비스는 서비스폴더에 다 있어서 이게 맞냐하니깐 테이블 100개 미만 소규모는 이렇게 해도 된다고 하더니 그날 오후 큰 기능별 폴더 구조 아래 서비스/컨트롤러 폴더로 쪼개놧네요 ㅠㅠ 왠지모를 불안감이 듭니다 고급개발자 두명에 오년정도 개발자두명인데 거의 오년차 개발자들이 페이지별 프론트와 빽을 같이 설계하도록 WBS를 잡아놨네요 제가 잘 몰라서 그러는데 고수님들 사기 각인가요?