<aside> 💡 Notion Tip: 又是一个一个闲出屁的 IDEA

</aside>

构思了一个很简约的 node 服务端框架

1. 减少模板代码（反例 Nestjs & Spring）
2. 设计的足够合理 （反例 express）
3. 一个编译器（该想法来源于 svelte）

我的想法

1. 要像写配置文件一样写后端
2. 功能的标签化 （TSX/JSX）
3. 拥抱 Deno
4. 接入第三方极其方便

登陆：

import { Service, Contorl, Modal } from '<https://reme.icecee.com/core>'
import { Container, App } from '<https://reme.icecee.com/lib>'
import ORM from 'ORM'
import setting from './setting.gen'

interface IProps {
	username:string
	pwd: string
}

<Modal name="User">
	<out>new ORM.user()</out>
</Modal>

<Service name="Login" useModal={[User]}>
	<in>username</in>
	<in>pwd</in>
	<func>
		const checkID = aysnc () => {
			const user = User.out
			const { data } = await user.findOne({username, pwd})
			if (!data) {
				return false
			}
			return true
		}
	
		const main = aysnc () => {
			return await checkID()
		}
	</func>
	<out async>main()</out>
</Service>

<Control name="Login" setting={setting}>
	<in type={IProps}>{username, pwd}<in>
	<out>Service.Login({username, pwd})<out>
</Control>

Container.registry(() => <App name="tototo" contorls={[Login]}/>)

仔细想想这玩意似乎有些脑瘫，一堆模板的代码，又麻烦，概念好像又多，既然这样为什么我不去写隔壁的 Nestjs 。而且如果按照写配置文件来写这个东西的话就有一堆的问题，比如如何让项目的目录结构清晰，我们知道 Nestjs 目前最大的问题就是目录结构如何整理，这一点毋庸置疑是 Node 的锅，既然我们毫不犹豫的选择了 Deno ，那么就不应该再因为这种问题瞎想了。

之后我又想了一个问题，就是真的要用 node 完全用来搞服务端吗？我们知道，js 是单线程的，不适合做密集运算，所以需要把密集运算的部分集中到另一个适合密集运算的服务器上，而且 node 比较是适合当中间层，适合将后端的通用接口整合成专有业务的接口，减轻前端的负担。（cluster / MW的话，建议不要使用 Proxy 来进行线程的交换数据的管理，文件操作符直接能把服务器快乐死）