TECH LEAD Blog

TECH LEAD Resume

TECH LEAD Agent

2019-04-05

【サーバーサイド（アプリケーション層）編】TECH LEADの技術を惜しげも無く公開します！React × PHP Laravel × BEAR.Sunday × SSR

テクノロジーエンジニア

こんにちは、@TECH LEADです。

第3回となる今回は、TECH LEADのサーバーサイド（アプリケーション層）の技術をご紹介します。

アーキテクチャー編
フロントエンド編
サーバーサイド（アプリケーション層）編　←いまここ
サーバーサイド（内部API層）編
インフラ編

はじめに

アーキテクチャー編でも少し説明させて頂きましたが、 TECH LEADサービスのサーバーサイドプログラム(PHP)は、大きく内部API層とアプリケーション層の2つに分かれています。

アプリケーション層は、フロントからのリクエストされたデータや処理を内部API層へリクエストし、結果をフロントへ返却する役割をしています。

今回は、前回の続きでSSR(サーバーサイドレンダリング)の実装部分と内部API層との連携部分に関して説明していきたいと思います。

主な技術

PHP 7.2

フレームワーク

Laravel 5.6

ディレクトリ構成

.
|                   # 内部API層
├── api/            # [BEAR.Sunday]ミドルウェアの操作・メール送信
├── db/             # [Laravel] データベースのマイグレーション・シードを管理
└── web/                  # アプリケーション層
    ├── site-common/      # 共通で利用できるものを配置
    |                     # シンボリックリンクで各アプリケーションで使用
    ├── site-mypage/      # [Laravel] TECH LEAD共通部分
    |                     # アカウント設定・パスワード変更など
    ├── site-agent/       # [Laravel]TECH LEAD Agent
    ├── site-job/         # [Laravel]TECH LEAD Job
    └── site-resume/      # [Laravel]TECH LEAD Resume

サーバーサイドレンダリングに関して

TECH LEADでは、PHPのエクステンションのV8jsを使用してSSRを行なっています。

TECH LEAD Jobのトップページを例に説明していきたいと思います。

※フロントエンドの実装は、前回の記事をご確認ください。

<?php

namespace App\Http\Controllers\Site;

use App\Models\Job\Posting;
use App\Models\UserAccount;
use GlobalShift\TechLead\Models\Api\Searcher\JobPosting as JobPostingSearcher;

class IndexController extends Controller
{
    public function index()
    {
        /* @var UserAccount $userAccount */
        $userAccount = $this->loginUserAccount();

        if ($userAccount) {
            return redirect()->route('site/postings/index');
        }

        // 内部API層へリクエスト
        $result = (new JobPostingSearcher())->cachedSearch(
            ['public_status' => Posting::PUBLIC_STATUS_OPEN],
            1,
            Posting::NEWER_SORT
        );

        if ($result->code !== 200) {
            abort(404);
        }

        $searchResult = collect($result->body);

         // SSR用のHTML作成
        $html = $this->getSsrHtml('index', [
            'postings' => $searchResult->get('sources', []),
        ]);

        return view('site.ssr', [
            'html' => $html,
        ]);
    }
}

<?php

namespace App\Http\Controllers\Site;

use App\Http\Controllers\Controller as BaseController;
use App\Models\UserJob\Information;
use GlobalShift\TechLead\Models\Api\UserJob\Information as ApiInformation;

class Controller extends BaseController
{

   // 省略

    protected function getSsrHtml(string $page, array $payload = [])
    {
        $v8js = new \V8Js();

        // 共通して必要な環境変数・パスなど
        $variables = [
            'env' => config('app.env'),
            'flash_message' => htmlspecialchars(json_encode($this->flashMessage())),
            'path' => [
                'index_js_path' => route('/js/site_csr.js'),
                'index_css_path' => route('/css/site.css'),
            ],
        ];


        // V8jsで実行させるJavascript(文字列)
        $code = <<<EOT
%s
VARIABLES=%s
global.render(%s, %s);
EOT;

        $code = sprintf(
            $code,
            file_get_contents(__DIR__.'/../../../../public/js/site_ssr.js'),
            json_encode($variables),
            '"'.$page.'"',
            json_encode($payload)
        );

        return $v8js->executeString($code);
    }

    private function flashMessage()
    {
        return [
            'success' => implode(',', session()->pull('success', [])),
            'error' => implode(',', session()->pull('error', [])),
        ];
    }
}

<!-- web/site-job/resources/views/site/ssr.twig -->
{{ html|raw }}

まず、必要なデータを内部API層へリクエストし、収集します。次にgetSsrHtmlメソッドにレンダリングしたいページ名とページの生成に必要なデータを渡し、HTMLを生成します。

