앞으로 Svelte 를 학습해서 활용할 부분

Golang 기반의 Wails + Svelte + tailwind

Rust 기반의 Tauri + Svelte 

개발 언어들이 너무 짧은 주기에 좋은것들이 계속 나오니 정신을 못차리겠다.

학습을 해야 하는데 언어자체의 장점보다는 시장성을 빼놓을 수 없어서 Svelte를 배워둔다면 언제 써먹을지도 모를일이다.

Flutter도 이제 치고 들어오는데 React나 Svelte를 제껴두고 넘어가야되나 고민도 된다.

일단 한가지를 잡고 끝까지 완주해야 할텐데 어는걸 잡아서 하는게 맞을까?

정말... 시장성이 있는 React를 해야 하는건가? 아 골아프네.

Rust는 어떤 면에서는 굉장합니다. 그러나 빠르게 움직여야 하는 스타트업을 선택하기 전에 두 번 고려하세요.

나는 프로그래밍 언어에 대한 성전을 시작하거나 시작하고 싶지 않기 때문에 이 글을 쓰는 것을 주저했습니다. (불길한 미끼를 없애기 위해 Visual Basic은 최고의 언어입니다!) 그러나 많은 사람들이 Rust에 대한 나의 경험과 프로젝트에 Rust를 선택해야 하는지 여부를 묻습니다. 그래서 저는 빠르게 움직이고 팀을 확장하는 것이 정말 중요한 스타트업 환경에서 Rust를 사용하는 것에 대해 제가 본 장단점을 공유하고 싶습니다.

나는 특정한 것에 대해 Rust의 팬임을 분명히 하고 싶습니다 . 이 게시물은 Rust가 언어로서 얼마나 나쁜지에 대한 것이 아닙니다. 그러나 내가 말하고 싶은 것은 Rust를 사용하는 것이 당신이 빨리 움직이려고 한다면 주요 요인이 될 수 있는 사소하지 않은 생산성 타격을 거의 확실하게 수반할 것이라는 점입니다. 속도 영향이 회사 및 제품에 대한 언어의 이점만큼 가치가 있는지 신중하게 평가하십시오.

바로 앞에, Rust는 설계된 일에 매우 뛰어나며 프로젝트에 Rust의 특정 이점(고성능, 초강력 타이핑, 가비지 수집이 필요 없는 시스템 언어 등)이 필요한 경우에 말해야 합니다. 그런 다음 Rust는 훌륭한 선택입니다. 그러나 저는 Rust가 그다지 적합하지 않은 상황에서 자주 사용되며 팀은 많은 이점을 얻지 못한 채 Rust의 복잡성과 오버헤드의 대가를 지불한다고 생각합니다.

Rust에 대한 나의 주된 경험은 이전 스타트업에서 2년 조금 넘게 일하면서 얻은 것입니다. 이 프로젝트는 클라우드 기반 SaaS 제품으로, 거의 기존의 CRUD 앱에 불과했습니다. 데이터베이스 앞에 REST 및 gRPC API 엔드포인트를 제공하는 마이크로서비스 집합과 기타 일부 백-서비스입니다. 최종 마이크로서비스(자체는 Rust와 Python의 조합으로 구현됨). Rust는 주로 회사 창립자 두 명이 Rust 전문가였기 때문에 사용되었습니다. 시간이 지나면서 우리는 팀을 상당히 성장시켰고(엔지니어링 인원을 거의 10배 늘림) 코드베이스의 크기와 복잡성도 상당히 커졌습니다.

팀과 코드베이스가 성장함에 따라 시간이 지남에 따라 Rust를 계속 사용하는 데 점점 더 많은 세금을 내고 있다고 느꼈습니다. 때때로 개발이 느렸고, 새로운 기능을 출시하는 데 예상보다 오래 걸렸으며, 팀은 Rust를 사용하기로 한 초기 결정으로 인해 실질적인 생산성 저하를 느꼈습니다. 다른 언어로 코드를 다시 작성하면 장기적으로 개발이 훨씬 더 민첩해지고 전달 시간이 빨라지지만 주요 재작성 작업을 위한 시간을 찾는 것은 매우 어려웠을 것입니다. 그래서 우리는 총알을 깨물고 많은 양의 코드를 다시 작성하기로 결정하지 않는 한 Rust에 갇혀 있었습니다.

녹은 얇게 썬 빵 이후로 가장 좋은 것으로 여겨졌는데 왜 우리에게는 잘 작동하지 않았습니까?

Rust는 엄청난 학습 곡선을 가지고 있습니다.

나는 내 경력에서 수십 개의 언어로 작업했으며 거의 ​​예외 없이 대부분의 현대적이고 절차적인 언어(C++, Go, Python, Java 등)는 모두 기본 개념 측면에서 매우 유사합니다. 각 언어에는 차이점이 있지만 일반적으로 언어마다 다른 몇 가지 주요 패턴을 학습한 다음 매우 빠르게 생산적일 수 있습니다.그러나 Rust를 사용하려면 배워야 합니다.완전히 새로운 아이디어— 수명, 소유권 및 차용 검사기와 같은 것. 이는 다른 공통 언어로 작업하는 대부분의 사람들에게 친숙한 개념이 아니며 숙련된 프로그래머에게도 상당히 가파른 학습 곡선이 있습니다.

