寫了一個deno 的demo，說說個人見解

上週某個普通的一天，deno 1.0發佈了。因而利用業餘時間寫了一個服務端的程序。 GIT：https://github.com/shinku/deno-demokoa 之於 node，至關於oak就之於deno了。 雖然是奇怪的設定，不過僅僅換了個字母順序而已，koa 和 oak 就是一個同父異母的雙胞胎呀。

router .get("/", (context) => { context.response.body = "Hello world!"; })

 

以及

app.use((ctx) => {// Will throw a 500 on every request. ctx.throw(500);});

 

koa 與oak有着幾乎一致的kpi，因此對於有node經驗的開發人員來講，是很是友好的。 我嘗試着用deno 寫了一個靜態資源服務器。koa中有個koa-static能夠直接使用，可是oak中還缺少這個包，因此即使他們長得類似，積累上的差距仍是挺多的。

想到這裏，萬一後期阿里的egg換了deno運行時，會不會更名叫：geg

我索性利用了oak 的洋蔥模型的原理，簡單寫了一個static的oak中間件。

定義一箇中間件的基本方式：

export default async (context:any,next:Function)=>{//塞點內容進來}

 

根據文件請求路徑去服務器的服務器中訪問文件：

const data = Deno.readFileSync(_static+filename);

 

做爲返回主體，設置response的body。

let {response,request} = context;response.body = data;

 

而後我再寫了一個緩存的模塊，將請求資源的路徑和data 作個映射，確保在下次訪問的時候直接去獲取內存中的數據，減小再次讀取文件形成的資源開銷。 根據文件名分別處理了一下返回的headers的content-type的內容。 以上大體這些內容，我把這個文件放在了並起名爲static.ts的文件中

app/utils/static.ts

 

因而，結合oak的中間件邏輯，監聽8000端口（也是koa的中間件邏輯）。

import { Application } from "https://deno.land/x/oak/mod.ts";import _static from "./utils/static.ts";const app = new Application();app.use(_static);console.log('start at point :8000');app.listen({ port: 8000 });

 

運行了deno的啓動命令：

deno run --allow-net --allow-read index.ts

 

項目順利啓動了。當我將文件放在工程裏面指定的目錄下，用特定的url格式去訪問他們的時候，他們如約的出如今了個人瀏覽器中。

第一次編譯的時候，會從denoland上下載ts的代碼資源，拉到本地，再在deno的運行時中編譯成js文件，提交給V8引擎作最後的編譯。因此第一次編譯會比較耗時，後期的編譯會比較省時間。

TS的編譯過程在整個服務的啓動以前，也就是說實際上運行過程當中徹底不用考慮ts的編譯問題。因此相比較nodejs，deno的運行效率和node 應該是如出一轍的。

目前沒有找到一個相似於pm2 或者supervisor 的進程管理的工具，因此我每次修改service 的代碼以後，得反覆使用ctrl+C的方式退出當前進程，涉及到端口占用，還得強行運行一次「pkill -9 deno」暴力的關掉deno對於端口的佔用，以後再起一次deno的啓動命令。整個過程對我身心形成了不小的傷害。

const run = ()=>{ return Deno.run({ cmd: ["deno", "run","--allow-net","--allow-read","index.ts"], cwd:"app", }); }let _porcess = run();const watcher = Deno.watchFs("./app");for await (const event of watcher) { console.log('kill proceess'); _porcess.close(); console.log('restart'); _porcess= run();}

 

因而我將deno的啓動項的代碼由

deno run --allow-net --allow-read index.ts

 

替換成了

deno run --allow-net --allow-read --allow-run launch.ts

 

這樣我再改動app目錄下的代碼，並須要驗證效果的時候就，就會自動從新編譯啦。

涉及到的三個allow相關的tag的意義：

• --allow-net ：容許從遠程下載資源，deno 運行時須要拉取遠程模塊的時候必須
• --allow-read：容許調用deno的文件讀取的相關權限，deno應用須要訪問本地資源的時候必須
• --allow-run：容許啓用deno.run實現本地命令行調用，deno 中用到各項命令行操做的時候必須

這些allow在必定程度上起到了安全性的做用。

 

deno 區別於nodejs 對於第三方包的引入方式：

import { Application } from "https://deno.land/x/oak/mod.ts";

 

這種代碼讓我對於包管理的方式缺少安全感，不像 rust開發同樣有個cargo.toml 能夠統一管理因此調用的第三方包。因而我將第三方包都寫在了lib下一個專門的ts去管理

import * as oak from 'https://deno.land/x/oak/mod.ts';export { oak}

 

這個文件也能夠做爲後續管理其餘全部第三方包的入口，其餘業務模塊須要用到這些第三方模塊的時候都經過import 這個本地的入口，多少給了我一些安全感。

做爲學不動的一方，如下是我在使用deno後的一些感想。。。。

• 沒有了node_modules的存在，整個項目代碼結構看起來舒服很多。
• typescript 的全方位支持也讓開發過程的體驗有了質的飛躍，這表明着咱們不用再去顧及typescript 的編譯過程，和雜七雜八的webpack的配置項和插件；
• 沒有很是有效的包管理工具，使得使用過程當中對第三方模塊的使用沒法直視，缺乏安全感，因而要嘗試本身去寫一些模塊管理這些模塊；
• deno最終是由rust 編寫，可是最後並無沿用cargo的那一套很是友好又標準的包管理機制和運行時監聽工具，因此目前調試過程仍是比較繁瑣；
• 目前尚未一個有效的相似於pm2的進程管理工具，意味着若是我要上一個deno的項目，我得先在服務器上裝個docker？
• 官方在標準庫上還缺少更多的佈局，因此會以爲相對於普通開發者來講如今，還不適合使用deno開發生產業務

因爲纔剛剛發佈的版本，和nodejs 比較生態確定是不公平的，至少在開發體驗上來講，像是輕裝上陣，卻是輕鬆了很多。相比較於node目前的規模，deno並無解決什麼特別大痛點：node_modules包的存在能夠說有利有弊吧，ts的編譯能夠經過webpack搭建實現；deno的運行加了些權限限制，相比較於node來講業務的安全性獲得了必定的保障。

「大清亡於閉關鎖國，學習技術須要交流和資料」。 在這裏我給你們準備了不少的學習資料免費獲取,包括但不限於技術乾貨、大廠面試題系列、技術動向、職業生涯等一切有關程序員的分享.web前端小白進階方法筆記,學習資料,面試題和視頻,項目源碼免費領取（持續更新）