Architect (arc.code) が使いやすい

読了まで:約3分


私は​時々、

を​使って​何かしらの​スクリプトを​個人開発する​事が​あり、​その際、​毎回の​事ながら、

さて​ AWS Lambda に​ deployment を​する​ための​ツールは​何を​使おう?

と、​困る​事が​よく​有りました。

それで、

何か​良い​ツールチェインは​無い​ものか……

と、​毎回探していたんですが​最近に​なって、

と​言う​良さげな​ツールを​ awesome-serverless 経由で​見つけたので、​ 今日は​その​辺りを​紹介したいと​思います。

Architect とは?

これは​一言で​言えば、

AWS の​エコシステムに​特化した、​JAMStack 用の​ Toolchain

で、​もう​少し​詳細に​言うと、

AWS Lambda の​ Node.js Runtime を​ベースに、​AWS の​ Middleware に​特化した​開発補助ツール

と​言えます。

そして、​この​ Architect を​使うと、

  • AWS Lambda + AWS S3 + Amazon DynamoDB + Amazon API Gateway + ...etc

と​言ったような​構成で​開発する​時に​ 面倒な​ AWS 固有の​アレコレを​一挙に​引き受けて​もらえる​ ので、​ 本来の​開発すべき事柄に​集中する​事が​出来る​様に​なり、​それ故に​私は​今コレを​気に入って​使っています。

な​ぜ​私は​ Architect を​使うのか

基本的には、

AWS の​ Serverless 開発で​ AWS 周りの​面倒な​ことを​全部​押し付けたい

と​言う、​ワリと​都合の​良い​理由が​メインです。​また、​その​他にも、

  • 個人用 Slack の​ちょっとした​スクリプトを​ AWS Lamda で……とか
  • ちょっとだけサーバ処理が​必要な​スクリプトを​作る……とか
  • あるいは、​本格的な​開発でも​ガッツリと​コストを​下げる​ために​……とか

そういった​理由でも、​ Architect を​使っていたりします。

また、​上記の​理由の​他にも、

  • コードの​配置位置に、​程良い​制約が​有る
  • Architect 固有で​覚えなければならない​事が​少ない
  • JAMStack を​ deploy する​ための​便利な​コマンド類も​キチンと​揃っている

と​言った​様な​特長も、​私が​ Architect を​気に入っている​理由の​中に​入っています。

Architect が​向く​事・向かない​事

先にも​書いた​通り、​ Architect は​ AWS の​ JAMStack へ​特化した​構成に​なっていて、​ それ故に​下記の​様な​制約も​当然発生して​来ます:

  • AWS Lambda の​ Node.js 以外の​ Runtime に​対応していない
  • Architect が​すべての​ AWS Middleware の​面倒を​見てくれる​訳ではない
  • AWS Lambda の​ Node.js Runtime しばりなので、​それ故の​制約も​当然ある

とは​言え AWS Lambda が​関わらない​部分では​他の​ JavaScript ライブラリと​当然の​様に​組み合わせられるので、​ React や​ Vue と​言った​様な​ライブラリを​組み合わせる​事も​可能です。

また​ Architect が​管理する​部​分以外では​既存の​ AWS 用ライブラリが​使えるので、​ そう​言った​意味でも​あんまり​不自由さは​無いんじゃないかな、と​個人的には​思っています。

Architect の​始め方

Architect の​ Getting Started に​ついては、

を​閲覧した方が​圧倒的に​理解が​早いのですが、​一応​ここでも​紹介しておくと、​ Architect では​:

$ cd $WORKDIR
$ npm install @architect/architect
$ cat <<EOF >.arc
> @app
> testapp
>
> @http
> get /
> EOF
$ ARC_LOCAL=1 npx create

と​いう​様な​手順で​ボイラープレートが​生成し、​その後は​生成された​ボイラープレートに​従って、​ 色々と​実装して​行くと​いう​形に​なると​思います。

ただ​注意点と​して​ Architect では​ npx を​利用して​各種スクリプトを​実行するので、​ @architect/architect を​ グローバルインストールする​必要は​有りません

と​言うか、​グローバルに​インストールすると​他の​ toolchain と​実行ファイル名が​被ると​思うので、​ 基本的には​その​辺り​行わない​様に​しておいた​方が​良いです。

以上

と​言う事で、​今回の​話は​以上です。

今回書いた​様に​ Architect は​ AWS Lambda の​ Node.js Runtime に​特化しているで、​ 他の​ Runtime 等を​扱いたいと​いう​場合に​おいては、

と​言った​辺りを​使うと​良いかもしれません。

とは​言え JAMStack で​ AWS Lamda を​用いるのであれば、​ Architect は​複雑な​事を​簡単に​してくれる​良い​ツールだと​個人的には​思っているので、

一度、​Architect を​試してみるのも​良いんじゃない?

と​個人的には​思っています。​はい。

にゃるら(カラクリスタ)

『輝かしい青春』なんて失かった人。
次に備えて待機中。

今は趣味でプログラミングをして
生活しています。