getSsrHtmlメソッドでは、フロントエンドでSSR用に作成したエントリポイント(site_ssr.js)を読み込み、global.renderを実行するJavascriptのコードを文字列で作成します。

V8jsのexecuteStringを使用して、上記のJavascriptコードを実行し、結果(HTML)を返します。

ssr.twigは、PHPのviewテンプレートでSSRするページ共通で使用していて、コントローラから渡されたHTMLをそのまま表示しています。

※SSRには、まだ課題があり対応を検討中です。(参照：フロントエンド編)

内部APIとの連携に関して

アーキテクチャー編で少し説明させて頂きましたが、現状、同一サーバ上で全てのサービスが動いてHTTPでリスエスト処理をするには、まだサービスの規模が小さく、HTTP通信にすることによるオーバーヘッドが大きくなってしまうので、現在は内部API層(BEAR.Sunday)をインスタンス化したものをアプリケーション層で読み込み、内部API層の機能を利用してデータの取得などを行なっています。

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     */
    public function boot()
    {
        // 内部API層のインスタンスを注入
        $this->app['api'] = require dirname(__DIR__, 4).'/api/api.php';
    }

    /**
     * Register any application services.
     */
    public function register()
    {
        require dirname(__DIR__).'/helpers.php';
    }
}

<?php

namespace App\Traits;

trait DBApiTrait
{
    /**
     * @return \BEAR\Sunday\Extension\Application\AbstractApp
     */
    protected function dbApi()
    {
        // 内部API層のインスタンスを呼び出す
        return app()['api'];
    }
}

アプリケーション層の実際にデータを取得するための部分は、./web/site-common/app/Models/Api/以下に定義し、composerのautoload機能を利用してアプリケーション層(各サービス)で利用できるようにしています。

    "autoload": {
        "psr-4": {
            "App\\": "app/",
            "GlobalShift\\TechLead\\": "../site-common/app"
        }
    },

実際に都道府県データを取得するためのコードを紹介します。

<?php

use GlobalShift\TechLead\Models\Api\Prefecture;

$result = (new Prefecture())->all();

// body内に内部API層で取得したデータ入っている
$result->body;

// ./web/site-common/app/Models/Api/Prefecture.php
<?php

namespace GlobalShift\TechLead\Models\Api;

class Prefecture extends Base
{
    public function all()
    {
        // 内部API層の都道府県取得部分にリクエスト
        $result = $this->get('app://self/common/prefecture/index');

        return $result;
    }

    public function findByCode(string $code)
    {
        $result = $this->get('app://self/common/prefecture/detail', ['code' => $code]);

        return $result;
    }

    public function findByUrlWord(string $urlWord)
    {
        $result = $this->get('app://self/common/prefecture/detail', ['url_word' => $urlWord]);

        return $result;
    }
}

// ./web/site-common/app/Models/Api/Base.php
<?php

namespace GlobalShift\TechLead\Models\Api;

use App\Traits\DBApiTrait;

abstract class Base
{
    use DBApiTrait;

    /**
     * @return \BEAR\Resource\ResourceObject | \BEAR\Resource\Request
     */
    protected function cloneGet($uri, $queries = [], $crawls = [])
    {
        // `$this->dbApi()`は内部API層のインスタンス
        $resource = $this->dbApi()->resource;
        $request = $resource->get->uri($uri)->withQuery($queries);

        foreach ($crawls as $crawl) {
            $request->linkCrawl($crawl);
        }

        return $request->request();
    }

    /**
     * @return \BEAR\Resource\ResourceObject | \BEAR\Resource\Request
     */
    protected function get($uri, $queries = [], $crawls = [])
    {
        $request = $this->dbApi()->resource->get->uri($uri)->withQuery($queries);

        foreach ($crawls as $crawl) {
            $request->linkCrawl($crawl);
        }

        return $request->request();
    }

    /**
     * @return \BEAR\Resource\ResourceObject | \BEAR\Resource\Request
     */
    protected function post($uri, $data)
    {
        return $this->dbApi()->resource->post->uri($uri)->withQuery($data)->request();
    }

    /**
     * @return \BEAR\Resource\ResourceObject | \BEAR\Resource\Request
     */
    protected function put($uri, $data)
    {
        return $this->dbApi()->resource->put->uri($uri)->withQuery($data)->request();
    }

    /**
     * @return \BEAR\Resource\ResourceObject | \BEAR\Resource\Request
     */
    protected function delete($uri, $data)
    {
        return $this->dbApi()->resource->delete->uri($uri)->withQuery($data)->request();
    }
}

※内部API層(BEAR.Sunday)の詳細は次回のブログで紹介します。

まとめ

