布団の中にいたい

Elasticsearchいじったり、Androidアプリ書いたり。最近は数学の勉強が楽しくなってきました。

nuxtでRESTっぽい感じに重複したルーティングをする

特に難しいことを考えなくても色々できるので、最近はよくnuxtを触っているのですが、RESTっぽい感じに階層的なURLで動的なルーティングはどうするんだろうって思ったので、試してみた。

公式のリンクは以下。

ja.nuxtjs.org

上のリンクをたどればわかりますが、単純にidなどでルーティングしたいのであれば、pagesで以下のような形にします。ここの_id.vueでは、params.idという形でidを受けることができます。

pages
  - users
    - _id.vue

次に、階層的なルーティングは以下のような形でできました。下の例はユーザの趣味の一つを表示する的な意味合いでやっています。特徴的なのは上の例では、vueファイルに対して、_idという名前をつけましたが、階層的にルーティングをする場合は、ディレクトリに対して名前をつけています。

pages
  - users
    - _user_id
        - hobby
            - _hobby_id

werckerでs3にdeployしてみた

個人プロダクトをnuxt.jsを使ってSPAを書いているのですが、楽にデプロイしたいと思って、werckerを使ってみました。

werckerはTravis CIなどと同様のCIのサービスで、フリープランでもprivateリポジトリに対して導入できるという特徴があります。

Wercker Home

wercker自体の導入は簡単で、wercker側でリポジトリの登録をして、登録したリポジトリに対して、wercker.ymlを入れるだけです。wercker.ymlはシンプルなものであれば、導入時にテンプレートが用意されているので、それを軽く修正する形で問題ないと思います。私の場合は、nuxt.jsで書いたアプリをbuildしたかったので、node環境のテンプレートを修正する形にしました。

以下が私が書いたものの一部です。本来はbuild stepを分けるべきなんですが、werckerのworkflowがうまく組めなかったので、諦めてdeploy stepに全部書いてます。

deploy:
    steps:
        - npm-install
        - script:
            name: build nuxt
            code: |
                npm run build
        - s3sync:
            key_id: $AWS_ACCESS_KEY
            key_secret: $AWS_SECRET_KEY
            bucket_url: $AWS_BUCKET_URL
            source_dir: dist/

s3にデプロイしている部分はs3syncです。s3syncには、deploy用に作成したIAMユーザーのaccess keyとaccess secret keyを設定します。bucket_urlは配置するバケットのurlを乗っければいいです。例えば、hogehogeというバケット名であれば、s3://hogehogeでいけます。source_dirはs3に送るディレクトリになります。

ここで変数で指定している部分については、wercker側で設定する値になります。あとは、wercker側でpush時にpipelineが走るようにすれば概ね完了です。

あとは、pushしてしまえば、wercker側でpipelineが走って、上記だとs3にdistが配布されることになります。

「Amazon Web Services 基礎からのネットワーク&サーバー構築」を読んで、似たような構成をterraformで作ってみた

つい昨日、「Amazon Web Services 基礎からネットワーク&サーバー構築」を読んで感想を書いたのだけれど、実際に使う上では自動化必須だと思われたので、terraformでやってみました。

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

リポジトリは以下。

github.com

似たようなものと書いているのは理由があって、mysqlのインストールは行っていません。理由は単純で、ローカルからremote-execで接続してもよかったんですが、そうすると構成上、mysql-server用のインスタンスを公開するか、ルートテーブルに自分の環境のipを載せないといけなかったので、面倒くさくてやめました。実際に使う場合はterraform applyを実行するCIサーバから接続できるようにする形になるんですかね。

上でちらっと書きましたが、httpdなどのインストールにはprovisionerのremote-execを使っています。本当はansibleを使いたかったんですが、provisionerに無かったことと、やることがシンプルなものだけだったので、そのままremote-execでやっちゃってます。provisionerにchefなどがあったので、そっちでやっちゃってもいいかもです。

まとめ

terraformについては名前だけしか知らず、実際に使ったことは無かったのですが、いざ使ってみると思いの外簡単でした。他環境用のものもterraformでやってみようと思います。

「Amazon Web Services 基礎からのネットワーク&サーバー構築」を読んだ

AWSを仕事で使ってはいるものの、実際の構築は他の部署の方にお願いしているので、私自身はシステムのアーキテクチャを設計して、それをAWSで構築してもらっているだけでした。

さすがにそれではいけないという気持ちと、一通り全部出来たほうがいいかという気持ちがあったので、入門書として「Amazon Web Service 基礎からのネットワーク&サーバー構築」を読んでみました。

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

内容としては、AWSを使って、セキュリティを意識しつつ、wordpressを構築してみましょうというお話です。改訂版になって、UIが現在のものにかなり近くなっているので読みながら実際に構築していくことができます。加えて、基本的なhttpの説明から、TCP/IPの説明なんかもあるので、インフラ自体よくわからないという人におすすめかもしれません。