이러한 "새로운" 아이디어 중 일부는 물론 다른 언어, 특히 기능적인 언어에 존재하지만 Rust는 이러한 아이디어를 "주류" 언어 설정으로 가져오므로 많은 Rust 초보자에게 생소할 것입니다.

내가 함께 일했던 가장 똑똑하고 경험이 많은 개발자였음에도 불구하고 팀의 많은 사람들(나 자신 포함)은 Rust에서 특정 작업을 수행하는 정식 방법, 컴파일러에서 종종 난해한 오류 메시지를 파악하는 방법 또는 핵심 라이브러리가 작동하는 방식을 이해하는 방법(자세한 내용은 아래 참조). 우리는 팀이 지식과 ​​전문 지식을 공유하는 데 도움이 되도록 매주 "Rust 학습" 세션을 갖기 시작했습니다. 모두가 느린 개발 속도를 느꼈기 때문에 이것은 모두 팀의 생산성과 사기를 크게 떨어뜨렸습니다.

소프트웨어 팀에서 새로운 언어를 채택하는 것이 어떤 것인지 비교하기 위해 Google의 한 팀은 C++에서 Go로 완전히 전환한 최초의 팀 중 하나였습니다. 15명 정도의 팀이 처음으로 Go로 꽤 편안하게 코딩했습니다. Rust를 사용하면 매일 몇 달 동안 언어로 작업한 후에도 팀의 대부분의 사람들이 완전히 유능하다고 느끼지 못했습니다. 많은 개발자들이 자신의 기능이 착륙하는 데 예상보다 오래 걸리고 Rust를 이해하는 데 너무 오랜 시간을 소비하고 있다는 사실에 종종 당혹스럽다고 말했습니다.

Rust가 해결하려는 문제를 해결하는 다른 방법이 있습니다.

위에서 언급했듯이 우리가 구축한 서비스는 상당히 간단한 CRUD 앱이었습니다. 이 서비스에 대한 예상 부하는 이 특정 시스템의 수명 동안 최대 초당 몇 개의 쿼리를 넘지 않을 것입니다. 이 서비스는 실행하는 데 많은 시간이 걸릴 수 있는 상당히 정교한 데이터 처리 파이프라인의 프런트엔드였으므로 서비스 자체가 성능 병목 현상이 될 것으로 예상되지 않았습니다. Python과 같은 기존 언어가 좋은 성능을 제공하는 데 문제가 있을 것이라는 특별한 우려는 없었습니다. 웹 대면 서비스가 처리해야 하는 것 외에 특별한 안전이나 동시성 요구 사항은 없었습니다. 우리가 Rust를 사용한 유일한 이유는 시스템의 원래 작성자가 Rust 전문가였기 때문이지 이런 종류의 서비스를 구축하는 데 특히 적합했기 때문이 아닙니다.

Rust는 개발자 생산성보다 안전이 더 중요하다는 결정을 내렸습니다. 이것은 OS 커널에서 코드를 작성하거나 메모리가 제한된 임베디드 시스템과 같은 많은 상황에서 올바른 절충안이지만 모든 경우에 올바른 절충안이라고 생각하지 않습니다. 특히 속도가 중요한 스타트업에서는 그렇지 않습니다. 나는 실용주의자입니다. 팀의 모든 구성원이 이러한 문제를 완전히 방지하도록 설계된 언어를 사용하여 생산성이 4배 저하되는 것보다 팀에서 가끔 발생하는 메모리 누수 또는 Python 또는 Go로 작성된 코드의 유형 오류를 디버깅하는 데 시간을 할애하는 편이 낫 습니다 . .

위에서 언급했듯이 Google 팀은 전적으로 Go로 서비스를 구축했으며 시간이 지남에 따라 8억 명 이상의 사용자와 Google 검색 QPS의 4배 정도를 지원하는 수준으로 성장했습니다. 이 서비스를 구축하고 실행하는 동안 Go의 유형 시스템이나 가비지 컬렉터로 인해 발생한 문제에 부딪힌 횟수는 한 손으로 셀 수 있습니다. 기본적으로 Rust가 피하도록 설계된 문제는 좋은 테스트, 좋은 린팅, 좋은 코드 검토, 좋은 모니터링 등 다른 방법으로 해결할 수 있습니다. 물론 모든 소프트웨어 프로젝트가 이러한 사치를 누리는 것은 아니므로 다른 상황에서는 Rust가 좋은 선택이 될 수 있다고 상상할 수 있습니다.

Rust 개발자를 고용하는 데 어려움을 겪을 것입니다.

우리는 이 회사에 있는 동안 수많은 사람들을 고용했지만 엔지니어링 팀에 합류한 60명 이상의 사람들 중 약 2~3명만이 Rust에 대한 이전 경험이 있었습니다. 이것은 Rust 개발자를 찾기 위한 노력이 부족해서가 아닙니다 — 그들은 단지 거기에 없을 뿐입니다. (동일한 이유로 우리는 Rust 로만 코딩하기를 원하는 사람들을 고용하는 것을 주저했습니다 . 언어 및 기타 기술 선택이 민첩한 방식으로 이루어져야 하는 스타트업 환경에서 설정하는 것은 나쁜 기대라고 생각하기 때문입니다.) Rust가 더 주류가 됨에 따라 Rust 개발 인재의 수는 시간이 지남에 따라 변할 것입니다.

