| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- Kotlin
- php
- FastAPI
- playwright
- Vite
- 아키텍처
- 소셜로그인
- React
- electron
- 상태관리
- sqlite
- 배포
- 인증
- 메일자동화
- 도메인설계
- REST API
- Android
- 온디바이스AI
- 마이그레이션
- contextBridge
- JWT
- python
- 백엔드
- 크롤링
- next.js
- github actions
- 보안
- javascript
- typescript
- 프론트엔드
- Today
- Total
목록FastAPI (9)
HM소프트
이미지 URL None을 배열로 다뤄 터지는 직렬화 500을, 응답 스키마 검증자 한 곳에서 안전한 기본값으로 정규화해 잡는다. 정적·동적 라우트 순서 함정, JSON 검색을 ILIKE로 되돌린 이유, 하버사인 거리 계산은 파이썬에서, joinedload로 즐겨찾기 N+1 제거, 소셜 ID 매칭 인증까지 다룬다.다시 시작하며 — 못 믿을 데이터를 API로 내보내기1편에서는 외부 화면을 Selenium으로 긁어 DB에 쌓는 크롤러와 스케줄러를 다뤘다. 그 글을 이렇게 끝맺었다 — "이렇게 긁어 온 데이터는 솔직히 지저분하다. 어떤 항목은 좌표가 없고, 어떤 필드는 비어 있다." 이번 편은 바로 그 지저분한 데이터를 사용자에게 제공하는 API 계층의 이야기다.스택은 단순하다. 웹 프레임워크로 FastAPI를..
공개 API가 없는 외부 화면을 Selenium으로 긁는 크롤러 설계. navigator.webdriver 숨기기·UA 무작위화·무작위 지연으로 차단을 피하고, 중첩 iframe 전환과 셀렉터 다단계 폴백으로 화면 개편을 견딘다. 식별자 우선 upsert로 멱등성을, 다층 예외 격리와 정직한 partial 로그로 새벽 수집을 지킨다.시리즈를 시작하며 — 출처가 외부에 있는 서비스지역에 흩어진 시설 정보를 한곳에 모아 검색하고, 즐겨찾기하고, 이용 후기를 모아 보여 주는 서비스를 만들었다. 백엔드(Python)가 데이터를 수집·정제·제공하고, 크로스플랫폼 앱이 그걸 소비하는 구조다. 그런데 이 서비스에는 보통의 CRUD 백엔드와 결정적으로 다른 점이 하나 있었다. 데이터의 출처가 우리 손 밖에 있다는 점이..
BaseCrawler 추상 클래스로 5개 공개 데이터 출처(벌크 API·주간 XML·웹페이지 PDF)를 하나의 수집-파싱-저장 파이프라인에 통합한 설계. fetch/parse 두 메서드만 출처별로 구현하고, Pydantic 공통 모델의 원문/번역 분리, COALESCE UPSERT 중복 제거, 2단계 보강, 건별·출처별 격리, 수집과 번역 분리까지 다룬다.시리즈를 시작하며 — "출처가 5개인데 화면은 하나여야 한다"여러 나라가 각자 공개하는 제품 리콜 데이터를 한곳에 모아, 자동으로 번역하고, 검색·내보내기까지 되는 데스크톱 앱을 만들었다. 한 줄로 줄이면 "공개 데이터 크롤러"지만, 실제로 시간을 잡아먹은 건 크롤링 그 자체가 아니었다. 나라마다 데이터를 주는 방식이 전부 다르다는 점이 모든 설계 결정..