はじめに
弊社の看板サイトである「生活110番」のリニューアルが終わり、本年9月上旬に無事にオープンしました。今回のWebサイト・リニューアルで何を考え、何を行ったのかをフロントエンド・エンジニアの視点でブログに綴ります。
このブログに書かれた内容はすべて弊社内のラボで実証実験を経て、自分たちですべて組み上げたDIYフロントエンド構成についてです。読んでみて興味のあるフロントエンドさんはぜひ弊社に一度遊びに来てください!
ハーフスタック・エンジニア
世の中には、フルスタック・エンジニアなど存在しない!という意見もあります。フルスタックは存在しないが、ハーフスタックは目指すに値すると考えました。わたしなりの定義が以下です。
- HTML/CSS/JavaScriptが書ける
- PHP/Java/Python/Rubyのどれかが得意で書ける
- フロントとバックエンドAPIの両方書ける
かなり狭義の定義になりますが、こんなスキルセットとします。
WordPressからの変更
今までの「生活110番」はWordPressで構築、運用されていました。サイトをリニューアルするにあたり、WordPressのまま行くのか、全く違うCMSやその他フレームワークで行くのかを検討しました。
また社内のSEO部隊やインフラ部隊から以下のようなリクエストもあがりました。
- AWSでコストを意識した運用ができること
- CI/CDをしっかり行うこと
- SEO対策がしっかり行えること
- 更新が素早く行えること
以上を踏まえて、候補に上がったフレームワークは、
- WordPress(現状維持)
- Vue.js/Nuxt.js
- React/Next.js
以上の3つが最終選考に残りました。
東京都の新型コロナ対策サイトやデジタル庁の公式サイトが、Vue.js/Nuxt.jsで構築されているようですね。React/Next.jsは、海外で人気が高く、国内ではYahooさんが積極的に導入しています。どちらもメリット、デメリットがあるため、決めかねていました。しかし決めなければならず、社内で多くの議論や実証実験を行いました。
Nuxt.jsに決定
Nuxt.jsもNext.jsもSEOとの相性が良いSSRで駆動しますし、困ったときの情報も豊富にあります(日本語ではVue.jsの方が多いかもしれません)。あとは好みの問題というところまで進みました。が、実際には社内の他サイトでVue.jsの構築経験のあるスタッフが若干名いました。最後は、Reactを新しく学ぶより、Vue.jsの方が若干早く開発が行えるのではではないかと工期優先を切り札にして決定した次第です。
開発をスタートしてみて苦労したお話
はじめが肝心ということは重々承知していましたが、やはり今回もそうでした。特に大規模サイトのリニューアルでしたので、大きくぶれましたね。Nuxt.jsはVue.js単体で書くよりは規則や規約が厳格なのですが、色々とトラブルが発生しました。その事例の1つをご紹介します。
困ったことの具体的な例
以前までは通信のたび、axios通信のもっともシンプルで標準的な次のようなコード(page/index.vue)を書いていました。HEADERにAPIキーを埋め込むコードや、404エラー時の処理を毎回記述していたため、非常に保守性が悪かったと思います。とりあえずベタ書きでもAPIサーバーからデータが取れるし、Nuxt.jsも動くしで、ある時期はあちこちに書かれてしまっていました。
page/index.vue
async created(){
try {
this.data = await this.$axios.get('https://example.jp/fetchHuga/?param1=a',{headers:'XXXXX'})
}catch(e){
if (error.response.status === 401) {
alert('エラー')
}
return error;
}
この問題を解決するため、次のようにAPI通信部分をクラス化(api.js)し、Pageと分離を行いました。
page/index.vue
async created(){
this.data = await this.$api.fetchHuga('aaaa')
}
plugins/api.js
export default function ({ $axios, env }, inject) {
const axios = $axios.create({
baseURL: 'https://example.jp/',
headers: { 'X-API-KEY': 'XXXXX' },
})
//エラー発生時の共通処理
axios.onError((error) => {
if (error.response.status === 404) {
alert('エラー')
}
})
const api = new Api(axios)
inject('api', api)
}
class API = {
constructor(axios) {
this.axios = axios
}
async fetchHuga(param1) {
const paramList = ['service_id']
return await this.axios.$get('fetchHuga', { params: payload })
}
}
こんなことは初めに用意しておけばよかったことですよね・・・・通信部分をクラス化することで、 単体テストが行いやすいですし、エンドポイントや通信設計の変更に対しても柔軟に対応できるしで、 保守性が格段に向上できたと思います(^_^;)
他にも同様に多くの共通処理をクラス化してコードのルール化ができました。
以上が、フロントエンド・エンジニア達が実際に職場で行っているお仕事の一例になります。最後まで読んでいただきましてありがとうございました。
シャアリングテクノロジーでは一緒に働くメンバーを募集しています。気軽に遊びに来てくださいね!!
本稿、「ハーフスタックエンジニアへの道(2回目)」で続きがあります。よければどうぞ。