또 다른 두 번째 요인은 Rust를 사용하면 팀에서 Rust를 아는 사람들과 그렇지 않은 사람들 사이에 분열이 생길 것이 거의 확실하다는 것입니다. 우리는 이 서비스를 위해 "난해한" 프로그래밍 언어를 선택했기 때문에 기능 구축, 생산 문제 디버깅 등에 도움이 되었을 수 있는 회사의 다른 엔지니어들은 대체로 도움을 줄 수 없었습니다. Rust 코드베이스의 꼬리. 엔지니어링 팀의 이러한 대체 가능성 부족은 빠르게 움직이고 팀의 모든 구성원의 결합된 강점을 활용하려고 할 때 실질적인 문제가 될 수 있습니다. 내 경험상, 사람들은 일반적으로 C++와 Python 같은 언어 사이를 이동하는 데 거의 어려움이 없지만 Rust는 충분히 새롭고 복잡해서 사람들이 함께 작업하는 데 장벽이 됩니다.

라이브러리와 문서는 미성숙합니다.

이것은 (희망합니다!) 시간이 지나면 해결되겠지만 Go와 비교할 때 Rust의 라이브러리와 문서화 생태계는 믿을 수 없을 정도로 미숙합니다. 이제 Go는 전 세계에 출시되기 전에 Google의 전체 전담 팀에서 개발하고 지원했다는 이점이 있으므로 문서와 라이브러리가 상당히 세련되었습니다. 이에 비해 Rust는 오랫동안 진행 중인 작업처럼 느껴졌습니다. 많은 인기 있는 라이브러리에 대한 문서가 매우 드물고 사용 방법을 이해하기 위해 특정 라이브러리 의 소스 코드 를 읽어야 하는 경우가 많습니다 . 이것은 나쁘다.

팀의 Rust 사과론자들은 종종 "async/await는 여전히 정말 새롭습니다." 및 "예, 해당 라이브러리에 대한 문서가 부족합니다."와 같은 말을 하지만 이러한 단점은 팀에 상당한 영향을 미쳤습니다. 우리는 서비스의 웹 프레임워크로 Actix를 채택함으로써 초기에 큰 실수를 저질렀습니다. 그 결정은 아무도 수정 방법을 알아낼 수 없는 라이브러리 깊숙이 묻혀 있는 버그와 문제에 부딪히면서 엄청난 고통과 괴로움을 초래했습니다. (공평하게 말하면 이것은 몇 년 전의 일이고 지금은 상황이 개선되었을 수 있습니다.)

물론 이런 종류의 미숙함은 실제로 Rust에만 국한된 것은 아니지만 팀이 지불해야 하는 세금에 해당합니다. 핵심 언어 문서와 자습서가 아무리 훌륭하더라도 라이브러리 사용 방법을 알 수 없다면 별 문제가 되지 않습니다(물론 처음부터 모든 것을 작성하려는 경우가 아니라면).

Rust는 새로운 기능을 대략적으로 만드는 것을 매우 어렵게 만듭니다.

나는 다른 사람에 대해 모르지만 적어도 나에게는 새로운 기능을 구축할 때 일반적으로 모든 데이터 유형, API 및 기타 세부 정보가 먼저 작동하지 않습니다. 나는 종종 몇 가지 기본 아이디어가 작동하도록 노력하고 일이 어떻게 작동해야 하는지에 대한 내 가정이 다소 정확한지 확인하려고 코드를 작성합니다. 예를 들어 Python에서 이 작업을 수행하는 것은 매우 쉽습니다. 타이핑과 같은 작업을 빠르고 느슨하게 수행할 수 있고 아이디어를 대략적으로 작성하는 동안 특정 코드 경로가 손상되더라도 걱정할 필요가 없기 때문입니다. 나중에 돌아가서 모든 것을 깔끔하게 만들고 모든 유형 오류를 수정하고 모든 테스트를 작성할 수 있습니다.

Rust에서 이런 종류의 "초안 코딩"은 매우 어렵습니다. 왜냐하면 컴파일러 는 유형 및 수명 검사를 통과하지 못하는 빌어먹을 모든 것에 대해 불평할 수 있고 불평할 것이기 때문 입니다. 이것은 생산 준비가 된 최종 구현을 구축해야 할 때 완벽하게 이해되지만 아이디어를 테스트하거나 기본 기반을 마련하기 위해 무언가를 함께 짜내려고 할 때 절대적으로 짜증납니다. 매크로는 어느 정도 도움 이 unimplemented!되지만 여전히 컴파일하기 전에 스택에서 모든 유형을 확인해야 합니다.

정말 짜증나는 것은 로드 베어링 인터페이스의 유형 서명을 변경해야 하고 유형이 사용되는 모든 장소를 변경하는 데 시간을 소비하여 무언가에 대한 초기 찌르기가 가능한지 확인하는 것입니다. 그런 다음 다시 변경해야 한다는 것을 깨달았을 때 모든 작업을 다시 실행합니다.

러스트는 무엇을 잘하나요?

