Benjamin
1인 개발자로 사는 이야기
국내 1위의 개발 유튜브를 운영하고 계시는 조코딩님과 함께 유튜브 촬영을 했습니다.
https://www.youtube.com...v=L6TNhTNHRIA?
1인 개발자로 사는 이 ...
https://www.youtube.com...v=L6TNhTNHRIA?
1인 개발자로 사는 이 ...
youtube.com
15
3
4
🧑💻
1인 개발로 경제적 자유 달성하고 건물주 생활하는 개발자 인터뷰
샵빱뚜비두
허생은 스타트업에 다녔다.
dev_sooyeon
페어 프로그래밍 직접 해보니.. 이렇습니다
페어 프로그래밍을 실제로 경험한 개발자들의 후기를 모아봤습니다.
장점으로는
• 오타, 변수명 등으로 인한 디버깅 시간이 80% 이상 감소되는 것을 확인
• 주니어에게는 실력을 상승 ...
장점으로는
• 오타, 변수명 등으로 인한 디버깅 시간이 80% 이상 감소되는 것을 확인
• 주니어에게는 실력을 상승 ...
tech.kakao.com
5
2
signer
리액트, 널 사랑하지만 넌 나를 슬프게 해
React.js에게,
우리가 함께한 지 어언 10년이라는 시간이 흘렀습니다. 많이 발전했네요. 그런데 이제는 감당이 안 됩니다. 우린 대화가 필요해요.
창피한 거 알아요. 아무도 ...
우리가 함께한 지 어언 10년이라는 시간이 흘렀습니다. 많이 발전했네요. 그런데 이제는 감당이 안 됩니다. 우린 대화가 필요해요.
창피한 거 알아요. 아무도 ...
velog.io
2
1 comment
NEWTHINGS
공부한 내용을 100% 내 것으로 만드는 방법!
배운 내용을 100% 흡수하는 방법에 대한 글인데 내용이 좋네요. 직무, 분야 가리지 않고 적용되는 방법인 듯 해요!
1. 사이드 프로젝트 만들기
프로젝트 하나를 처음부터 끝까지 ...
1. 사이드 프로젝트 만들기
프로젝트 하나를 처음부터 끝까지 ...
brunch.co.kr
7
2
3
랄랄라
개발자를 위한 무료로 가능한 서비스들 모음
1. https://free-for.dev/#/
2. https://github.com...stack-on-a-budget/
출처 ...
2. https://github.com...stack-on-a-budget/
출처 ...
free-for.dev
5
5
앤드류
waterglasstoon 추천받았는데
넋놓고 봤네요. ㅋㅋ 이 분 표현력 너무 좋으시네요.
출처:
https://www.instagram.com/p/CjSTeVPv9bw/ ...
출처:
https://www.instagram.com/p/CjSTeVPv9bw/ ...
6
1
샵빱뚜비두
선언형, 명령형 코드 그리고 추상화
한번씩 이렇게 개념을 명확하게 하는 글을 읽으면 마음이 개운~해지더라고요.
milooy.github.io
1
elly
구글 엔지니어는 이렇게 일한다 책의 요약본
정리를 엄청 깔끔하게 해 주셨길래 공유해봅니다.
[구글 엔지니어는 이렇게 일한다] 책을 읽고 가볍게 훑어볼 수 있도록 간략하게 요약했어요. 지난달 프론트엔드 챕터에 공유했었는데요, 외부에 열어도 좋을 것 같아서 공유합니다 :)https://t.co/jRgXp3vVsw— Jbee🐝 (@JbeeLjyhanll) August 1, 2022
4
2
앤드류
이런 의자 있으면 좋겠네요
https://fb.watch/ebdsHAH5H6/
거북목에 좋을 거 같은데, 옯겨다니면서 일할 수도 있고
거북목에 좋을 거 같은데, 옯겨다니면서 일할 수도 있고
fb.watch
4
4 comments
5
9
8
2
3 comments
6
1
3
브래드
조회수 0
Express.js router 탐험기
(스압주의)
(스압주의)
(스압주의)
개요
express middleware 관련해서 문서를 훑다가, 문득 express 내부에서는 우리가 설정해둔 경로들을 어떻게 처리하고있는지 궁금해졌습니다. 설정 방식에 따른 성능의 차이가 존재하는지도 궁금했구요. 그러지 말았어야 했습니다
시작
우리가 넘기는 path...어디로 갈까? 가 궁금해서 express의 github으로 갔습니다.
간단하고 짧은 코드인데도, 라이브러리 코드를 읽는건 어려운 것 같습니다. 정신이 혼미해지기전에 대충 훑어보며 다음과같은 정보를 얻었습니다.
`Router.stack`에서 Layer의 배열을 유지함
Layer내부에서는 넘겨받은 경로(`path`)를 정규식으로 변환해서 저장: 코드
요청이 들어오면, 정규식이 매치되는값이 나올때까지 `Router.stack`을 while-loop를 돌며 조회
path를 기준으로 일치하는 Layer를 찾으면: 코드
해당 Layer에 일치하는 method가 존재하는지 검사 후 실행: 코드
`/` 나 `*`같은 특이케이스는, 별도 처리: 코드
궁금증
코드를 읽다보니, flatten 어쩌고,,, split 어쩌고 하는 코드들이 보이는데
모든 경로는 쪼개져서 구조화되어 (flat한 list 형태로)저장되는것인지?
Layer는 단층인지, 혹은 여러개 층인지
단층이면 이름이 Layer 일 리는 없지.. 그럼 어떤 단위로 계층이 나뉘는지?
가 궁금해졌습니다.
그런데 코드를 더보다가는 점심을 나가서 먹게될 것 같아서 그냥 테스트 코드를 만들었습니다.
테스트 1
간단한 express app을 만들고, 두가지 케이스로 express route를 설정했습니다.
express/lib/router/index.js:153 라인에서 `Router.stack`값을 콘솔에 찍었습니다.
벌써 prettier의 노예가 되어버려서, 들여쓰기는 엉망입니다. 감안하고 봐주세요.
case 1. path가 같더라도, 모든 라우트를 따로 정의
case 2. 같은 path의 method만 다른 경우 하나로 묶음
결과:
원래는 성능테스트도 겸할 목적으로 route를 많이 만들었는데, 귀찮아서 라우트객체의 결과값만 비교했습니다. 때문에 스크린샷의 동그라미 친 부분만 보셔도 됩니다.
좌측이 case 2, 우측이 case 1 의 결과입니다.
원래 output에는 다른 Layer객체의 정보들도 들어있었지만, 보기 편하도록 regexp 필드만 잘라넣었습니다.
정말 코드에 정의하는 그대로 똑같이 들어가네요. 중복된 경로는 최소한으로 쓰는게 좋겠다는 결론을 얻었습니다.
테스트 2
프로젝트 설정 시, 흔히 route의 중간 경로별로 파일을 분리하곤 합니다. 예를들어 user와 관련한 API route들은 `/server/route/api/user.js` 에 두고, item 관련 API는 `/server/route/api/item.js` 에 만드는 식으로요.
이런 경우에, 각 route의 path를 모두 풀어 쓴 경우와, 단계별 공통된 route별로 분리해서 계층화 한 경우 `Router.stack`의 값에 차이가 생기는지도 궁금했습니다.
case 1. 풀어 쓴 경우
이 경우는 테스트 1의 case 1과 동일하므로 별도로 작성하지 않았습니다.
case 2. 계층화 한 경우
외부에 공통된 경로로 route를 설정하고,
별도의 파일에서 하위 경로의 route를 설정
결과:
마찬가지로 동그라미친 부분만 보시면 됩니다.
우측이 기존, 좌측이 case 2 의 결과입니다.
case 2의 결과에서는 로그가 두번 찍혔네요. (아래쪽 동그라미) 따라서 case 2와 같은 방식으로 구현하면 Layer가 계층화되어 저장되며, 재귀 탐색이 된다는 것을 알았습니다.
요청이 들어오면 매번 위에서부터 하나씩 정규식 비교가 실행 될 것이므로, 공통된 중간 경로를 가진 route가 많다면 위와같이 계층화 시켜 구현하는것이 더 효과적일것이라 생각합니다.
실제로도...?
정말 속도가 차이가 날까?
궁금해서 계층화 하지 않은 버전과 계층화 된 버전, 두가지의 마지막에 있는 api를 axios를 이용해서 각각 100,000번씩 호출 해 보았습니다. 실험은 각 6번씩 반복했습니다.
다만 위 샘플코드로 테스트해본건 아니며, 개발중이던 프로젝트를 조금 단순하게 수정한 후, 위 실험 2와 비슷한 조건으로 만들어서 테스트 했습니다.
신뢰할만한 실험이었는지는 장담할 수 없지만, 약간의 차이는 보였습니다. (단위: ms)
case 2에서 약 3.5% 정도의 빠른 응답속도가 나왔네요.
다만 유의미한 수치를 보려면 더 복잡한 구조의 프로젝트에서의 테스트가 필요할 것 같습니다.
결론 / TL;DR
1. express는 우리가 넣어둔 router path들을 모두 정규화 시켜서 저장한다.
2. 넣어둔 path들은 순서대로 배열에 쌓이며, 일치하는 값이 나올 때 까지 순서대로 정규식 검사가 실행된다.
3. router를 중간 경로가 같은 것 끼리 묶어서 계층화 시켜두면, 실제로 express도 우리가 넣은 구조 그대로 값을 저장한다.
4. router에 공통된 중간경로를 가지는 route가 많다면, 계층화 시켜서 최적화 할 수 있다. 다만 엄청 큰 규모가 아니라면 유의미한 수준의 성능개선은 어렵다.
2
3
데이빗
Feb 5, 2022스태틱한 경로를 굳이 정규식으로 풀어서 저장한 이유가 뭘까요? 저라면 경로 / 별로 맵을 만들어서 아래처럼
요렇게 저장해두고 정규식으로만 풀 수 있는걸 같이 돌리면 라우팅이 더 빠를 것 같은데....
브래드
Feb 5, 2022아마 문자열경로/정규식경로를 나누지 않은 이유는 순서가 제일 중요하기때문 아닐까 싶으네요!
문자열을 굳이 정규식으로 바꾼건.... 그러게요 단순하게 만들고 싶었던걸까요
실제로
if (typeof path === 'string') then compare
과
pre-compile된 정규식 비교 한번 하는 것
둘의 속도 차이가 많이 날런지도 궁금하기는 합니다
산책왕
Feb 5, 2022@브래드 정규식 비교가 구문에 따라 비용이 큰 경우가 많지만, 라우팅에 쓰는 URL 패턴은 대부분 복잡하지 않으니까 일관성에 초점을 둔 게 아닐까요?
라우팅 패스 파라미터로 정규식을 넣을 수 있기도 하고요.
1