ここまで、サーバーサイドのアプリケーション層に関して、一部になりますが説明させて頂きました。

弊社のエンジニアチームでは、このような複数サービスを横断的に利用できるWEBサービスの開発をした経験がなかったため、どのように実装するかとても悩みました。いざ実装していくと想定外の問題にぶつかったり、改善すべき点が見つかったりまだまだ試行錯誤しながら開発しています。

是非、同じようなサービスを開発している方や同じような課題を持っている方とお話ししてみたいです。興味がある方は是非お声がけください！

エンジニアの皆さんへお願い

よろしくお願いします！

次回予告

次回は【サーバーサイド(内部API層)編】で、BEAR.Sundayの紹介と内部API層の実装ついて話したいと思います。

最後まで読んでいただきありがとうございました！

PR

「今は具体的な転職を考えていないよ」と言う方も、是非一度TECH LEADの各サービスを触ってみていただけると嬉しいです。

TECH LEAD Job

TECH LEAD Resume

TECH LEAD Agent

2019-03-29

【フロントエンド編】TECH LEADの技術を惜しげも無く公開します！React × PHP Laravel × BEAR.Sunday × SSR

エンジニアテクノロジー

こんにちは、@TECH LEADです。

前回の「【アーキテクチャー編】TECH LEADの技術を惜しげも無く公開します！」は、たくさんの方に読んでいただきありがとうございました。

第二回となる今回は、TECH LEADサービスでのフロントエンドの実装をご紹介します。

アーキテクチャー編
フロントエンド編　←いまここ
サーバーサイド（アプリケーション層）編
サーバーサイド（内部API層）編
インフラ編

はじめに

最近、ReactやVueなどのJavaScript フレームワークを使い、フロントエンドの開発を進める企業やサービスが増えてきていると思います。どんどん進化して行くフロントエンドの技術をどのように実装して行くか悩む方がたくさんいると思います。TECH LEADサービスでもフロントエンドの開発でとても悩みました。

弊社では約1年半くらい前からReactを使用したアプリケーションを開発してきました。

最初に使用したサービスではReact × React Router × ReduxでSPA(シングルページアプリケーション)を作成し、次のサービスではReact × React Router × Typescript × ReduxでSPAを作成しました。

TECH LEADサービスではReact × TypescriptでSSR(サーバーサイドレンダリング)+CSR(クライアントサイドレンダリング)で作成しています。

「なんでTECH LEADはSPAじゃないのか？」と疑問に思った方もいると思いますので、その理由を説明したいと思います。

SPAを辞めたわけ

2つのサービスをSPAで作成しましたが、開発中にSPAである必要があったのかと考えさせられることがあったので他の手段や方法を検討するためにもTECH LEADでは、一旦SPAをやめて開発をすることにしました。

SPAを開発する上で大きく3つの課題がありました。

セッション管理が大変
Reduxの処理を書くのが大変
SEOやOGPなどの対応が難しい

SPAを使った場合、ルーティングの設定、ログイン認証処理などフロントエンドでやることが増えます。 SSR/CSRの場合、ルーティングの設定もセッション管理も完全にサーバーサイドに任せてしまえばいいので、ページを描画することだけに専念させることができ、SPAをやめたことでReduxを使う必要もなくシンプルにコードを書くことができました。

※Reduxはとても便利ですが、コードを書く量が多く、保存されたデータの初期化のタイミングなど考えることが多く大変でした。。。

また、パブリックなページに関しては、SEOやOGPなどの設定や処理を入れるのが大変そうだったり、きちんと評価されるか不安だったため、確実に対応できそうなSSRで対応することにしました。

※以前の2つのサービスは、プライベートなページのみだったのでSEOを気にする必要はなかった

Reactを勉強している方や使用を検討している方に少しでも参考になるよう、一部にはなりますが詳しく公開したいと思いますので、よろしくお願いします。

TECH LEADのフロントエンド

主な技術

React 16.4

Typescript 2.6

Sass

webpack 4

ディレクトリ構成

.
├── common/             # `web/site-common/js`へのシンボリックリンク
|                       # 各サービス共通で使用する関数やコンポーネントを配置
├── components/         # ステートレスコンポーネントを配置
├── containers/         # renderされるメインのステートフルコンポーネントを配置
├── modules/            # api通信用の関数を配置
├── pages/              # SSR時に使用するコンポーネントを配置
├── const.d.ts          # Typescriptの型定義ファイル
├── index.tsx           # CSR用のエントリーポイント
├── index_csr.tsx       # SSR後にCSRする用のエントリーポイント
└── index_ssr.tsx       # SSR用のエントリーポイント

サーバーサイドレンダリングに関して

