리믹스
Remix 쪽에서 자세히 Next.js 와 자신의 차이를 설명해 준다.
개인적으로 Nextjs 의 복잡함을 좋아하지 않는데, Remix 가 좋은 대안을 주는 듯 하다.
대략 기억나는 것을 정리중…
ref. 1 의 Chapter 1, Reliable, Scalable, and Maintainable Applications
Scalability > Describing Performance
p.14
p. 15
p. 16
Scalability > Approaches for Coping with Load
routine task 를 쉽게 만드는 방법 :
위의 글, Introduction into Domain-Driven Design (DDD), 에 있는 인용문을 보면 DDD 가 말하고자 하는 것을 알 수 있다.
from : Building Microservices by Sam Newman
Eric Evan’s book DDD helped us understand the importance of representing the real world in our code. and showed us better ways to model our systems.
이해한 바를 정리하면, 우리가 우리의 시스템을 우리의 생각대로 그려나갈 수 있지만, 그 그림이 현실세계와 맞닿아 있을때 더 낫다. 그리고 그렇게 시스템을 디자인 하는 것이 DDD 이다.
See Also 4. 를 참고하면, 구체적으로 이 디자인이 어떤식으로 구현되는지를 알 수 있다.
하지만 See Also 5. 의 이야기처럼, DDD 의 기본개념이 뜻하는 바를 이해하는 것이 중요하다. 무조건 DDD에서 제안하는 pattern 이나 기술규칙을 사용하는 것이 DDD가 아니다.
from : Designing a DDD-oriented microservice - .NET | Microsoft Learn
때때로 이러한 DDD 기술 규칙과 패턴은 DDD 접근 방식(DDD aproaches)을 구현하는 데 있어 가파른 학습 곡선을 가진 장애물로 인식되기도 합니다. 하지만 중요한 부분은 패턴 자체가 아니라 코드를 비즈니스 문제에 맞게 구성하고 동일한 비즈니스 용어(유비쿼터스 언어)를 사용하는 것입니다. 또한 DDD 접근 방식(DDD aproaches)은 중요한 비즈니스 규칙이 있는 복잡한 마이크로서비스를 구현하는 경우에만 적용해야 합니다. CRUD 서비스와 같이 더 단순한 책임은 더 간단한 접근 방식으로 관리할 수 있습니다.
Sometimes these DDD technical rules and patterns are perceived as obstacles that have a steep learning curve for implementing DDD approaches. But the important part is not the patterns themselves, but organizing the code so it is aligned to the business problems, and using the same business terms (ubiquitous language). In addition, DDD approaches should be applied only if you are implementing complex microservices with significant business rules. Simpler responsibilities, like a CRUD service, can be managed with simpler approaches.
cors 설정 / redirect fetch / fetch cors
site.a.com 에 접속한 상황에서 fetch 로 api.a.com 에 request 를 했다. 그 상황에서 api.a.com 가 redirect site.a.com 를 나에게 던져준 경우이다.site.a.com
--> fetch api.a.com
--> redirect to site.a.comCORS error 가 뜨는 이유는 Origin 이 site.a.com 이 아니라 null 로 set 돼서 site.a.com 로 request 를 보내기 때문이다. 그렇게 되면, browser 에서 orgin 과 서버가 보낸 Access-Control-Allow-Origin 값을 비교할 때 두 값이 달라서 error 를 던지게 된다.(아래 Fetch: Cross-Origin Requests 부분 참고)
site.a.com 에서 CORS 를 지원하기 위한 설정을 잡아줘야 한다.다음처럼 api.a.com 으로 보내고 api.a.com 으로 redirect 되는 경우는 다음처럼 CORS error 가 안뜨고, 잘 동작한다.
조정한 내용:
Accee-Control-Allow-Origin: nullAccess-Control-Allow-Credentials: trueAccess-Control-Allow-Headers 에 Access-Control-Request-Headers 에서 요청한 header를 넣어준다.Access-Control-Allow-Methods 를 Access-Control-Request-Method에 맞춰서 지정api.a.com 으로 보내고 site.a.com 으로 redirect 되는 경우 : mermaid link
fetch 를 한 후 redirection 을 응답으로 받는 경우
예를 들어, http://a.com/api/a 로 request 를 보낸 경우, redirect 로 http://a.com/api/b가 오는 경우는 한 번 fetch 를 보내면, redirected request 까지 알아서 수행된다.
redirect 가 cors policy 에 걸리는 경우라면, error 를 내보낸다.
const resp = await fetch(realUrl, fetchParam)
consoel.log(resp.redirected) // true
consoel.log(resp.url) // http://a.com/api/b`fetch(url, {redirect: 'manual'}) 을 사용하는 경우, redirect response header 의 Location 을 알 수 있는 방법이 없다.CORS error 가 안뜨게 하려면, 다음처럼 설정을 하면 된다.
client :
mode : 'no-cors'server :
Access-Control-Allowed-Origin: *Access-Control-Allow-Credentials: falseOrigin을 보내면, 그것을 server가 본다.Access-Control-Allow-Origin 을 만들어서 response 에 보낸다.Access-Control-Allow-Origin 값을 비교해서 값이 적절하면, javascript 가 response 값을 access 할 수 있게 해준다.javascript 가 기본적으로 접근할 수 있는 safe header 는 다음과 같다.
js 가 다른 header 에 접근하고 싶어도 browser가 접근을 막는다. 다만 server 에서 Access-Control-Expose-Headers 에 추가된 header는 browser가 js 한테 열어준다.
이제는 browser가 안전하지 않은 요청(unsafe request)는 바로 날리지 않는다. preflight request 를 먼저 날리고 나서 날리게 된다.
200 OK
Content-Type:text/html; charset=UTF-8
Content-Length: 12345
Content-Encoding: gzip
API-Key: 2c9de507f2c54aa1
Access-Control-Allow-Origin: https://javascript.info
Access-Control-Expose-Headers: Content-Encoding,API-Key ┌─► http://localhost:8081
http://localhost:8080 │ ┌─────────────┐
│ │ │
http://localhost:8080/api──┘ │ WAS │
┌─────────────┐ │ │
│ web server │ │ │
│ ┌───────┤ │ │
│ │ │ └─────────────┘
│ │ asset │
│ │ │
└─────┴───────┘ spec , origin이 널 / null 인 경우 / why origin null
origin 값은 opaque origin 또는 tuple origin 인데, tuple origin 이 정상적인 값으로 ‘http://daum.net’ 같은 값이고, opaque origin (이해하기 힘든 origin)은 null 이라고 보면 된다.
The serialization of ("https", "xn--maraa-rta.example", null, null) is "https://xn--maraa-rta.example".아래 링크에서 origin 이 null 이 되는 모든 case 를 이야기 해준다.
fetch 를 한 경우 다른 origin 으로 redirect 하면 null 이 된다.
레디스 / 레디스 대신 사용할 / 세션 공유 / data store / 저장소
microsoft 에서 redis 와 비슷한 cache-store 를 open 했다. Redis serialization protocol (RESP) 를 지원한다.
이쯤, Redis 가 dual license 로 변경했다.
에러 / 장애 / 캐시 / 레디스 이슈 / 레디스 버그 /
쿠팡에서 직접적으로 밝히진 않았지만, 장애원인으로 지목되는 것은 다음 이슈이다.
간략하게 이야기하면 item 을 추가할 때 쓰는 dictAddRaw 함수의 버그이다. long long(64bit) 으로 사용해야 할 index를 int 로 사용해서 문제가 발생했다.