聊天專案


#1

目前整理一些資料 專門來做聊天的專案 但不知道方向對不對

第一次這樣玩 主要還是用於可以實際功能串起來

至於變化的功能 等到功能出來 可以理解再來進一步功能

Rails api server 首先使用 Devise 來實作 Android 接口在第2篇

Ruby on Rails and Android Authentication Part One
(API SERVER)
http://lucatironi.net/tutorial/2012/10/15/ruby_rails_android_app_authentication_devise_tutorial_part_one/

Ruby on Rails and Android Authentication Part Two
(Android APP 連結API)
http://lucatironi.net/tutorial/2012/10/16/ruby_rails_android_app_authentication_devise_tutorial_part_two/

或是直接用

完成後 進入 SPA架構
SPA (React.js+Node.js+Express+MongoDB创建的单页测试应用程序)
https://github.com/huzzbuzz/react-spa-demo

React-router-redux React做Single Page Application (SPA)
https://motephyr.gitbooks.io/nodejs-with-express-react-with-redux-/content/react-router-redux.html

在這個架構當中再包一個 elixir 的 Websockets
使用Phoenix和Websockets创建一个游戏大厅系统 by Alex Jensen websocket game phoenix elixir
https://segmentfault.com/a/1190000007937575

1.登入後如果是一對一OR一般群聊 就將session array 附值({USER_ID:USER_NAME}) 並將相關名稱列出HTML LIST
2.登入連線狀態 將MYSQL/MonogoDB歷史資料寫入 redis
3.SPA 將狀態儲存於 redis (如 當前連接使用者 開始輸入中 開始連結中 送出訊息 斷開連結 操作LOG等)
4.將要傳送的文字數據存入 redis
5.如果離線狀態 將相關紀錄寫入 MYSQL/MonogoDB 並刪除 redis個人KEY的VALUE

目前 redis 的使用時機
redis 頂多是用的方式不好 效果差 不至於不能用(後面有空再陸續惡補這一塊優化用法與時機)
比較抽象還是在 不同語言該怎互相溝通使用
rails api server 主要是避免非正常使用者 驗證正常的操作流程
進入後 SPA 網站架構 並包一個 Phoenix的Websockets
這些工具之間目前還很抽象在互相配合(還是我想太多了 其實這些都只是在同個HTML框架 他們其實都是獨立運作 不需要互相傳參數)


#2

hmm~ 你寫的基本正確,雖然有點亂 X"D

你只需要把資料拆成三部分即可

  1. 純讀取或拋棄沒差的資料(變更時需連動更新,所有資料必須能重建[*有例外])
  2. 必須儲存的個人資料 / 交易資料,通常都是完整的實體資料
  3. 歷史紀錄

其中 (1) 通常頻率很高,類似 session id => user name / user email 這件事情,或是你說的使用者上線狀態,類似歡迎聊天 / 靜音
(2) 通常必須在 RDBMS 內,畢竟是真實交易必須保證完整性
(3) 用 Logger 即可,需要分析時則正規化反向回資料去做分析即可

所以其中 (1) 看你的量,可選 Redis 或 SSDB,(2) 必須保證所以 RDBMS,不過可能依照量來移動資料拆資料庫,否則太肥也吃不消,(3) 一般不管,通常保存一年份即可,出事再說即可

大概就這些唄,按照資料的種類來分即可,所以有些公司聊到後面只有 RDBMS 時 … (( 必須壓抑吐槽的狀況很痛苦的 … ))

*例外,如果你拿 SSDB 來當備存用,則無法 rebuild,此時 SSDB 必須要建立備份機制才行,因為 SSDB 同時有速度和大量的兩個優點,所以可以同時存放 1 & 3 的資料就是,但內部是 single process 實作,所以部分狀況類似要刪除時,可能會拖累"所有的 server" …


#3

好的 今天已經在玩相關工具 前面應該沒啥問題 但是要改寫一些東西 語法就得自己花時間去摸一下

備份的部分 現在網路上有人在賣無限容量的google帳號 倒是可以定時拿來做異地log備份 好便宜阿~雖然不是很安全@@

(但是僅僅是異地資料 如果有臨時狀況立刻可以由另一邊來corver)

然後做完可以再加一些推播 或是擴展開發 感覺不錯啊~