今回はTECH LEAD JobがどのようにSSRされ、ページを作っているか実際のコードを元に説明します。

※参考：TECH LEAD Jobトップページ

※サーバーサイドの実装の詳細は、次回「サーバーサイド（アプリケーション層）編」で公開します。

実際に使用するファイル(一部抜粋)

.
├── pages/ 
│  ├── Index.tsx        # トップページのコンポーネント
│  ├── layout.tsx       # レイアウトファイル
│  └── variables.tsx    # コンポーネントをまとめたもの
├── index_csr.tsx       # SSR後にCSRする用のエントリーポイント
└── index_ssr.tsx       # SSR用のエントリーポイント

# index_ssr.tsx
import * as React from 'react';
import {renderToString} from 'react-dom/server';
import Helmet from 'react-helmet';
import {layout} from './pages/layout';
import {pages} from './pages/variables';

const render = (page: string, payload: object) => {
  const element = pages[page];

  const component = renderToString(
    <React.Fragment>
      <Helmet>
        <title>IT/WEBエンジニア専門の求人サービス|TECH LEAD Job</title>
        <meta name="description" content="TECH LEAD Job（テックリードジョブ）は、IT・WEBエンジニア専門の求人サービスです。"/>
        <meta property="og:title" content="IT/WEBエンジニア専門の求人サービス|TECH LEAD Job"/>
        <meta property="og:type" content="website"/>
        <meta property="og:url" content="https://job.techlead.jp/"/>
        <meta property="og:image" content="https://job.techlead.jp/img/sns-ogp.png"/>
        <meta property="og:site_name" content="TECH LEAD Job"/>
        <meta property="og:description" content="TECH LEAD Job（テックリードジョブ）は、IT・WEBエンジニア専門の求人サービスです。"/>
        <meta name="twitter:card" content="summary_large_image"/>
        <meta property="fb:app_id" content="762141787490152"/>
      </Helmet>
      {React.cloneElement(element, {...payload})}
    </React.Fragment>
  );

  return layout(component);
};

declare const global: {render: any};

global.render = render;

index_ssr.tsxはSSR用のエントリーポイントになります。

サーバーサイドではV8jsを利用して、「SSR用のエントリーポイント」を読み込み、グローバルに用意したrender関数を実行・HTMLを生成・HTMLを返します。

render関数には、呼び出すコンポーネント(ページ)のキーとPropsの値を渡します。

React.cloneElement(element, {...payload})の部分で対象のコンポーネントを渡されたPropsで生成し、renderToString関数でコンテンツ部分のHTMLを取得します。

コンテンツ部分のHTMLができたらlayout関数で、ページに必要なheadの情報や共通部分を追加したHTMLを生成し、HTMLを返します。

サーバーサイドは、この生成されたHTMLをレンダーしてページを表示します。

# variables.tsx
import * as React from 'react';
import {defaultValues as indexValues, Index} from './Index';

export const pages: {
  [key: string]: JSX.Element;
} = {
  index: <Index {...indexValues}/>,
};

※呼び出すコンポーネント(ページ)とキーの組み合わせをまとめている

# layout.tsx
import Helmet from 'react-helmet';

export const layout = (body: string) => {
  const helmet = Helmet.renderStatic();

  return (
    `
<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0,maximum-scale=1.0,user-scalable=no">
  <meta name="format-detection" content="telephone=no">
  <link rel="shortcut icon" href="/img/favicon/favicon.ico">
  <link rel="apple-touch-icon" sizes="180x180" href="/img/favicon/apple-touch-icon.png">
  <link rel="icon" type="image/png" sizes="32x32" href="/img/favicon/favicon-32x32.png">
  <link rel="icon" type="image/png" sizes="16x16" href="/img/favicon/favicon-16x16.png">
  <meta name="msapplication-TileColor" content="#da532c">
  <meta name="theme-color" content="#ffffff">

  ${helmet.title.toString()}
  ${helmet.meta.toString()}
  ${helmet.link.toString()}
  ${helmet.script.toString()}

  <link href="https://use.fontawesome.com/releases/v5.1.0/css/all.css" rel="stylesheet">
  <link href="${VARIABLES.path.index_css_path}" rel="stylesheet" type="text/css">
</head>
<body>
  <div id="flashMessage" data-payload="${VARIABLES.flash_message}">
  </div>
  ${body}
  <script src="${VARIABLES.path.index_js_path}"></script>
</body>
</html>
    `
  );
};

※ページheadの情報は、React Helmetを使用してページごとに設定

※VARIABLESはサーバーサイドで設定した定数