Rust에 대해 제가 좋아하는 점과 다른 언어로 갖고 싶은 Rust의 기능이 분명히 있습니다. match구문이 훌륭합니다 . , 및 특성은 정말 강력하며 Option연산자 는 오류를 처리하는 우아한 방법입니다. 이러한 아이디어 중 많은 부분이 다른 언어로 된 대응물을 가지고 있지만 Rust의 접근 방식은 특히 우아합니다.ResultError?

나는 높은 수준의 성능과 안전성이 필요하고 빠르게 성장하는 전체 팀과 함께 코드의 주요 부분을 빠르게 발전시켜야 할 필요성에 대해 크게 걱정하지 않는 프로젝트에 Rust를 절대적으로 사용할 것입니다. 개별 프로젝트나 매우 작은(예: 2-3명) 팀의 경우 Rust가 적합할 것입니다. Rust는 성능과 안전이 가장 중요한 커널 모듈, 펌웨어, 게임 엔진 등과 같은 것들과 출하 전에 철저한 테스트를 수행하기 어려울 수 있는 상황에서 훌륭한 선택입니다

[원본]

https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454

학습 시작

글을 읽는 분들에게 미안한 마음이 들지만 앞단에 진행되던 내용들도 뭐 나름 의미가 있기는 하다.
003 글 마지막에 template 기본을 만들어주는 기능을 발견하고 바로 작성하던 글을 종료시켰다. 그럼 새롭게 알아낸 방법으로 template를 만들어보기로 하자.
https://wails.io/docs/guides/templates/

01. 템플릿 기본 생성하기

아주 간단히 template 기본 틀을 생성할 수 있다.

wails generate template -name {프로젝트명}
ex)
wails generate template -name wails-vite-sveltekit-ts-tailwind-template

앞에서 등록한 글들에서 본 폴더/파일 구조와 별반 다르지 않다고 느낄 수 있는데 자세히 보면 설정 파일들의 파일명이 다르다는 걸 알 수 있다.
package.tmpl.json
, app.tmpl.go
, go.tmpl.go
, main.go.tmpl
, wails.tmpl.json
이렇게 tmpl이라는 문구가 추가되어 생성되어 있다.

대표적으로 wails.tmpl.json 파일을 오픈해보면 변경될만한 정보들이 {{ }} 로 감싸져 있는 걸 볼 수 있다. 이 부분이 -t 옵션으로 프로젝트를 생성하게 되면 상황에 맞는 값들이 대입되어 온전한 wails.json 파일이 생성되게 된다.
그런데 template 프로젝트를 생성 후 frontend 폴더를 보면 frontend 소스가 없고 dist 폴더와 package.tmpl.json 만 있는 걸 볼 수 있다. dist는 frontend 폴더에 개발을 하면 빌드 시 재 구성되는 부분이라 확인할 필요가 없고 package.tmpl.json은 개발에 사용할 의존 모듈들에 대한 정의들이 정의된 설정 파일이다. 개발된 샘플 소스가 없다.
template 프로젝트를 생성할 때 -frontend 옵션이 있는데 별도로 구성된 javascript 프로젝트를 frontend로 포함시켜서 템플릿을 완성시켜 주는 기능이 포함되어있다.
나는 sveltekit + vite +typescript + tailwind 를 사용할 예정이므로 이 네 가지를 적용한 프로젝트를 별도로 만들어보겠다.

일단 앞에서 샘플로 생성한 폴더를 삭제한다.

rmdir /s /q wails-vite-sveltekit-ts-tailwind-template

02. Frontend 기술 적용된 프로젝트 만들기
https://kit.svelte.dev/docs/introduction

sveltekit을 설치하기 위해 사이트에 접속해 보자.
그럼 다음 내용을 확인할 수 있다.

나는 npm을 사용하지 않고 pnpm을 사용할 것이므로 위 내용과는 조금 다르게 프로젝트를 생성하겠다.

pnpm create svelte@latest sveltekit-template

문답형 설치가 진행된다.

Skeleton Project로 템플릿을 생성하니 너무 없어 보여서 SvelteKit demo app으로 선택하기로 한다.

Typescript 를 사용할 예정이므로 두 번째 항목을 선택한다 (본인이 만들 템플릿에 따라서 선택하면 된다. No는 VanillaJS를 의미한다.)

ESLint (Option)
Prettier (Option)
Playwright (Option)
위 세 가지 선택 여부를 결정하고 프로젝트를 생성한다. (위 3가지는 검색해서 한번 알아보도록 하자)

