新卒で入った会社で、物理サーバーに Node と Express を入れる作業をしました。
自分でサーバーを立てて、そこに処理を置いて、React の画面から呼びます。 呼ぶ側と呼ばれる側を、両方とも自分で用意した状態です。 このとき、paiza のときとはまた別の感じがありました。
同じ内容を、スクールでは説明として聞いています。 クライアントがあって、サーバーがあって、API で繋がっている。 その場では何も残りませんでした。
説明が入らなかった理由#
聞いていた頃の私には、確かめる手段がありませんでした。
目の前に画面があっても、どこがクライアントでどこがサーバーなのかを見分けられません。 図で線が引かれていても、その線が自分の手元で何に対応するのかが分かりません。 分からないことを確かめようがない状態で、分類の名前だけを聞いていました。
自分で両方を用意すると、境目が物理的に見えます。 片方を止めれば、もう片方から呼べなくなります。 自分のパソコンからは動くのに、別の場所からは動かない状況にも当たります。
その困りごとが来てから聞くと、クライアントとサーバーの話は答えになります。
画面より先に置く#
そこで、この段では画面をまだ作りません。
前の段で書いたロジックを、外から呼べる形にするところまでをやります。 処理を返すだけの小さなサーバーを立てて、ターミナルから呼んでみます。 自分のパソコンの中では動くのに、外からは届かない、という状態にここで一度当たっておきます。
通信の仕組みや、ポートや、リクエストとレスポンスの話は、この位置で拾います。 先に説明として渡すと、私がスクールで受け取り損ねたのと同じことになります。
GETとPOSTより先にあるもの#
学び始めの順番でよく前に来るものに、GET と POST があります。
私はこれを後ろに置きました。 理由は、これが決まりごとだからです。 どちらを使うかには慣習があり、覚えれば済みます。 選択肢を比べて決める種類のものではありません。
一方で、値をどう持つかは設計の判断です。 選び方が何通りかあって、間違えるとあとで困ります。 困る可能性があるところにしか、問いは生まれません。
決まりごとより、選ぶところを先に置きます。
画面を戻す#
次の段で、ようやく画面を作ります。
ここでも見た目には手を入れません。 素の HTML に入力欄とボタンを置いて、さっき立てたサーバーを呼ぶだけです。 CSS は書きません。
私が新卒のときに手応えを感じたのは、React から呼んだ瞬間でした。 自分が書いた処理が、別の場所から呼ばれて、結果が画面に出ます。 呼ぶ側と呼ばれる側が繋がって、初めて一周します。
この一周を体験するために画面が要るのであって、見た目を整えるためではありません。 学び始めに HTML と CSS で長く止まってしまうのは、この役割が入れ替わっているからだと考えています。