# Index.tsx
import * as React from 'react';
import Helmet from 'react-helmet';
import SimpleSearchForm from '../containers/SimpleSearchForm';
import {LpJobCard} from '../components/LpJobCard';
import {agentUrl, jobUrl, resumeUrl, mypageUrl} from '../../common/util';
import {PostingModel} from '../../common/lib/models/JobInterface';

export const defaultValues = {
  postings: [],
};

interface Props {
  postings: PostingModel[];
}

export const Index: React.SFC<Props> = ({postings}) => {
  return (
    <React.Fragment>
      <Helmet>
        <script type="text/javascript" src="delighters.js"/>
      </Helmet>
      <header className="head head--lp">
        <div className="head__inner">
          <a href={jobUrl()} className="head__logo">
            <img alt="" className="card-lp__service--logo" src="/common/logo/TLJ.svg" height="25"/>
          </a>
          <div id={'headerSignArea'}/>
        </div>
      </header>
      <div className="lp-top">
        <div className="lp-top__content">
          <h1 className="lp-top__title">
            IT/WEBエンジニアに<br/>
            理想的な求人情報と
            <br/>スカウトを
          </h1>
          <p className="lp-top__txt">テックリードジョブは、エンジニアの得意な技術や仕事への志向性でマッチングする、IT/WEB業界に特化した新しい求人・転職サービスです。</p>
          <div className={'signupButton'} data-payload={JSON.stringify({label: '会員登録 (完全無料)'})}/>
        </div>
        <img className="lp-top__visual--job--main" alt="" src="/common/lp/job__keyvisual.png"/>
        <img className="lp-top__visual--job--bg1" alt="" src="/common/lp/lp-top__bg1--job.svg"/>
        <img className="lp-top__visual--job--bg2" alt="" src="/common/lp/lp-top__bg2--job.svg"/>
      </div>
      <div id={'simpleSearchForm'}>
        <SimpleSearchForm/>
      </div>
      <section className="lpj_sec" data-delighter="">
        <div className="container is-small">
          <div className="lpj_sec-title">
            <h2>
              フィット感の高さが伝わる、厳選された求人情報
            </h2>
          </div>
        </div>
        <ul className="lpj_job-list">
          {postings.map((posting, i) => (
            <LpJobCard
              key={i}
              posting={posting}
              jobPostingContent={posting.job_posting_content || {}}
              jobClient={posting.job_client || {}}
            />
          ))}
        </ul>
        <div className="has-text-center">
          <div className={'signupButton'} data-payload={JSON.stringify({label: '会員登録 (完全無料)'})}/>
        </div>
        <div className="container is-small mt-6">
          <div id={'campaignBanner'}/>
        </div>
      </section>

      <!-- 省略 -->

注意点

静的なHTMLが生成される

V8jsからは、静的なHTMLが生成されるのでコンポーネント内でonChangeイベントなどの処理があっても実行することができません。動的なコンポーネントはレンダーされた後に実行する必要があるので、「SSR後にCSRする用のエントリーポイント」を使い、マウントします。

例として、Index.tsxの下記の部分について説明します。

# Index.tsx
<!-- 省略 -->
  <div id={'simpleSearchForm'}>
    <SimpleSearchForm/>
  </div>
<!-- 省略 -->

# index_csr.tsx
import '@babel/polyfill';
import * as React from 'react';
import {render as reactRender} from 'react-dom';
import ErrorBoundary from '../common/components/common/ErrorBoundary';
import SimpleSearchForm from './containers/SimpleSearchForm';
import SignupButton from '../common/containers/common/SignupButton';

const renders: {
  [key: string]: JSX.Element;
} = {
  simpleSearchForm: <SimpleSearchForm/>,
  signupButton: <SignupButton/>,
};

const getElementData = (element: HTMLElement): object => {
  const data = element.dataset.payload;

  if (!data) {
    return {};
  }

  element.dataset.payload = '';

  return JSON.parse(data);
};

Object.keys(renders).forEach((name) => {
  const element = document.getElementById(name);

  if (element) {
    const data = getElementData(element);
    const component = React.cloneElement(renders[name], {...data});

    reactRender(
      <ErrorBoundary>
        {component}
      </ErrorBoundary>
      , element
    );
  }

  const elements = document.getElementsByClassName(name) as HTMLCollectionOf<HTMLElement>;

  for (const ele of Array.from(elements)) {
    const data = getElementData(ele);
    const component = React.cloneElement(renders[name], {...data});

    reactRender(
      <ErrorBoundary>
        {component}
      </ErrorBoundary>
      , ele
    );
  }
});

index_csr.tsxは、SSR後にCSRする用のエントリーポイントです。

index_csr.tsxでは、rendersに定義されたキーから対応する要素を探し、対応する要素があればコンポーネントをレンダーしています。また、対応する要素のdata属性を使用し、data-payloadがあれば格納されたJSONを初期描画に必要なPropsとして注入しています。

※最初は、HTMLのid属性でコンポーネントを指定いましたが、1ページに複数回出てくるようなコンポーネント(signupButtonコンポーネントなど)があったためclass属性でもレンダーさせています。

※マウントさせる要素の命名規則をきちんと作らないと意図せぬ場所へマウントされてしまうので気をつけてください。

※data属性を使う理由は、何度もサーバーサイドにリクエストされるのを防ぎ、高速化させるため

<SimpleSearchForm/>を<div id="simpleSearchForm"/>でラップしている理由は、<div id="simpleSearchForm"/>だけでレンダーしてしまうとindex_csr.tsxが実行されるまでは要素が空になってしまうからです。

ラップすることによって、初期描画時に<SimpleSearchForm/>で仮の要素を作り(動かない)、マウント時に動く要素と入れ替えることができます。これを行うことによって、初期描画からマウントされるまでの間に、要素が空になってしまうことやDOMが書き換わることによる画面のブレを防いでいます。

V8jsの罠

V8jsはPHPのエクステンションで、インストールするとV8 Javascript EngineがPHPに組み込まれJavascriptが実行できるようになります。

ただV8jsでは、setTimeoutなど使えない関数があるのでSSR時に使用するコンポーネントでは使わないように気をつけてください。

また、layout.tsxのhead部分にGoogle タグマネージャを埋め込み、アナリティクスなどの計測をさせていたのですが、V8jsのChromium上でも読み込まれ、実行されてしまっていたようで、計測の数値が倍くらいになってしまう問題が発生しました。

暫定的に、V8jsのChromium上にはwindowがないようだったので、windowの存在判定をして、実行されないように回避しました。

V8js上で、何が起こっているか確認する方法やデバッグがわからなかったため、暫定的な対応になってしまいたした。。。

詳しい方がいたらご教授いただきたいです。よろしくお願いします。

クライアントサイドレンダリングに関して

「SSR後にCSRする用のエントリーポイント」の動きとほぼ同じになります。

違いは、初期描画をPHPのビューテンプレートで行なっているのでメタ情報などはサーバーサイドで設定しているということと、使用するコンポーネントが異なることくらいです。

TECH LEADを作ってみて

「もう一度SPAを作ってみたい！」と思っています。

やはりSSRやCSRだとサーバーサイドとフロントエンドの両方でviewの管理をしなければならなくなり役割が分散してしまうので、SPAにしてviewは全てReactで行うようにし、サーバーサイドは完全にAPIサーバのような形をとったほうがいいのではないかなと思ってきています。

また、今まで経験を生かしReduxの使いどころに注意しながらSPAを作っていきたいと思っています。

以前SPAを作った時は、Reduxに全てのデータを入れ、Stateの管理をまとめたり、コンポーネントにPropsを注入するのに使っていたため、ちょっと使いたいデータなどがあった時でも大量のコードを書かなければならなくて大変でした。

しかし、最近ReactにContext APIやHooksといった機能が追加されたため、簡単なことや限定的はことだけどStateを使いたい・Propsを注入したいという時は、Reduxではなく簡単に使えるContextやHooksで実装したら楽にSPAがつくれそうだなと思っています。

まとめ

サーバーサイドレンダリング

メリット
- 初期描画が早い
- SEO対策・メタ情報の設定が楽
- セッション管理が簡単
デメリット
- 実装が難しい
- サーバーサイドが大変

クライアントサイドレンダリング

メリット
- 実装が簡単
- セッション管理が簡単
デメリット
- SEO対策・メタ情報の設定が大変・不安
- DOMが空の状態でレンダーされる
- 初期描画が遅い

シングルページアプリケーション

メリット
- 実装が簡単
- サーバーサイドが簡単
- 一度読み込むと早い
デメリット
- SEO対策・メタ情報の設定が大変・不安
- 初期描画が遅い
- セッション管理が難しい

SSR・CSR・SPA、どれにもメリット・デメリットがあると思いますが、フロントエンドの技術は、すごいスピードで進化していて「これがスタンダード」というような形は、まだまだ決まっていないと思います。なので開発する際は、アプリケーションやページに対して最適な方法を見極める必要があります。（それが難しいと思いますが。。。）

また、進化が早い分、常に新しい情報をチェックし、どんどん取り入れていく必要があると思います。

弊社では以前作ったSPAが大変だったことからSSR・CSRでTECH LEADサービスを作りましたが、Reactへの理解も深まり、新たな機能が増えたことからSPAに変更することを検討しています。

おそらく、ログイン後のプライベートなページなどからの変えていくことになると思いますが、SPAを実装した際は、また皆さんに共有します！

エンジニアの皆さんへお願い

今回はTECH LEADのフロントエンドの実装方法を公開しましたが、いかがでしたでしょうか。すこしでも開発の参考になればと思います。

よろしくお願いします！

次回予告

次回は【サーバーサイド（アプリケーション層）】の実装について話したいと思います。

最後まで読んでいただきありがとうございました！

PR

「今は具体的な転職を考えていないよ」と言う方も、是非一度TECH LEADの各サービスを触ってみていただけると嬉しいです。

TECH LEAD Job

TECH LEAD Resume

TECH LEAD Agent

2019-03-20

【アーキテクチャー編】TECH LEADの技術を惜しげも無く公開します！React × PHP Laravel × BEAR.Sunday × SSR

エンジニアテクノロジー

こんにちは、@TECH LEADです。

現在TECH LEADでは、IT/WEBエンジニアのキャリアアップに関する3つのサービスを開発・運営しています。

現在はキャリア・転職関連のサービスを中心に展開していますが、今後は全てのIT/WEBエンジニアの皆さんに利用されるようなエンジニアリングのスキル・キャリアプラットフォームへと成長させていく事を目指しています。

2018年3月から本格的に自社サービスであるTECH LEADの開発がスタートしたのですが、スタート時にはサービスをどのように設計し、開発していくかについてとても悩みました。（今も悩んでます）

そんな時に他のサービスを参考にしたいと思い、いろいろなサービスを調べていく中で下記のようなことを強く感じました。

どのように設計されているのだろうか？
どのように実装されているのだろうか？
中身を見てみたい

色々な会社のテックブログなどで使われている技術などの紹介をしていることは多いものの、詳細なアーキテクチャーや実装が書いてあるサービスはとても少ない印象でした。もちろん、セキュリティー上見せられないということもあるかと思いますが、もう少し詳細なところを知りたいな・参考にしたいなと思いました。

そこで「人がどうやっているのか教えて欲しい！」と言う前に、まず自社のサービスがどのように実装されているのか公開したいと思います。なるべく全体像や詳細な実装がわかるように詳しく書いていきたいと思いますので、よろしくお願いします。

今回を第一回として、今後以下の順番でブログを連載していきます。

アーキテクチャー編　←いまここ
フロントエンド編
サーバーサイド（アプリケーション層）編
サーバーサイド（内部API層）編
インフラ編

新規でサービスを作ろうとしている方も既存サイトがある方も、少しでもこの記事が参考になればと思っています。

第1回となる今回は、TECH LEADサービス全体のアーキテクチャについて説明したいと思います。

開発の基本コンセプト

プラットフォームサービスを作っていくにあたって以下のようなことを基本コンセプトとして設定し、設計・開発を行っています。

１つのアカウントですべてのサービスを利用できる
登録されたリソースを無駄なく全サービスで活用できる
スケールしやすく作る
メンテナビリティが高い

主な技術

インフラ・ミドルウェア

Amazon EC2

Amazon Aurora

Amazon S3

Elasticsearch 6.4

nginx

PHP-FPM

デプロイ

Deployer

インフラツール

Terraform

Ansible

サーバーサイド

PHP 7.2

フレームワーク

Laravel 5.6

BEAR.Sunday

フロントエンド

React 16.4

Typescript 2.6

Sass

webpack 4

インフラに関して

EC2：アプリケーション用とElasticsearch用の2つ
データベース：Amazon Aurora
ストレージ：Amazon S3

※Amazon Elasticsearch Serviceを使うこと検討しましたが、Kuromojiのユーザー定義辞書を使うことができないため見送りました。

オーケストレーションツールとしてTerraformを用い、サーバ・DNSなどの設定を全て行なっています。

Ansibleでミドルウェアのインストール・nginxの設定などのサーバ構成管理を全て行なっています。

現状は、全サービス同一サーバに乗っているので、1台のNGINXで全てのアプリケーションを動かしています。

サーバーサイドに関して

ディレクトリ構成

.
|                   # 内部API層
├── api/            # [BEAR.Sunday]ミドルウェアの操作・メール送信
├── db/             # [Laravel] データベースのマイグレーション・シードを管理
└── web/                  # アプリケーション層
    ├── site-common/      # 共通で利用できるものを配置
    |                     # シンボリックリンクで各アプリケーションで使用
    ├── site-mypage/      # [Laravel] TECH LEAD共通部分
    |                     # アカウント設定・パスワード変更など
    ├── site-agent/       # [Laravel]TECH LEAD Agent
    ├── site-job/         # [Laravel]TECH LEAD Job
    └── site-resume/      # [Laravel]TECH LEAD Resume

TECH LEADサービスのサーバーサイドプログラム(PHP)は、大きく内部API層とアプリケーション層の２つに分かれています。

内部API層では、データベース・Elasticsearchの操作、メール送信処理などに直接アクセスし、それらの処理をラップ(抽象化)しています。

各アプリケーションは、直接データベースなどを操作することはなく、内部API層へリクエストすることでデータを作成・取得・更新をしています。データベースなどを考える必要がなく、基本的にはフロントからのリクエストを内部API層にリクエストし、結果を受け取り、フロントに返すことに専念できます。

また、アプリケーション層と内部API層を分けることで、サービスが追加された時や変更があった時でも、ほかのサービスへの影響を最小限に抑え、対応ができるようこのような構成になっています。

データベースのマイグレーションとシードに関しては、dbディレクトリ配下に配置しているLaravelのマイグレーション機能を利用しています。ここでは、マイグレーションとシード以外のことは行なっていません。

※現状、同一サーバ上で全てのサービスが動いていますが、今後サービスが成長していくにつれて各サービスを分離していこうと考えています。

フロントエンドに関して

ディレクトリ構成

.
├── common/             # `web/site-common/js`へのシンボリックリンク
|                       # 各サービス共通で使用する関数やコンポーネントを配置
├── components/         # ステートレスコンポーネントを配置
├── containers/         # renderされるメインのステートフルコンポーネントを配置
├── modules/            # api通信用の関数を配置
├── pages/              # SSR時に使用するコンポーネントを配置
├── const.d.ts          # Typescriptの型定義ファイル
├── index.tsx           # CSR用のエントリーポイント
├── index_csr.tsx       # SSR後にCSRする用のエントリーポイント
└── index_ssr.tsx       # SSR用のエントリーポイント

PHPのviewテンプレートはTwig、フロントエンドはReact × Typescriptを使っています。

TECH LEADサービスでは、ほとんどのページがCSR(クライアントサイドレンダリング)でコンテンツを描画しています。

PHPからはheadやjs・cssエントリポイント、利用するコンポーネントの指定をしたHTMLだけを返し、CSRでページを描画しています。

しかし、SEO的にページへアクセスした時点でDOMが作られていないのはよくないので、ログイン前に見れるページはSSR(サーバーサイドレンダリング)で作っています。

※SSRはPHPのエクステンションのV8jsを使用して行なっています。

弊社では以前、別プロジェクトでSPA(シングルページアプリケーション)を作成した経験があります。「ReactでSPAを作ろう！（作ってみたい！）」と意気込んだものの、開発中に下記のようなこと思いました。

本当にSPAである必要があったのか？
Reduxを使う必要があったのか？
もっと簡単に書けるのでは？

そんなことを思った経験からTECH LEADサービスでは、まずは最小限で実装し、フロントエンドをどう実装するのがいいのかを考えながら開発をしていこうと思っています。

※最近、「モダンなフロントエンドはSPAがベストプラクティス」というような記事をみかけ、やはりSPAにしようかなと検討中です。

まとめ

ここまでインフラからフロントエンドまで、非常にざっくりとではありますが全体の構成を説明させていただきました。

TECH LEADサービスのアーキテクチャーで一番特徴的なところをあげると、フロントエンド、アプリケーション層(プログラム)・内部API層(プログラム)でやることを切り分け・限定しているところになると思います。各層をAPIでやり取りすることによって、共通のリソースを使うことができ、それぞれの依存関係を低くすることでメンテナビリティを高められていると思います。

今後の課題として、アプリケーション側で共通部分をシンボリックリンク使って各サービスで使用しているコードを、サーバを分ける際にどのようにまとめるかなどの検討していかなければならないですが、基本的には上記のような形を維持しつつうまくパッケージ化して各サービスで使用することができたらなと思っています。（結構大変だと思いますが。。。）

エンジニアの皆さんへお願い

今回は、TECH LEADサービスのアーキテクチャや全体像の説明をさせて頂きました。次回以降のブログでは、フロントエンドからサーバーサイド、インフラまでもう少し具体的な実装や、開発時の課題などを公開していこうと考えていますが、もし、「ここをもっと聞きたい」「うちではこうやっている」と言ったご意見・アドバイスなどありましたら、@TECH LEADまでリプライやDMにてお気軽にお知らせください！

よろしくお願いします！

次回予告

次回は【フロントエンド編】で、フロントエンドの実装ついてもう少し深く話したいと思います。

最後まで読んでいただきありがとうございました！

PR

「今は具体的な転職を考えていないよ」と言う方も、是非一度TECH LEADの各サービスを触ってみていただけると嬉しいです。

TECH LEAD Job

TECH LEAD Resume

TECH LEAD Agent