先謝過jc大嚕~:grin:


#4

要再來問結構的問題

因為我感覺我自己邏輯錯了 但是也不太敢肯定

我原本是想 rails 包 nodejs 在包一個websocket

但我怎樣想 感覺邏輯上怎樣都不對阿

按正常擴大使用的框架

API Server應該是一個獨立的存在
最好是一個獨立的硬體設備來運作

如果把 API Server 攻陷 頂多是其他需要API驗證的服務無法使用 也不至於有其他的事情(金融體系除外…)

其他的服務都應該是在外圍設備然後連回API SERVER 去做驗證 (例如登入 或是金融類身分驗證 或是一些機密性質需要驗證的項目 或者是電腦來源 行動裝置來源)

我想我這樣的想法 應該才是對的吧@@


另外想問 api server 不一樣的東西做出來 效果是差在哪裡??

今天弄了一個 Rails 5 API 底下是 DEVISE 然後裡面也是有auto_key

然後也有看到 json api 架出來的 一般格式 沒有 auto_key

另外一種 是jc大推薦的 Doorkeeper / Grape / Swagger

我自己可以看到的是 用 Doorkeeper / Grape / Swagger 這種自幹模式 可以去掉不需要的框架 省資源???

但是不清楚他們之間的差異是在哪??


#5

沒有誰包誰的問題,而是誰處理誰來的需求即可

              聊  天
                |
  網頁/APP ------------- API

今天假設你三個系統都是不同語言寫的,則盡可能使用同一個 DB 群體來做聚集即可,也就是每一台都會連到 RDBMS / Redis / memcached 取得當下適用的資料即可,而不是外部傳入(會有變造危險)外部彼此對傳的只有 session_id,甚至把代辦事項也都寫在 redis 也是可行的(類似之前需要用 get / post 的資料先存在 memcache 後,轉到另外一台,該台去 memcache 內撈,就可不把資訊流的過程對外)

類似登入只能用網頁 / APP 登入註冊,則去 Redis / memcache 裡面塞一個 session_id => user_id 的資料,則到任何系統都知道登入的使用者是誰,自我檢查能做什麼事情,類似網頁 / APP 登入後可以進入聊天室(使用帶有 session_id 的網址過水,或是單純的 cookie 轉移),兩人有交易或是狀態變動時去 API server 做修改,大概就是這樣的想法哩,所以每段都是自我維運的,沒有誰包誰就是了

而會出現的誰包誰只有"流程上"會出現,類似必須先登入才能使用系統,所以一開始的入口點就是 Web / APP,但對子系統切割的思維上應該每一個系統都是獨立且自我營運的就是

另外的問題,如果用 Doorkeeper / Grape / Swagger 做出來會不會比較漂亮?你要先搞清楚這三個目的哩

Doorkeeper 主要用在第三方廠商來串接你們家的 API 時,你們家 API 想開得像 Facebook 一樣的,需要認專案和 key 才能溝通的狀態下才需要使用的(還可出現類似臉書的"你確定要授權嗎?"的畫面),一般如果單一公司對使用者根本不需要就是,因為你會使用類似 Facebook 的類似 omniauth 登入即可,因為 provider 是他而非你自己

Swagger 這時候不應該拿出來講,因為他只是一個包裝比較好看的給別人用的機制而已,適合讓別人可試玩 API 的場合,一樣是你開 API 給別人串才需要,自己的作品可不加,所以自己用 Grape 即可,至於 Grape vs Rails API 誰優誰劣…差異太小了反而無法比較,或是比較沒意義||||

so~ 你用 route / controller / action 還有 Grape / Rails API mode 兩個都可以做到你所謂的 API server,挑個你想要的來做即可哩


#6

了解

沒考慮到傳遞的資訊變造因素 這樣我就可以先放著這裡 繼續往下做哩~


Doorkeeper / Grape / Swagger 這個東西 反而是用在更進階的一種東西

我猜測大概是在自己的網站 加裝金融機構的驗證API過程 (等於是加密型雙向驗證的一種API驗證應用 包含一些KEY包裝等過程 要更加嚴謹)

而我的只是單作品 實務 到沒這個問題 也不會有多方需要APIKEY的接口

感謝JC解答~:grin: