Egg.js

Egg.js 目录结构介绍 、定义 controller 以及配置路由、Egg目录约定规范

亡梦爱人 提交于 2020-05-08 09:51:04
1 、 Egg.js 目录结构介绍 2 、 Egg.js 目录约定规范 egg目录结构以及执行流程 代码: 路由配置 router,.js /* * * @param {Egg.Application} app - egg application */ module.exports = app => { const { router, controller } = app; router.get( '/' , controller.home.index); router.get( '/news' , controller.home.news); router.get( '/admin' , controller.admin.index); }; admin.js 'use strict' ; const Controller = require('egg' ).Controller; class AdminController extends Controller { async index() { // egg基于koa // koa给用户相应信息 // ctx.body='用户管理' console.log( this ); // egg给用户相应信息 this .ctx.body='用户管理' ; } } module.exports = AdminController;

轻松搭建基于 Serverless 的 Egg.js Web 应用

一曲冷凌霜 提交于 2020-04-17 07:39:21
【推荐阅读】微服务还能火多久?>>> 首先介绍下在本文出现的几个比较重要的概念: 函数计算(Function Compute): 函数计算是一个事件驱动的服务,通过函数计算,用户无需管理服务器等运行情况,只需编写代码并上传。函数计算准备计算资源,并以弹性伸缩的方式运行用户代码,而用户只需根据实际代码运行所消耗的资源进行付费。函数计算更多信息 参考 。 Fun: Fun 是一个用于支持 Serverless 应用部署的工具,能帮助您便捷地管理函数计算、API 网关、日志服务等资源。它通过一个资源配置文件(template.yml),协助您进行开发、构建、部署操作。Fun 的更多文档 参考 。 备注: 本文介绍的技巧需要 Fun 版本大于等于 3.6.9。 Egg.js 是什么? Egg.js 官方描述为: Egg.js 为企业级框架和应用而生,我们希望由 Egg.js 孕育出更多上层框架,帮助开发团队和开发人员降低开发和维护成本。 Egg 奉行『约定优于配置』,按照一套统一的约定进行应用开发,团队内部采用这种方式可以减少开发人员的学习成本,开发人员不再是『钉子』,可以流动起来。 Egg 的插件机制有很高的可扩展性,一个插件只做一件事。Egg 通过框架聚合这些插件,并根据自己的业务场景定制配置,这样应用的开发成本就变得很低。 Egg 特性: 提供基于 Egg 定制上层框架的能力

egg学习笔记第二天:egg.js目录结构介绍、定义controller以及配置路由、egg目录约定规范、vscode+egg开发工具配置

ⅰ亾dé卋堺 提交于 2020-04-06 20:22:32
今天来介绍一下egg.js的目录结构,以及vscode egg开发工具配置 一、egg.js目录结构介绍 二、egg.js目录约定规范 egg-project ├── package.json ├── app.js (可选) ├── agent.js (可选) ├── app | ├── router.js │ ├── controller │ | └── home.js │ ├── service (可选) │ | └── user.js │ ├── middleware (可选) │ | └── response_time.js │ ├── schedule (可选) │ | └── my_task.js │ ├── public (可选) │ | └── reset.css │ ├── view (可选) │ | └── home.tpl │ └── extend (可选) │ ├── helper.js (可选) │ ├── request.js (可选) │ ├── response.js (可选) │ ├── context.js (可选) │ ├── application.js (可选) │ └── agent.js (可选) ├── config | ├── plugin.js | ├── config.default.js │ ├── config.prod

高德APP全链路源码依赖分析工程

一曲冷凌霜 提交于 2019-12-09 11:43:20
一、背景 高德 App 经过多年的发展,其代码量已达到数百万行级别,支撑了高德地图复杂的业务功能。但与此同时,随着团队的扩张和业务的复杂化,越来越碎片化的代码以及代码之间复杂的依赖关系带来诸多维护性问题,较为突出的问题包括: 不敢轻易修改或下线对外暴露的接口或组件,因为不知道有什么地方对自己有依赖、会受到影响,于是代码变得臃肿,包大小也变得越来越大; 模块在没有变动的情况下,发布到新版本的客户端时,需要全量回归测试整个功能,因为不知道所依赖的模块是否有变动; 难以判断 Native 从业务实现转变为底层支撑的趋势是否合理,治理是否有效; 这些问题已经达到了我们必须开始治理的程度了,而解决此类问题的关键在于需要了解代码间的依赖关系。 二、高德 APP 平台架构 为了消除一些疑惑,在讨论依赖分析的实现前,先简单说明一下高德 APP 的平台架构,以便对一些名词和场景有一些背景了解。 高德 APP 从语言平台上可以分为 4 个部分,JS 层主要负责业务逻辑和 UI 框架;中间有 C++层做高性能渲染(主要是地图渲染),同时实现了一些切面 API,这样可以在双端只维护一套逻辑了;Android 和 iOS 层主要作为适配层,做一些操作系统接口的对接和双端差异化的(尽可能)抹平。 这里的切面是指 JS 层与 Native/C++ 层的分界线,这里会实现一些切面 API,也就是 JS 层与