백엔드

개발이 이루어지기 위해선 개발공간과 해당 공간의 내장요소들이 필요하다.공간/요소는 여러 종류와 형태가 있으며, 목적 및 기능에 따라 잘 선택하여 사용할 수 있어야 한다.프레임워크 (Spring(Java) / Django(Python) /Angualrjs(JS))보통 웹

물리적인 컴퓨터 자원을 논리적인 객체로 표현하는 기술하나의 하드웨어를 여러 하드웨어가 있는 것처럼 동작하거나, 여러 하드웨어를 하나의 하드웨어처럼 묶어 동작하는 방법이 있다.CPU, memory, server, storage, DB 등 HW자원 및 OS 등의 효율적인

객체와 묶는 과정말 그대로 묶는 과정을 말한다.보통 class나 객체 내부에서 this를 통해 인스턴스를 묶는 과정을 말하고, binding된 this(프론트엔드에서는 props가 될 것)를 통해 해당 객체로 접근할 수 있다.여러 모듈이나 파일을 하나로 묶는 과정bun

process A를 제약사항없이 처리하였을 때 소요되는 시간이 있다.이때 비동기처리를 위한 logic 추가나 middleWare 등과 같은 부가적인 요소들로 인해 process A를 처리하는 시간이 늘어날 때 오버헤드가 발생하였다고 한다.즉 쉽게말하면 처리시간의 지연을

뒤에 있는 proxy serverclient가 host server에 직접 접속하는 것이 아닌, proxy server를 통해 network에 접속할 수 있도록 통로를 제공하는 cache의 일종.가상의 server, 실제 server 역할을 대신 해주는 곳이라 생각하면

1-1. 레지스터 관점의 개념 > 명령을 한 레지스터에 옮겨 담는 과정, 혹은 옮기는 것 시스템 구조론, 레지스터 관점에서의 fetch는 명령(operand)을 레지스터에 옮기는 과정을 일컫는다. 1-2. javascript 관점의 개념 > 외부의 REST AP

코드예시를 통해 fetch와 axios의 차이점을 살펴본다.react-native에 적합한 함수.fetch는 url를 인자로 전달받는다.주어진 url의 res를 전달하며, json data형식으로 반환한다.반환(return)하는 res는 body 속성을 지닌다.url

Apollo/GraphQL을 사용하기 전에 왜 GraphQL을 사용해야하고, GraphQL를 실무에서 활용하기 위해 Apollo가 왜 필요한지 그 이유를 알아본다.REST API는 접속할 url에 대해 POST/GET 등의 방식으로 data를 요청한다.REST API는

Route, useQuery 등 외부에서 받아오는 data들은 기본적으로 요청, 응답까지 소요되는 시간이 매우 길다.useQuery를 통해 받아오는 data는 GraphQL server로부터 전달받는다.이러한 데이터 처리에 오랜 시간이 소요되는 경우, 별도 장치없이 바

실무에서 다음과 같은 경우가 발생한다.특정 시점에서 DB table의 존재 유무를 확인한다.DB table이 존재하지 않는다면, 새로 생성된다. 생성한 table이 존재한다면 특정 column의 value를 update한다.이때 특정 시점에서 DB table의 존재 유

backend API를 만들면서 기능이 동작한다는 점, frontend에서 보안적인 이유로 진행할 수 없던 logic을 backend에서 보완했다는 점 외에 사실 매우 많은 유의사항이 존재한다.추가적으로 알게되었던 유의사항들 중 하나는, 기능개발을 진행하면서 추후 DB

동시성 문제를 해결하기 위해 필요한 개념인 프로세스와 스레드에 대해 공부하고 정리한 내용을 기록한다.프로세스와 스레드는 운영체제에서 작업 효율성을 극대화하기 위한 병렬처리 과정에서 사용하는 개념으로, 이 개념은 웹개발 및 백엔드에서도 활용한다.프로세스 : 운영체제로부터

동시성 문제를 해결하기 위한 개념을 학습하기 위해 싱글 스레드와 멀티 스레드 공부 내용을 기록한다.프로세스를 하나의 스레드로만 작업하는 과정을 의미하며, Java의 경우 메인메서드를 실행하였을때 메인스레드를 생성한다.별도의 스레드 요청 작업이 없다면 메인스레드라는 싱글

스레드를 구현할 수 있는 대표적인 3가지 방안에 대해 공부한 내용을 기록한다.Thread 추상클래스를 상속받아 사용한다.Runnable 인터페이스를 구현하여 사용한다.(\* 이때 Runnable 객체를 Thread의 인자로 전달하여 스레드를 구현할 수 있다.)람다식을