この本自体は実際に手を動かしながら進めていく形ですが、AWSのcloudformationを使って構築してみたみたいな記事がいくつかあるので、そちらを参考に同じことをしてもいいかもしれません。私自身はプライベートでGCPを使っていることもあるので、AWS以外の環境でも使えるterraformでお試しに構築してみています。またはそれについては別の記事で書くかもしれません。

blog.a-know.me

「初めてのシングルアプリケーション Vue.js と Firebase で作るミニ Web サービス」を読んだ

ここ最近、個人プロダクトはReact使ってたんですが、仕事でVueを触らないといけない状況が増えてきたので、Vueの勉強を再開しています。そんな中で、技術書典4の本がBOOTHで売られていたのでPDFを買って読んでみたので、さっくりと感想でも。

booth.pm

本の内容は表題にもあるとおり、全編通してVueとFirebaseを使って、小さめのWebサービスを作ってみて公開してみようというお話です。個人的に一番助かった点ですが、firebaseを使っているので裏側をだいぶお手軽にできることが実感出来たことと、それをVueで利用する上でどうしたらいいかを理解できたことです。Vue自体はとりあえず触ったことはあるものの、フロント周りの技術自体あまり知らないので、「Vueの基本的な部分だけを使って、簡単なWebサービスを作る」ということを実感できたのは非常にありがたかったです。加えて、初学者・中級者向けに次の課題も提示されているので、さらに勉強するのであればそれらをやってみてもいい、という形で次の指針が示されているので、勉強もしやすいのではないかと思います。

まとめ

同人誌自体読んでみるのが初めてなんですが、普通に本を読むよりためになったなと個人的には感じています。「Vue使ってみたいけど、何やっていいかわからん」みたいな場合に読んでみるとかなり助けになるのではないかと思いました。

BOOTHで買うときにお布施しとけばよかったと後悔。購入後にお布施する仕組みとかないかな。

echoでCORS対応する場合にpreflightリクエストの処理をどこでしているか調べてみた

昨日「Web API: The Good Parts」を読んで、APIを実装する場合の基本的な部分をおさえてみようということでCORS対応について色々確認してみてます。

net/httpで実装するのであれば、該当するhandler内部でMethodのチェックをして、OPTIONSならそのまま返す、みたいなことをしてやれば良い訳ですが(もしくは、リクエスト受けるときにそのままチェックしてやるとか)、echoでやる場合にはどうしたらいいのかと思って確認してみました。

echoでCORS対応する場合は、middlewareにCORSがあるのでそれを使ってしまえばいいと思います。サンプルコードも公式にあります。

echo.labstack.com

ただ、どこでOPTIONSのチェックをしているのかと思ったのでソースコードを漁っていたら、middleware/cors.goのCORSWithConfig内部でやってました。

echo/cors.go at master · labstack/echo · GitHub

OPTIONSについても、Access-Control-Allow-Methodsに付加すると思ってたんですが、普通にチェックするだけでいいんですね。

「Web API: The Good Parts」を読んだ

新しいことばかりに目を向けすぎていて、今現在活用されている技術についての理解が不足しているなーと思ったので、最近は既存技術の根っこみたいな所を集中して勉強するようにしています。

そんな中でWeb APIは大抵のサービスで活用されているものであり、この所のモノリシックなアプリケーションからマイクロサービスへの移行が各所で進み始める中で、APIについて理解することはより大切であろうと思ったので「Web API: The Good Parts」を読んでみました。

Web API: The Good Parts

Web API: The Good Parts

細かい内容について言及するのは引用の域を超えそうなので、大まかな部分と感想だけ。

本の流れとしては、Web APIとは、といった所から設計・運用であったり、HTTPの仕様についての解説からどういった使い方をすべきか、またはWeb API自体のセキュリティについて言及されています。

私自身は、今まで働いてきた中で何度かAPIの実装や改修などは行ってきましたが、エンドポイントを追加する時などは特に何も考えず、「これの方がAPIっぽい」みたいな形でやってました。実際、これ自体は既存のAPIに似せた形で作ろうという考えだったので、考え方自体は間違っていなかったかも知れないですが、結局の所、曖昧な考えを元にしていたのでもやもやしていました。

「Web API: The Good Parts」では、毎回の項目でAPIの細かい部分について説明しながら、既存の有名なプロダクトのAPIと比較などを行いつつ、選択するのに無難な方を理由を踏まえて説明してくださっていて、自身の曖昧な考えについて、「なぜそうするべきなのか」について明確な回答が得られたような気がします。

公開するようなWeb APIだけではなく、例えば普通のアプリケーションのAjaxで呼ばれる内部APIみたいなものを実装する場合にも参考になる部分は多いと思うので、何かしらWebサービスに関わる方は一読の価値があると思いました。