thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 댓글을 남기셨습니다.
thumbnail
물론 직접 해보고 전달해드리는 것이 아니라서 확실한 정보가 아닐 수 있습니다.
@city7310님이 댓글을 남기셨습니다.
thumbnail
감사합니다. 타입 힌팅과 관련해선 [Using boto3 classes in type annotations](https://github.com/boto/boto3/issues/447) 참고하시면 좋을 것 같습니다.
@city7310님이 댓글을 남기셨습니다.
thumbnail
ㅎㅎ 감사합니다.
@city7310님이 댓글을 남기셨습니다.
thumbnail
써야겠다고 리스팅해둔 건 정말 산더미입니다. '백엔드가 이런건 해줘야하지 않나?'하는 것들 생각나는 대로 다 정리해 두었어서.. 말씀하신 부하테스트, 모니터링도 있구요. 그런데 제 지식이 얕은 주제는 잘 알고 나서 써보려고 되도록 뒤로 미루는 것도 있고, 생각해둔 순서도 있고 해서 40챕터 넘어가는 언저리에 쓰게 될 것 같아요.
@city7310님이 댓글을 남기셨습니다.
thumbnail
감사합니다. 아실 수도 있겠지만 프론트엔드 테스트에 cypress 한번 써보세요!
@city7310님이 댓글을 남기셨습니다.
thumbnail
항상 그래왔듯 어설픈 구현으로 공감을 유도하고, 좋은 방향이라 생각하는 곳으로 동기부여하며 이끌어 보려고 합니다. 제 지식이 얕아서 이런 구조가 계속 가능할지는 모르겠네요. ㅎㅎ
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 이 포스트를 좋아합니다.
thumbnail
@city7310님이 댓글을 남기셨습니다.
thumbnail
옛날부터 정말 궁금했던 것인데, 제가 프론트엔드를 안하다 보니 고민 해결을 못한 것이.. SSR이 정말 SEO에 유의미할 정도로 기여를 하나요? 어느 검색 엔진이느냐에 따라 다르긴 하겠지만 클릭률(CTR), 연관 키워드, 백링크(다른 사이트에서 우리 사이트를 가르키는 링크) 갯수, 페이스북에 관련된 것들(공유, 트래픽, 코멘트 등)이 큰 기여를 하는 것으로 알고 있거든요. 검색엔진 크롤러한테만 따로 SSR 시켜주는 기법도 사용되곤 하니 DOM의 컨텐츠가 뭔가를 하긴 할텐데, 그 뭔가가 무엇일지 모르겠어서요. ㅎㅎ
@city7310님이 댓글을 남기셨습니다.
thumbnail
REST가 참.. 생각보다 훨씬 훨씬 훨씬 어렵더라구요. 마치 SMTP가 이메일에서 쓰는 프로토콜이라길래 '아니 뭐 제목이랑 수신자랑 내용 말고 뭐 별거 있겠어?' 싶었는데 MX record고 뭐고 심오한거 엄청 많네 하고 느꼈던 것처럼.. REST한 어플리케이션이라고 말하려면 무조건 HATEOAS를 지켜야 하는데 JSON payload로 request/response하는 요즘 API에선 지키기가 정말 어렵지요. 저는 그냥 HTTP API라고 불러요. REST에 관해선 '[그런 REST API로 괜찮은가](https://slides.com/eungjun/rest#/)'라는 슬라이드가 매우 유명합니다.
@city7310님이 댓글을 남기셨습니다.
thumbnail
그리고 lambda가 free tier 범위가 꽤 커보이고 초당 0.000몇 달러여서 엄청 싸보이는데, 막상 트래픽 많아지고 나면 정말 그렇게 싼 것 같지가 않은 것 같더라구요(그 마지노선이 얼마나 될지는 계산을 안해봐서 모르겠습니다 ㅎㅎ). 트래픽 많아지면 그냥 Beanstalk, ECS같은 프로비저닝된 컴퓨팅 엔진을 쓰는 것이 차라리 비용 효율이 더 좋을 것 같아요.
@city7310님이 댓글을 남기셨습니다.
thumbnail
serverless.js에서도 발생하는 현상일지 모르겠는데, Python에선 WSGI 어플리케이션을 lambda에 배포할 수 있도록 돕는 zappa라는 것이 있어서 조심해야 할만한 부분들을 조금 첨언하자면, 1. IAM Role을 지 입맛대로 수정해버립니다. 특히 배포 할때마다 trust relationship 바꿔버리는 것 때문에, 거기에 물려 있던 ECS 클러스터가 AssumeRole 실행 못하고 에러 뿜어버리는 경우가 있었습니다. 2. 5분마다 생기는 cold start는 keep warm해주면 되는 건데, 배포 직후의 cold start 현상은 zappa 단에서 해결할 수 없었습니다. 이를 해결하기 위한 방법 중 하나는, lambda function에 alias를 만들어 두고, API Gateway에서는 alias된 함수의 arn을 가르키도록 설정해둔 상태에서, 배포 파이프라인을 다음과 같이 변경하면 됩니다 : `배포(UpdateFunctionCode) -> warm해지도록 함수 호출(lambda invoke) -> API Gateway에 물려 뒀던 alias가 가르키는 버전 변경` serverless.js는 API Gateway가 가르킬 function arn을 직접 설정할 수 있을런지 모르겠지만, zappa는 그렇지가 않아서.. 3. API Gateway는 response body size가 5MB를 넘기면 500번대 에러를 뿜습니다. response size가 크다면 gzip을 사용하는 것이 이로울 것 같습니다. 4. 코드 실행의 context가 모두 실행될 것을 보장받지 못합니다. Flask의 경우 요청부터 응답 후까지의 context를 모두 라이브러리 단에서 helper화 시켜 두었는데, '응답 후'에 대한 콜백이 lambda에선 실행되지 않더라구요. Elastic APM의 Flask extension이 그걸 쓰는데, 메트릭이 제대로 넘어가지 않아서 삽질했던 기억이 있습니다.
@city7310님이 댓글을 남기셨습니다.
물론 Lambda에서 SSR을 할 수도 있습니다! https://dev.to/adnanrahic/a-crash-course-on-serverless-side-rendering-with-reactjs-nextjs-and-aws-lambda-13ed