기본적으로 스레드를 활용하고 관리하기 위해 필요한 개념들을 공부하여 정리한 글이다.데몬스레드는 우선순위가 낮아 보이지 않는 곳에서 실행되는 스레드를 의미하는데, 1차적으로 메인스레드 실행 완료 후 필요 시 데몬스레드가 실행된다.JVM 및 애플리케이션 종료는 메인스레드의

스레드 상태를 직접적으로 관리할 수 있는 메소드를 공부한 내용을 기록한다.스레드는 실행대기 - 실행 - 종료의 생명주기를 가진다.스레드의 실행대기는 start() 메서드를 통해 이루어진다.그 후 자원을 할당받아 정의한 작업 내용대로 처리하며, 이는 run() 메서드를

myBatis mapper 사용 시 bean 오류가 매번 발생하여 고생을 좀 하였는데, 이번에 오류해결을 하면서 했던 설정 방법을 남기고자 작성한다.spring boot 버전에 맞는 myBatis spring boot starter maven dependency를 설치

지금까지 Docker 개념이 자리잡지 못한 채로 개발을 진행하다보니 헷갈리는 부분도 많고, 어떠한 필요에 의해 Docker를 사용하는지 정확히 인지한지 못한 채 흐르는 파도에 몸을 맡긴 상황인 것처럼 개발자답지 못한 개발을 진행하였다.개인 프로젝트 겸 학습을 진행하면서

일전에 작성한 Docker 작동원리 및 과정을 토대로 Docker를 실행하는 과정에 대해 이해한 내용을 정리해본다.Docker Run, 도커를 실행하는 과정은 정확하게 말하면 "특정 환경을 구성할 이미지파일을 컨테이너로 실행한다"라는 의미와 동일하다.Docker Des

개인 프로젝트를 진행하면서 인덱스를 좀 더 깊게 살펴보는 기회가 생겨 공부해보았다.단순히 정렬된 데이터를 저장하는 공간인가? 필요한 데이터를 추출하기 위한 데이터 저장공간에 이미 데이터가 정렬이 되어있기 때문에 조회 성능이 향상하는가? 인덱스를 사용하여 조회성능이 향상

일전의 인덱스를 통한 조회성능향상에 이어, "근본적으로 데이터가 너무 많아 조회성능을 향상하고 싶은 상황"에 대해 공부한 내용을 기록하고자 한다.데이터가 많아진다면, 아무리 인덱스를 잘 구성하고 쿼리를 잘 사용하여 Covering index를 활용한다고 한들 물리적인

지금까지 생각없이 UUID/Time Stamp/Auto Increment 등 단일DB에서 유일성을 보장하기 위한 채번방안만을 고려하였는데, 이를 넘어 분산DB 환경 및 인덱스 환경까지 고려한 적절한 채번방안을 마련해야 한다는 것을 깨닫게 되었다.이에 대해 공부하면서 정

지금까지 데이터 관리를 할때 계층 구조가 존재할 경우(MIS/Back Office) 단순히 ID/PARENT_ID 두가지 항목만을 관리하였다.두 항목만을 관리항목으로 고려하였기에, 데이터를 표현할때는 CONNECT BY와 LEVEL을 활용하였고, 이러한 데이터 구조와

금번의 개인 프로젝트는 각 서비스마다 별도의 Database를 두는 MSA 환경으로 진행하고 있는데, 그러다보니 일전에는 단순하게 생각했던 부분들이 지금의 환경에서는 좀 더 깊게 생각해볼 문제라는 것을 알게되었다.이번에 게시글(Article), 좋아요(like) 기능을

개인 프로젝트를 진행하면서 "조회수"라는 비교적 간단한 기능을 구현할때 기능적/환경적 요인을 고려할때 꽤 흥미있는 장치를 결합할 수 있지 않을까라는 생각을 하게 되었다.일전의 게시글 및 게시글 좋아요 수와 달리, 조회수는 데이터의 실시간 처리가 즉각적으로 이루어지지 않

대용량 트래픽이 발생할 수 있는 상황에서 순차처리와 안정성 등의 고가용성을 보장하기 위한 도구로 Kafka를 많이 사용한다.일전에 Kafka에 대해 한번 정리한 적이 있긴한데, 이번에 다시 한번 살펴보면서 잘못 알고 있었던 내용들을 바로 잡고, 이에 따라 Kafka에