Giter VIP home page Giter VIP logo

charisworks-backend's Introduction

CharisWorks-BackEnd

これは golang ベースで作られた開発中のバックエンドサーバです。

今まで商品管理・アカウント・取引を別々に開発していましたが、今回はそれをすべて統合した形となります。

構成

graph LR
client --- Nginx
subgraph  [Server]
Nginx --- FrontEndServer
FrontEndServer --- BackEndServer
FireBaseAuth --- BackEndServer
BackEndServer --- DB
BackEndServer --- Stripe
FrontEndServer --- FireBaseAuth
Stripe --> FrontEndServer
end

フロー

セッション

sequenceDiagram

participant Client
participant Server
participant DB

Client ->> Server:Session_Key
Note right of DB: loginlog
Server ->> DB:Session_Key
DB ->> Server:UID
Note over Server: newSession_Key
Note right of DB: loginlog,Customer
Server ->> DB:NewSession_Key UID
Server ->> Client:NewSession_Key


ログイン

sequenceDiagram
participant Client
participant firebase
participant Server
participant DB

Client ->> firebase:email password
firebase ->> Client: userCredential
Client ->> firebase:userCredential.user
firebase ->> Client:IdToken(JWT)
Client ->> Server: IdToken(JWT)
Server ->> firebase:IdToken(JWT)
firebase ->>Server:Token
Note over Server:issue Session_Key
Server ->> Client:Sesison_Key
Note right of DB: loginlog,Customer
Server ->> DB: Token.UID,Session_Key

取引フロー

sequenceDiagram
participant Client
participant Server
participant Stripe
participant DB


Client ->> Server:request with cart
Note over Server:check Item,Stock,Price
Server ->> DB:Register Transaction
Server ->> Stripe:Create PayentIntent
Stripe ->> Server:PaymentIntent Info
Server ->> Client:URL
Client ->> Stripe:Stripe Checkout
Stripe ->> Server:Status of Charge
Server ->> DB:Update Transaction
Server ->> DB:Update Item

データ構造

カート・取引 データベース

erDiagram
Customer }|--|{Transactions:""
Transactions}|--|{TransactionDetails:""
TransactionDetails}|--|{Item:""
Item}|--|{ItemDetailsImage:"商品の画像"
Item}|--|{Customer:"出品者が商品を出品"
Customer}|--|{LogInLog:"ログインとセッションの管理"
Maker}|--|{Item:"出品者が商品を出品"
Maker}|--|{Customer:"出品者が商品を出品"
Customer{
    UserID string PK "FirebaseTokenから取得"
    Email string "FirebaseTokenから取得"
    IsEmailVerified bool "FirebaseTokenから取得"
    CreatedDate timestamp "作成日時"
    Name string "名前"
    ZipCode string "郵便番号"
    Address string "郵便番号以降の住所"
    IsRegistered bool "本登録"

}
ItemDetailsImage{
    ItemID string PK
    Image string "画像へのpath"
    Order int
}
Item{
    ItemOrder int PK "商品の順番"
    ItemID string
    Status string "商品の状態(買えるかどうかなど)"
    Price int "価格"
    Stock int "在庫"
    ItemName string "商品の名前"
    Description string "商品説明"
    Color stirng "色"
    Series string "シリーズ"
    ItemSize string "商品のサイズなど"
    StripeAccountID string FK
    Top int "Topに表示するかどうか"
}
TransactionDetails{
    ItemOrder int PK "取引商品の順番"
    TransactionID string UK
    Quantity int "数量"
    ItemID string FK
}
Transactions{
    UserID string UK
    TransactionID string PK
    Name string "顧客の名前"
    TotalAmount int "購入金額"
    ZipCode string "顧客の郵便番号"
    Address string "郵便番号の先の住所"
    TransactionTime timestamp "取引された時間"
    StripeID string "Stripeから振られたID"
    Status string "取引の状態"
    ShipID string "郵便局の追跡番号"
}
LogInLog{
    UserID string PK
    SessionKey string
}
Maker{
    UserID string PK
    StripeAccountID string UK
    MakerName string
    Description string
}

charisworks-backend's People

Contributors

whatacotton avatar

Stargazers

Arata avatar

Watchers

 avatar

charisworks-backend's Issues

検索機能の実装

現在のルーティングはクエリを一つまで対応しているが、複数のクエリに対応できるようにしていく必要がある。
SQLのステートメントを組み上げるような機構が必要となる。

商品の画像の保存

商品の画像をリクエストに飛ばして、それをサーバの特定の場所に保存させるような処理をする。
拡張子でバリデーションをするような実装も必要。

カートのデータの保管場所をサーバ側ではなく、ローカルストレージ側にする(バックエンド処理)

今までの実装では、すべてのデータをサーバ側に保存していたため、そのデータが誰のものなのかを確実に判定し、それを更新させる必要があった。しかし、それではデータを更新するたびにサーバにリクエストを投げる必要があり、サーバの負荷がユーザの増加に応じて増えていくため、スケーリングにかなり難がある。
そこで今回ローカルストレージにデータを保存することにした。ローカルストレージに保存することによって、今まで無理やりセッションなどでユーザを判別してきたデータ構造も不要になるし、今まで必要だったリクエストも格段に減る。
フロント側でデータを持つので、カート情報の変更も用意になるし、ログインしていてもしていなくてもカート機能を使用できる。

セッションに基づくカートを対応するべきか

現在実装されているログイン無しでのカート機能は本当に必要かどうか
セッションに基づくカートの実装には別のkeyのcookieが使用されており、今までとても実装が大変だった。可用性を重視するためにこの機能を消しても良いが、どうするか決めたい

カートの詳細情報の取得

カートのデータの構造体を小さくしたため、そのデータ自体に名前や価格が乗らなくなってしまった。なので小さいデータを投げると、必要なデータを補完して出してくれる仕組みが必要

cookieをアクセスごとに変えるべきか

cookieをアクセスごとに変えるべきか問題が存在する。
メリットとしては、cookieのデータが漏れたとしても、次のアクセス時にはそのcookieが無効化されているので、セキュアである。
デメリットとしては、実装が大変で、更にcookieをincludeしたアクセスを同時に2つ以上叩くことができないということ。

getCustomer時にカートの情報も取ってくるようにする

現在はgetCustomerを実行すると、顧客の個人情報のみを取ってくるようにしている。なので、ログインするタイミングでカートの個数を表示させるためには2つリクエストを飛ばす必要がある。そこで、getCustomer時にもカートの情報を取ってこれるようにしなければいけない。

データベースの環境について

前環境ではdbeaverを使っていたが、今回の環境では使えないみたい。それでどのデータベースビューワーを使うかという問題。

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.