프로젝트가 생성되면서 다음 절차를 통해서 실행해볼 수 있다는 문구가 나타난다. (npm을 pnpm으로 바꾸고 pnpm에서는 run 명령어를 생략해도 되므로 run을 생략하고 실행해보자(4 번에서)
그리고 git 사용 여부는 본인 선택이므로 사용할 거면 git 설치 부분을 학습하고 설치 후 3번을 진행하도록 한다. 단 지금은 템플릿을 만드는 단계이므로 맨 마지막에 진행해도 상관없을 것 같으므로 지금은 3번은 스킵하도록 한다.

cd sveltekit-template
pnpm install
pnpm dev -- --open

pnpm install 실행 중 corepack을 통한 update를 하라고 하는데 지금 정확히 잘 모르겠다. 추후 알게 되면 해당 글에 업데이트하도록 하겠다.

다음과 같이 devDependencies에 의존성 모듈들이 추가되었다고 나타난다. 모두 최신 버전인 것 같다.
(Skeleton 으로 생성했을 때와는 의존성 모듈 구성이 조금 틀리니 이상하다고 겁먹지 말자)
이제 정상적으로 구동이 되는지 실행해보자.
pnpm dev -- --open

크롬 브라우저를 실행 후 Local에 있는 주소를 복사해서 붙여 넣어 보자.

정상적으로 실행되는 걸 확인했다.
이번에 사용할 기술들 중 3가지가 해결되었다.
Sveltekit + Vite + Typescript
다음으로 Tailwind css 프레임워크를 추가해보자.
https://tailwindcss.com/docs/guides/sveltekit

8 단계로 설명해 놓았는데 1단계는 이미 처리된 거고 2단계부터 적용해보자

항상 유의해야 할 부분이 npm을 사용하지 않고 pnpm을 사용하는 거다.

pnpm install -D tailwindcss postcss autoprefixer svelte-preprocess

devDependencies가 추가되었는데 svelte-preprocess 부분은 이미 등록되어 있어서 누락되었다.

pnpx tailwindcss init tailwind.config.cjs -p

두 가지 cjs 파일이 생성되었다.
이제 사용할 모든 프레임워크와 모듈이 추가되었으므로 wails 템플릿을 다시 만들어보자.

02. frontend Project로 wails template 생성하기

cd ..
wails generate template -name wails-vite-sveltekit-ts-tailwind-template -frontend ./sveltekit-template

sveltekit-template 폴더 상위로 이동한 후 template 을 생성해보자.

정상적으로 생성되었다.
알기 전까진 꽤 어렵게 생각되었는데 구조를 알고 나니 큰 어려움 없이 사용자 Template를 생성할 수 있었다.
그렇지만 아직 끝난 게 아니다.
일단 템플릿 형태이기 때문에 wails build 해서 바로 실행할 수 있는 구조가 아니다 . wails 의 -t 옵션을 통해서 프로젝트를 생성해 줘야 정상적인 값이 설정된 프로젝트가 생성되기 때문이다.
그리고 wails로 template를 생성하면 기본적으로 npm을 사용하는 구조로 생성된다.
그래서 wails.tmpl.json 파일을 열어서 npm 부분을 수정해주자.

다른 템플릿들을 보면

다음과 같은 옵션들이 있는데 추가해주자 : 추가하지 않으니 실행이 안된다.
두 번째 template.json 파일 내용을 수정하도록 한다.

내용을 보고 자신에게 맞는 구성으로 수정해서 등록하도록 한다.
READMD.md 파일과 NEXTSTEPS.md 같은 파일들을 자신에 맞게 수정 후 저장한다.
자 일단 github에 올려보자. open 할 template이기 때문에 Repository 등록할 때 public으로 등록해야 한다.
git을 잘 사용하시는 사람은 git 명령어로 빠르게 처리해도 좋고 좀 미숙한 사람들은 VSCode에 있는 기능을 이용해 자신의 Repository에 등록하면 된다.

Initialize Repository 버튼을 클릭하면 현재 Project에 git init 가 실행되어 git 적용 환경이 된다.

상단 Message 부분에 "Initialize Template" 를 입력하고 Commit 버튼의 오른쪽 화살표를 클릭해 Commit & Sync 항목을 클릭한다.

3개 파일이 저장이 안 되었다고 저장 후 Commit을 진행한다고 한다. 각자 상황에 따라 메시지가 다를 테니 적절히 대처한다.

public repository를 선택한다.

저장소가 없던 게 생겼다. 그렇지만 클릭해 보면 정상적으로 소스가 upload가 안되었을 것이다.
다시 한번 Message 부분에 "initialize template" 등록 후 commit & Sync 버튼을 클릭해보자

여차저차 해서 정상적으로 개인 github에 등록이 되었다.
github에 관한 내용은 음.. VSCode로던지 직접 git 명령어로 등록하던지 별도로 학습해서 적용해보도록 하자. VSCode로 적용하는 게 생각보다 쉬우니 적용해보자.
이제 Template가 github에 등록이 되었으니 wails 의 -t 옵션으로 정상적으로 프로젝트를 생성할 수 있는지 확인해 본다.
공식적인 template가 아니므로 github 저장소 주소를 가져와서 프로젝트를 생성해야 한다.

주소를 복사해둔다.

wails init -n graduateapp -t https://github.com/dofstar/wails-vite-sveltekit-ts-tailwind-template.git

프로젝트가 정상적으로 생성되었다. 파일명도 tmpl 명칭이 빠졌고 설정값들도 정상적으로 적용되어 있다.
이제 구동이 되는지 확인해보자.
VSCode에서 Ctrl + ` 를 이용하면 TERMINAL을 사용해 CMD 를 사용하는 것과 같은 기능을 사용할 수 있다.

wails build

실행하면 wails build 부터 frontend 부분 빌드 및 번들링까지 해서 exe파일을 생성해준다.
그렇지만 지금은 exe파일을 실행하는 게 목적이 아니라 build를 통해 build, frontend/dist, frontend/node_modules 등등의 생성 폴더/파일이 필요해서이다. dist 폴더와 내부 파일들이 없으면 wails가 정상적으로 구동이 안된다. 이유는 main.go 에 설정되어있는 assets 부분 때문인데 추후 내용을 설명하기로 하겠다.
일단 build가 오류 없이 정상적으로 진행되어 종료되었다.
그럼 TERMINAL 창에 다음 명령어를 실행해보자.

wails dev

필요한 부분 빌드가 다시 진행되고 wails 프로그램이 실행되면서 sveltekit 내용이 wails에서 구동되면 완료이다!!!
빌드 후 실행이 안된다..
뭐가 문젠가..??
늦은 밤이라 내일 다시 확인해보기로 하겠다. 잘되는 것 같아 기분 좋았는데 갑자기 급우울이 오네.
=========================================================
문제점을 찾았다. wails.json 파일에

  "frontend:dev:watcher": "pnpm dev",
  "frontend:dev:serverUrl": "auto",

두 가지 항목을 추가해주자.
wails dev 실행하면 정상적으로 실행되는 걸 볼 수 있을 것이다.
기능들을 많이 넣다 보니 소스가 너무 복잡하다.
역시나 우려했던 대로 오픈소스 진영 프로젝트는 설정 지옥이 되는 게 어쩔 수가 없다.
설정을 한 곳으로 모으는 무언가가 있었으면 좋겠는데 좀 아쉽다.
마지막으로 tailwind를 사용하기 위한 설정은 적용되어 있는데 어떻게 적용해서 사용하는지 확인이 되지 않았다.
app.css 파일 추가 및 설정
layout.svelte 파일에 import 설정 추가
page.svelet 파일에 html 표현하기

3가지 적용에 대한 설명이 누락되었는데 너무 늦어서 일단 자야겠다.
사실 여기서 Template 만드는 방법은 종료를 해야겠다.
일단 시간이 없어서 개발을 우선순위로 둬야 하기 때문이다. 불필요한 파일 삭제는 마무리되었지만 설명 파일들 update도 해야 하고 잔잔하게 소스들 수정을 해야 완전히 끝나긴 하겠지만 지속적으로 조금씩 업데이트를 해나가는 방법으로 진행해야겠다.
자 그럼 이제부터 본격적으로 Graduate App을 만들어보도록 하자.
https://devguru.tistory.com/27?category=588709

[corepack 에 대한 설명]
https://luvstudy.tistory.com/188

github Repository를 만들고 회사에서 테스트겸 템플릿 다운을 받으려고 했더니 SSL 문제 떄문에 프로젝트 생성이 안되는 문제가 확인되었다. 보안적으로 많은 부분이 막혀있는 곳이라 좀 문제가 많은데 wails init 를 통해 템플릿 형태로 프로젝트 생성하는건 허용이되고 있다. 이게 어떤 이유로 되는지는 잘 모르겠다. 뭐 그부분까지 확인하려면 많은부분들을 확인해보고 알아봐야 하는데 템플릿을 만드는 주제와는 무관하므로 스킵하도록 하겠다. 그래서 왜 -t 옵션으로 프로젝트 생성을 못하는지 확인을 해보니 다음 설정파일이 누락되어 있어서 안되고 있는걸 확인했다.

template.json을 추가해서 내용을 등록했다.

{
    "name": "Wails + Vite + Sveltekit + Typescript + TailwindCSS template",
    "shortname": "wails-vite-sveltekit-ts-tailwind-template",
    "author": "dofstar(dofstar@gmail.com)",
    "description": "Wails + Vite + Sveltekit + Typescript + TailwindCSS template",
    "helpurl": "https://github.com/dofstar/wails-vite-sveltekit-ts-tailwind-template"
  }

파일을 추가 후 wails init 명령어로 프로젝트를 생성해보니 정상적으로 생성되었다.

이 template.json 설정파일의 내용은 추후에 어떤 용도로 사용될지 설명을 할텐데 일단 등록해두자.

자 템플릿 만들기 002 까지는 불필요한 파일들 싹 지우고 액기스 파일들만 남겨두고 순수 설정파일과 소스 파일들만 남겨뒀다.

Wails + Vite 설정만 되어있는 구조인데 이제 사용할 프레임워크들을 추가해보도록 하자.

frontend의 핵심 기술인 Sveltekit 과 Typescript 를 추가해보도록 하자.

frontend 폴더를 새롭게 교체하게 될텐데....

==============

헉.. wails 명령어에 template 기본을 생성해주는 기능이 있다.

그렇다면 제공된 기능을 최대한 사용하는 구조로 템플릿을 만들어봐야지!!

-- 끝

01. Wails 기본 프로젝트 생성

다른 모듈들이 추가되지 않은 순수 Wails 프로젝트를 생성하자.

wails init -n wails-vite-sveltekit-ts-tailwind-template

cd wails-*

git init

(tip) cd 명령어에서 아스트링크(*)를 사용하게되면 뒤의 단어들을 생략할 수 있다.
Project Templete 를 보면 vanilla 라고 되어 있는데 흔히들 바닐라JS 라고 하면 Javascript 기본을 바닐라JS라고 한다.
git init는 git이 설치되어 있다면 적용할 수 있다. 

현재 기준으로 wails 프로젝트를 생성하게되면 다음과 같은 폴더 구조를 가지게 된다.

폴더와 config 파일들을 자세하게 파보도록 하자.

최상위 폴더에는 다음 파일들이 있다.

.gitignore : git에서 소스관리를 하지 않을(ignore 할) 필터링 내용이 등록되어 있다.
wails.json : wails 에서 관리되는 설정
README.md : 프로젝트 설명 파일
go.mod : go 에서 사용할 dependency 정보 설정
go.sum : go 에서 사용하는 dependency 별 체크섬을 기록해두고 변조 여부를 검사하는데 사용
main.go : wails 실행 시 최초로 실행되는 main 함수가 포함되어 있는 source
app.go : main에서 호출 해서 사용할 사용자 정의 함수들이 포함되어 있는 source

기본적으로 Root에는 다음과 같이 source가 세팅된다.

기본으로 설정된 프로젝트에서 각종 config 파일들을 변경해줘야 하는데 먼저 wails.json 파일을 수정하도록 하자.

초기 설정은 npm을 사용하게 되어 있다. 하지만 성능적인 부분이나 디스크 공간을 효율적으로 사용하는 pnpm을 사용하도록 한다.

{
  "name": "wails-vite-sveltekit-ts-tailwind-template",
  "outputfilename": "wails-vite-sveltekit-ts-tailwind-template",
  "frontend:install": "pnpm install",
  "frontend:build": "pnpm build",
  "frontend:dev:watcher": "pnpm dev",
  "frontend:dev:serverUrl": "auto",
  "author": {
    "name": "noname",
    "email": "noname@gmail.com"
  }
}

go.mod 파일을 열어보자

mod 파일의 상단 부분에 go version을 1.19 버전으로 수정하고 wails 버전을 가장 최근에 update된 v2.1.0 버전으로 수정하자.

go 1.19

require github.com/wailsapp/wails/v2 v2.1.0

그런데 wails 버전을 v2.1.0으로 수정하더라도 Wails CLI 버전이 자동으로 변경되지 않는다.

wails update

실행해서 Wails CLI 버전을 update 해준다.

이미 업데이트 된 상태에서 실행한거라 내용이 좀 다를 수 있지만 Latest Release 가 v2.1.0 버전이면 정상이니 넘어가도록 하자.

wails update 하게되면 require 부분의 버전들도 자동적으로 변경되는지 확인을 안해봤는데 크게 중요한거 아니니 궁금해서 미칠것 같다면 변경전 내용과 변경후 버전을 캡쳐해서 비교해봐도 좋다.

자.. 이렇게 root 부분의 수정할 파일들을 모두 살펴보았다.

다음은 wails의 frontend 부분 소스가 담겨있는 frontend 폴더를 살펴보자.

우선 가장 기본이 되는 설정이 있는 package.json 파일을 살펴보자

가장 기본적인 Wails 프로젝트를 생성했기 때문에 dependencies 에 설정된게 거의 없다.

Vite 가 기본적으로 설정되어 있다.

• 빠른 번들링
• HMR (Hot Module Replacement) 기능

https://vitejs-kr.github.io/guide/

이 템플릿은 가장 최신 버전으로만 설정될 것이므로 Vite 버전을 변경해주자.

VS Code 에서 devDependencies 에 등록되어 있는 참조모듈의 버전을 변경하는 방법은 다음과 같다.

이미 버전을 확실히 알고 있다면 직접 입력해도 된다. 그렇지만 최신 버전이 정확히 모를 경우

"Vite" : "^2.9.9"  에서 ": 부터 라인 끝까지 삭제 한후 ":"을 입력하고 Ctrl + Space를 누른다. 그럼 가장 최신버전을 표시해준다.

상단에 보면 Version이 있는데 이 버전은 개발할 프로젝트의 빌드 버전이다. 사용자가 버전업 할 사용자 버전을 등록하면 된다. 뭐 귀찮다면 변경하지 않아도 좋은데 가능하면 기능 업데이트때 마다 의미있는 버전을 적어주는게 좋다.

다시 frontend 폴더를 확인해보자

dist 폴더와 wailsjs 가 보일것이다.

이 폴더는 root 폴더에서 wails build 명령으로 새롭게 생성되므로 삭제 해도 무방하다.

최종적으로 설정이 마무리 될 시점이나 중간중간 wails build를 실행할 것이므로 일단 삭제하도록 하자.

index.html 파일과 src 폴더의 파일은 VanillaJS 기준 Source 파일들인데 typescript 용 Source는 어떻게 구성되는지 정확히 모르겠다. 일단 구동에 필요한 Source이므로 놔두도록 하자.

Rust - Tauri를 잠시 보류하고 Golang 기반의 Wails를 선택하고나니 좀 길이 보이기 시작했다.

Tauri가 막 엄청나게 어렵고 복잡하기보다는 시간적인 압박감때문에 계속 진도가 안나갔던것 같은데 심리적인 안정감 떄문인지 훨씬 진행속도가 빠르다는걸 느끼고 있다.

일단 거두절미하고...

Wails와 어떤기술을 사용 해야할지 검색을 좀 해보니 다음 기술들이 조합이 되어야 할 것 같았다.

Wails + Vite + Sveltekit + Typescript + Tailwind 조합이 딱 적당할 것 같았다.

각 기술들의 장단점들인 인터넷에 널려있으니 검색해도록 하자. 혹시 댓글로 요청이 많이 오면 별도로 정리하는 글을 적어보도록 하겠다.

Wails 개발홈페이지에서 제공하는 템플릿 기반으로 프로젝트를 생성하려다 보니 문제가 좀 있었다.

https://wails.io/docs/community/templates

원하는 기술에 딱 부합되는 템플릿이 없었다. 

wails-vite-svelte-tailwind-template 가 제일 적합한것 같았는데 typescript 가 빠져있었고 sveltekit이 적용이 안되었다. 게다가 관리를 안해서 그런지 프로젝트를 생성해서 구동을 해보면 정상적으로 실행이 안되고 각 config 들을 손을 좀 봐야 정상 작동을 하는 수준이있다.

그래서 해당 template를 fork 받아서 수정해서 쓰려고 했는데 svelte와 sveltekit 설정이 조금 상이해서 약간의 수정으로 처리하기가 좀 어려운감이 들었다. 물론 웹쪽에 아주 전문가 분들이라면 뚝딱뚝딱 수정해서 사용하기는 하겠지만....

그래서 진행하는 프로젝트는 wails-vite-svelte-tailwind-template를 수정해서 진행하기로 하고 template를 새롭게 구성해보겠다고 마음먹었다. template 만드는건 처음 해보는 시도이기도 하고 웹쪽의 각 기술들이 어떤식으로 조합해서 구성해야 하는지 기본부터 한번 해봐야 겠다는 생각도 들어서였다.

그래서 만드는 과정을 블로그에 기록하기로 하고 추후 다른 템플릿 만들때 참고 자료로 사용하면 좋을것 같아서 짬짬이 시간내서 진행하기로 한다. 

일단 https://github.com/dofstar/wails-vite-sveltekit-ts-tailwind-template 에 등록해서 작업해보도록 하겠다.

(지금 당장 생성된건 아니니 조금만 기다려달라..)

기술 조합은 다음과 같다.

Wails : 2.1.0
Vite : 3.18
SvelteKit : 1.0.0 (RC)
Typescript : 4.8.4
Tailwind : 3.1.8

https://levelup.gitconnected.com/lets-write-a-simple-event-bus-in-go-79b9480d8997

이 글을 요약해서 작성해보자

https://www.codingworldnews.com/news/articleView.html?idxno=12914 

Rust를 학습하면서 자연스레 WASM 쪽으로 관심이 가게되었다. 

아직 초창기여서 이런저런 문제점들이 있기는한데 계속 성장하는 모습들이 앞으로의 세대교체를 짐작하게끔 한다. 하지만 꽤 많은 시간이 걸릴것이다.이미 주류가 되어버린 Javascript가 너무 탄탄한데 언젠간 Javascript가 가지고 있는 구조적인 문제나 성능문제가 대두되면서 웹브라우저가 WASM에 더 비중을 실어줄것이고 기능 확대를 점진적으로 진행할 것이다. 하지만 진입점이나 학습곡선이 Javascript보다는 높은편이라 단기간에 기대할 수 있지는 않을꺼라 생각한다.

mod_wasm은 두 개의 라이브러리로 구성이 되어 있다

1. mod_wasm.so로 아파치 C API 와 러스트 라이브러리 사이에 인터페이스를 제공하여 웹어셈블리 런타임을 관리할 수 있다. 즉 아파치 구성 옵션 및 러스트 라이브러리와의 연결을 담당한다.

2. libwasm_runtime.so 라이브러리는 아파치의 HTTP 요청을 받아 웹어셈블리 모듈을 구성하고 실행한다. 응답을 파싱한 이후 mod_wasm.so에 다시 관리 권한을 넘겨준다.

웹어셈블리는 바이너리로 컴파일되어서 스택 기반 가상 머신으로 웹 애플리케이션이 높은 성능을 발휘할 수 있도록 도와준다. 한번 적용해보고 싶긴하다. 조만간 성능테스트 결과 같은게 나오면 소개해보겠다.

보통 Rust 패키지 관리자인 Cargo 를 사용할때 다음과 같은 문법으로 패키지를 추가한다.

cargo install create-tauri-app

관련 패키지들을 다운받아서 로컬에서 빌드를 하게 되는데 최초 관련 패키지들의 소스를 다운받아서 컴파일 한 후 빌드하면 사용할 패키지가 완성된다. 그런데 다운받아서 빌드하는데 5분넘게 시간이 걸린다. 아무래도 너무 오랜 시간이 걸리는 문제점을 개선하기위해 이미 빌드된 패키지를 다운 받는 기능을 만들어서 배포하는것 같다.

그럼 binstall 을 설치해보자.

cargo install cargo-binstall

이것도 꽤 많은 패키지들의 소스를 다운받아서 컴파일한 다음 cargo-binstall 패키지를 완성한다. 

설치가 완료되면 다음 두가지 방법으로 호출해서 사용할 수 있다.

cargo binstall <다운받을 패키지명>

or

cargo-binstall <다운받을 패키지명>

패키지명을 빼고 실행하면 다음과 같은 help 도움말이 표시된다.

cargo binstall create-tauri-app

다음을 실행해 보면 5분넘게 걸리던 패키지 설치과정이 40초로 줄어든걸 볼 수 있다.

세부적인 명령어는 필요할때 써보고 정리해보도록 하겠다.