オークションナイトサービス


競売夜サービス開発記録



🏨競売とは何ですか。


 競売夜プラットフォームとは、公認の仲介会社、一般ユーザーまたは会社が不動産商品を登録し、競売または売買方式で仲介を提供するBtoCサービスを指す.オークション方式はオークション物と署名の入札内容ブロックチェーンに登録し,開札後に落札結果を算出し,ユーザに信頼できるオークションサービスを提供する.
オンラインオークションの紹介

🔥開発リソース


このプロジェクトはFEシステムの設計、開発とリーダーシップを担当している.
開発期間は約2ヶ月半(2021年01月1日から2021.03.15年まで).
2021.03.15から現在まで、運営とメンテナンスを行っています.
会社の安全のために、簡単に説明します.

人員を投入する.

  • FE開発6ヶ月目1名(me)
  • 1年以下1名万能BE開発者😎
  • 個人携帯開発者(?…!)1名🤣
  • の間に補充人員としての新しいFE開発者😣
  • テクノロジーアーキテクチャ

  • TypeScript
  • Next.js
  • Express(custiom server)
    next.jsサーバ側でよく知られているエコシステムの広いexpressは、custom server
  • を使用しています.
  • React.js
  • accesstokenまたはサーバによって管理する必要があるデータを格納するために使用される
  • Redis (session storage)
  • scss
  • Matarial-UI
  • Atomic Design Pattern
    構成部品管理をより効率的に行うために、以前のプロジェクトとは異なる構成部品を導入しました.
  • 🍥サービス設計


    需要機能リスト


    売り手

  • 条幅
  • 貨物伝票
  • カスタマーサポート
  • オークション

  • 貨物伝票
  • 貨物詳細
  • オークション

  • 入札
  • 入札活動
  • 落札及び抽選参加履歴
  • 入札活動に参加した歴史記録
  • 検証入札履歴
  • お客様のサポート

  • 公告事項
  • FAQ
  • 報道資料
  • 勘定科目の関連付け

  • 登録
  • 会員入
  • ID、パスワード
  • を検索
    脱退
  • 会員
  • パスワード変更
  • マイページ

  • 入札目録及び詳細
  • 入札及び落札放棄
  • 登録と削除
  • 返金口座
  • 定価照合表
  • 積分使用と蓄積履歴
  • おすすめ友達
  • 登録
  • 仲介会社
  • システム構成


    BEサーバとの通信


    BEServerは、REST API、GraphQLとしてデータを提供する.主なread機能はGraphQL、create、update、deleteなどの機能をAPI形式で提供しています.
    Authenticationdは、ログイン時に提供されるJWTトークンをRedisセッションリポジトリに格納し、認証が必要な通信に追加します.これにより、FEクライアントに必要な通信は、FEサーバを介して設計される.

    FEサーバの構造


    FEサーバのデフォルトはSSRのNextです.jsを使用しました.Next.jsは、ExpressやNestなどのBEプログラムを使用してクライアントサーバ機能をサポートします.おなじみでコミュニティが活発なExpressを選びました.FEサーバは、Customサーバを使用する必要はありませんが、さらなる構造化には使用されません.
    注意:https://nextjs.org/docs/advanced-features/custom-server
    サーバのフォルダ構造には、主にミドルウェア、plugin、routerがあります.api, router.ページングで使用します.(BEとは異なり、FEの変更が多くend-pointが多くルーター設計が困難であるが、以下のように変化性が強い.)
    server
    ├─ middleware
    │  └─ example
    ├─ plugin
    │  └─ example
    │    └─ index.ts
    ├─ routers
    │  ├─ api
    │  │  ├─ api.router.ts
    │  │  └─ user
    │  │     ├─ account
    │  │     │  ├─ account.router.ts
    │  │     │  └─ controller
    │  │     │     ├─ getLogout.ts
    │        │     ├─ index.ts
    │  │     │     └─ postSignin.ts
    │  │     └─ user.router.ts
    │  ├─ index.ts
    │  └─ pages
    │     └─ user
    │        ├─ account
    │        │  ├─ account.router.ts
    │        │  └─ controller
    │        │     ├─ index.ts
    │        │     └─ signin.ts
    │        └─ user.router.ts
    └─ server.ts

    げんしせっけい


    以前のプロジェクト「競売ナイト事前登録サービス」では、コンポーネント管理がコンポーネントに埋め込まれたフォルダを管理していました.幸いなことに、事前登録サービスは小規模なプロジェクトなので負担できますが、このプロジェクトでは大規模なサービスであり、代替案が必要です.複数のアーキテクチャを検索する際に,素子の再利用性を強調するアーキテクチャ設計を採用した.以下の構造からなる.(pages, templetes, organisms, molecules, atoms)
    src
      ├─ pages
      │  ├─ 404.tsx
      │  ├─ user
      │  │  └─ account
      │  │     └─ signup.tsx
      │  ├─ _app.tsx
      │  ├─ _document.tsx
      │  └─ _error.tsx
      ├─ styles
      │  ├─ globals.scss
      │  ├─ index.scss
      │  ├─ SpoqaHanSans-kr.scss
      │  └─ _variables.scss
      ├─ templates
      │  ├─ styles
      │  │  └─ user
      │  │     └─ account
      │  │        └─ signup.scss
      │  ├─ user
      │  │  ├─ account
      │  │     └─ signup.tsx
      │  └─ _error.tsx
      ├─ ui
      │  ├─ atoms
      │  │  └─ input
      │  │     ├─ InputCheckbox.tsx
      │  │     └─ styles
      │  │        └─ InputCheckbox.scss
      │  ├─ molecules
      │  │  └─ card
      │  │     ├─ AuctionMiscarriageCard.tsx
      │  │     └─ styles
      │  │        └─ AuctionMiscarriageCard.scss
      │  └─ organisms
      │     ├─ carousel
      │        ├─ AuctionItemsCarousel.tsx
      │        └─ styles
      │           └─ AuctionItemsCarousel.scss
      └─ utils
         ├─ lib
         └─ redux
            ├─ actions
            ├─ reducers
            └─ store.ts

    イメージとファイル管理


    オークションには、静的ではなく動的にファイルを管理する必要があるというポイントがあります.例えば、ストライプ画像、物品に関連する画像またはファイル.開発初期の設計段階では、「ファイル管理サーバが必要です.」このような意見が出されたが,限られた開発時間と人力のため,あきらめてファイルシステム構造に開発された.(構成は以下の通り)
    この構造は開発と上場後に致命的な話題を残した...😥 ファイルはプロジェクトで管理され、ハブに配置されます.これは、バナーを交換するためにサーバを再配置する必要があることを意味します.これらの問題を解決するために、AWS 3を使用し、関連する内容はここです。で見つけることができる.
    file
      ├─ auction
         ├─ thumbnail
         │  └─ image.jpg
         └─ images
            └─ image1.jpg
            └─ image2.jpg

    🧬問題と解決


    FEサーバ構築エラー


    1週間前にサービスを開始したときに発生したエラーです.明らかに以前は良かったのですが、ローカルビルドは正常でしたが、AWS EC 2では未知の理由でビルドされていませんでした.最終的には発売日に解決されず、開発モデルでしか実行できません.事件は上場1週間後の不動産取引会で起きた.開発者モードで稼働しているサーバは、1日平均200~300人程度の接触速度に耐えられない.このようなことが発生した後、パフォーマンスの高いEC 2に変換し、バージョンの導入を行うと、すべてが嘘のようにスムーズになります.今までその理由を知らなかった.😂

    変更が多すぎる企画


    サービス開発とパブリケーションの後、変更リクエストが最も多いページはホームページである可能性があります.初期開発段階では、計画段階の設計に応じた最適化開発が行われ、設計変更要求を受けた後、かえって足手まといになった.その後、ホームページの設計はいくつかの小さな変化が発生し、これらの変更要求は開発サイクルを延長する要因の一つである.もちろん、開発者は管理職やユーザーと友好的に開発すべきだと考えているので、理解できます.これらの根強い問題を解決するためには,開発初期に最適化せずにコードを記述すべきであると考えられる.未来を考えても、あまり考えないで!!😮)

    🌹結果画面


    サイトリンク


    オークション:https://www.auctionok.co.kr

    オークションホームページ



    オークション、イベント、取引品目カタログおよび詳細