서버측 Swift에 웹 페이지 활용 이야기
어제shalm씨 거예요.
iOS의 React Native에서 한동안 놀았지만, 평소 iOS를 개발하고 있는 저는 스위프트로 쓰려고 합니다(죄송합니다).
하지만 평소 JS에서 열의가 넘치는 사람은 익숙한 언어라면 손쉽게 쓸 수 있다.
오늘도 그랬어.
이것은 무엇이냐
여러분은 어떤 방법으로 자신의 홈페이지를 가지고 어떤 환경에서 진행할 것 같습니까?
나는 익숙한 언어"React Native for Android로 앱을 만들면서 반한 일이라고 해요."로 서버를 쓴다.
다음은 총결산이다.
창고는 여기 있습니다: https://mokumoku.cloud
서버 측 Swift
오랫동안인터넷이라는 URL에서 만들었지만 .net가 뭐야. 그래서 나는 gTLD 일람표.cloud를 봤는데 도메인 이름이'이건'이라고 해서 모쿠모쿠를 생각했다.클라우드를 얻었습니다.
이번 기회에 업데이트를 진행하려고 전체 AWS로 구축하기로 했고 서버 측도 직접 쓰기로 했습니다.
당시 선택한 것은 당연히 스위프트였다.익숙해진 언어 비용도 줄어들고...
잡담
URL이 변경되면 업데이트됩니다.
"https://github.com/mokumoku/MokuMokuCloud"이라는 재미있는 게임 서비스가 있다.
(서버측에서 Node.js를 사용했습니다.)
잡담은 그만두어라
서버 측 스위프트 프레임워크도 전국시대가 많아 사용했다전자 오락기.
IBM에서 제작한 것이기 때문에 Swift 버전이 업그레이드되어도 유지보수됩니다.
AWS로 이동
구성은 이런 느낌.
Kitura
서버 쪽이 전문적이지 않기 때문에 상세한 내용은 제가 사랑을 끊는 것을 허락해 주십시오. 간단하게 말하면 EC2입니다.
ELB는 규모화를 위한 것이 아니라 HTTPS화된 인증서 배치장을 위한 것이다.(물론, Auto Scalling도 가능하지만, 물론 이런 접근 방식도 아니고, 너무 많이 방문해서 떨어져도 곤란한 사람은 없을 것이다. 그러면 된다. 돈도 없다.)
그리고 Code Deploy 같은 서비스가 있기 때문에 GiitHub을 누르면 연결해서 디버깅을 하면 되지만 IAM에 대한 이해가 부족해서 매번 실패할 수도 있습니다.
단순한 라우팅 및 정적 파일을 반환하는 서버
자신의 홈페이지는 정적 HTML만 되돌려주고 솔직히 S3에 넣으면 충분하다.
그러면 달갑지 않으니까 라우트를 통해 URL을 깨끗하게 만들었어요.例： /about.html は /about でアクセスできる
이것은 아래와 같이 쓸 수 있다.
main.swiftprivate func redirectHtml(_ name: String, _ response: RouterResponse) {
do {
response.headers["Content-Type"] = "text/html; charset=utf-8"
let path = "./public/\(name).html"
try response.status(.OK)
.send(fileName: path)
.end()
} catch {
Log.error("Failed to link \(name).html")
}
}
router.get("/about") { request, response, next in
redirectHtml("about", response)
next()
}
예, GET 액세스/about가 있으면 반환about.html만 가능합니다.
이렇게 페이지의 양만 채우고 HTML 파일을 다시 쓰는 처리가 완료됩니다.
뒷말
6개월 동안 아무것도 만지지 않았지만 떨어지지 않고 평화롭게 돌아가고 있었다.
단순히 키타라는 뛰어나 메모리 유출을 유발하지 않았다.
평균 방문량이 2일 정도이기 때문에 부하가 0이다.
AWS를 사용하려면 Swift를 사용할 수 있는 환경은 EC2뿐입니다.그리고 HTTPS를 위해서는 ELB를 세워야 하기 때문에 돈이 많이 든다.
아무것도 하지 않아도 매달 3000엔 정도가 들기 때문에 지갑에 좋지 않다.
진지하게 고찰해 보다
흥미가 너무 적은 웹 페이지를 만들었어도 어떤 일을 해도 결과는 변하지 않을 것 같다상상해 보고 싶어요.
개발의 용이도
스위프트로 개발한 사람이라면 당연히 쉽죠.
하지만 엑스코드를 이용한 개발은 어려울 것 같아서 다른 편집기를 사용할 것 같아요.
프로그램 라이브러리
.
CocoPods와 Carthage를 지원하더라도 SPM에 해당하는 라이브러리는 매우 적습니다.
그럼에도 불구하고 스위프트 JSON, Rx Swift, Alam ofire 등 유명한 곳에는 대응책이 있어 iOS와 마찬가지로 개발할 수 있을 것으로 보인다.
그러나 iOS에 없는 것, 예를 들면 O/R 매핑기와 템플릿 엔진 등은 아직 잘 알려지지 않았기 때문에 인터넷 서비스를 간단하게 만들 수 있는 상태와는 거리가 멀다.
보수성
나는 이것이 서버의 언어라기보다는 서버의 구조라고 생각한다.
하지만 Swift 업데이트가 빠르면 장애가 발생할 수 있습니다.
방금 6개월 동안 아무것도 건드리지 않았다고 썼는데 그 사이에 스와이프는 2.2에서 3.0.1로 바뀌었고 키타도 0.4-1.3으로 바뀌었다.
가벼운 포도 상태여서 API를 처음부터 업데이트하기로 했다.
또한 스위프트의 관리Swift Package Manager(SPM)는 진행되고 있지만 3.0.1은 설치가 안 돼 곤란하다.
(swifttenv를 다시 설치한 후 설치했다)
이처럼 반년 동안 제품에 방치하는 것은 그리 빠르지 않지만, 오랜만에 또 큰 변화가 생겨 두렵다
이런 일이 있기 때문에 업데이트할 때 반드시 꼼꼼히 따라가야 한다.
iOS 앱에서도 스위프트 버전 업그레이드는 빌딩을 통과해야 해 힘들기 때문에 많이 대응하는 게 좋다.
잡담
전기밥 니콘 게임기swiftenv도 있는데 한번 써봐도 될까요?
잡담은 그만두어라
위에서 말한 바와 같이 실용적인 물건을 만드는 데는 시간이 좀 걸릴 것 같지만 스위프트에 웹 페이지를 표시할 수만 있다면 기쁘니 꼭 도전해 보세요.
총결산
자신의 홈페이지는 정적 HTML만 되돌려주고 솔직히 S3에 넣으면 충분하다.
그러면 달갑지 않으니까 라우트를 통해 URL을 깨끗하게 만들었어요.
例： /about.html は /about でアクセスできる
main.swift
private func redirectHtml(_ name: String, _ response: RouterResponse) {
do {
response.headers["Content-Type"] = "text/html; charset=utf-8"
let path = "./public/\(name).html"
try response.status(.OK)
.send(fileName: path)
.end()
} catch {
Log.error("Failed to link \(name).html")
}
}
router.get("/about") { request, response, next in
redirectHtml("about", response)
next()
}
/about가 있으면 반환about.html만 가능합니다.이렇게 페이지의 양만 채우고 HTML 파일을 다시 쓰는 처리가 완료됩니다.
뒷말
6개월 동안 아무것도 만지지 않았지만 떨어지지 않고 평화롭게 돌아가고 있었다.
단순히 키타라는 뛰어나 메모리 유출을 유발하지 않았다.
평균 방문량이 2일 정도이기 때문에 부하가 0이다.
AWS를 사용하려면 Swift를 사용할 수 있는 환경은 EC2뿐입니다.그리고 HTTPS를 위해서는 ELB를 세워야 하기 때문에 돈이 많이 든다.
아무것도 하지 않아도 매달 3000엔 정도가 들기 때문에 지갑에 좋지 않다.
진지하게 고찰해 보다
흥미가 너무 적은 웹 페이지를 만들었어도 어떤 일을 해도 결과는 변하지 않을 것 같다상상해 보고 싶어요.
개발의 용이도
스위프트로 개발한 사람이라면 당연히 쉽죠.
하지만 엑스코드를 이용한 개발은 어려울 것 같아서 다른 편집기를 사용할 것 같아요.
프로그램 라이브러리
.
CocoPods와 Carthage를 지원하더라도 SPM에 해당하는 라이브러리는 매우 적습니다.
그럼에도 불구하고 스위프트 JSON, Rx Swift, Alam ofire 등 유명한 곳에는 대응책이 있어 iOS와 마찬가지로 개발할 수 있을 것으로 보인다.
그러나 iOS에 없는 것, 예를 들면 O/R 매핑기와 템플릿 엔진 등은 아직 잘 알려지지 않았기 때문에 인터넷 서비스를 간단하게 만들 수 있는 상태와는 거리가 멀다.
보수성
나는 이것이 서버의 언어라기보다는 서버의 구조라고 생각한다.
하지만 Swift 업데이트가 빠르면 장애가 발생할 수 있습니다.
방금 6개월 동안 아무것도 건드리지 않았다고 썼는데 그 사이에 스와이프는 2.2에서 3.0.1로 바뀌었고 키타도 0.4-1.3으로 바뀌었다.
가벼운 포도 상태여서 API를 처음부터 업데이트하기로 했다.
또한 스위프트의 관리Swift Package Manager(SPM)는 진행되고 있지만 3.0.1은 설치가 안 돼 곤란하다.
(swifttenv를 다시 설치한 후 설치했다)
이처럼 반년 동안 제품에 방치하는 것은 그리 빠르지 않지만, 오랜만에 또 큰 변화가 생겨 두렵다
이런 일이 있기 때문에 업데이트할 때 반드시 꼼꼼히 따라가야 한다.
iOS 앱에서도 스위프트 버전 업그레이드는 빌딩을 통과해야 해 힘들기 때문에 많이 대응하는 게 좋다.
잡담
전기밥 니콘 게임기swiftenv도 있는데 한번 써봐도 될까요?
잡담은 그만두어라
위에서 말한 바와 같이 실용적인 물건을 만드는 데는 시간이 좀 걸릴 것 같지만 스위프트에 웹 페이지를 표시할 수만 있다면 기쁘니 꼭 도전해 보세요.
총결산
흥미가 너무 적은 웹 페이지를 만들었어도 어떤 일을 해도 결과는 변하지 않을 것 같다상상해 보고 싶어요.
개발의 용이도
스위프트로 개발한 사람이라면 당연히 쉽죠.
하지만 엑스코드를 이용한 개발은 어려울 것 같아서 다른 편집기를 사용할 것 같아요.
프로그램 라이브러리
.CocoPods와 Carthage를 지원하더라도 SPM에 해당하는 라이브러리는 매우 적습니다.
그럼에도 불구하고 스위프트 JSON, Rx Swift, Alam ofire 등 유명한 곳에는 대응책이 있어 iOS와 마찬가지로 개발할 수 있을 것으로 보인다.
그러나 iOS에 없는 것, 예를 들면 O/R 매핑기와 템플릿 엔진 등은 아직 잘 알려지지 않았기 때문에 인터넷 서비스를 간단하게 만들 수 있는 상태와는 거리가 멀다.
보수성
나는 이것이 서버의 언어라기보다는 서버의 구조라고 생각한다.
하지만 Swift 업데이트가 빠르면 장애가 발생할 수 있습니다.
방금 6개월 동안 아무것도 건드리지 않았다고 썼는데 그 사이에 스와이프는 2.2에서 3.0.1로 바뀌었고 키타도 0.4-1.3으로 바뀌었다.
가벼운 포도 상태여서 API를 처음부터 업데이트하기로 했다.
또한 스위프트의 관리Swift Package Manager(SPM)는 진행되고 있지만 3.0.1은 설치가 안 돼 곤란하다.
(swifttenv를 다시 설치한 후 설치했다)
이처럼 반년 동안 제품에 방치하는 것은 그리 빠르지 않지만, 오랜만에 또 큰 변화가 생겨 두렵다
이런 일이 있기 때문에 업데이트할 때 반드시 꼼꼼히 따라가야 한다.
iOS 앱에서도 스위프트 버전 업그레이드는 빌딩을 통과해야 해 힘들기 때문에 많이 대응하는 게 좋다.
잡담
전기밥 니콘 게임기swiftenv도 있는데 한번 써봐도 될까요?
잡담은 그만두어라
위에서 말한 바와 같이 실용적인 물건을 만드는 데는 시간이 좀 걸릴 것 같지만 스위프트에 웹 페이지를 표시할 수만 있다면 기쁘니 꼭 도전해 보세요.
총결산
Reference
이 문제에 관하여(서버측 Swift에 웹 페이지 활용 이야기), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/daichiro/items/9d2f41bdd1795c718e55텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
