上一节，我们简单讲了一下Scratch 3.0的背景介绍，以及如何在本地编译运行的内容，对于采用面对面的教学方式，如果部署在局域网，这种方式应该也足够了。Scratch 3.0的脚本可以存放在本地，如果是公用电脑，可以使用目录的方式分开存放，如果是学生自带的电脑，那么就自行存放。
面临的一些限制
但这种方式也有些问题，进入高阶后，很多内容都需要素材，这样就需要能够分配一个初始的含有素材的脚本。虽然sb3（Scratch 3.0文件）可以通过copy的方式传给各个电脑，但毕竟不方便，如果学习的进度不同 ，管理起来就更加麻烦。另外，如果是公用电脑，那么学生就不能在家里对作品进行修改。
如果要方便上述的需求，就需要有后台的功能，至少可以进行课程的设置，并且将学生的进度与课程关联起来。
假设我们要实现上述功能，我们首先面临的是技术选型的问题，采用什么样的后台方案与前端进行配合。因为前端已经确定了，Scratch GUI使用的ReactJS，也就是说，它是一个SPA（single page web application）的应用，那么他的UI展现是在客户端渲染的，而不是在Server生成HTML页面再返回客户端的，因此，不需要SpringMVC这样的服务端MVC类的框架，我们只需要能够支持Restful API的框架就可以。
可选择的框架
可以选择的范围很广，Jakarta EE，Python Diango，PHP…，有了后台，必然要对前端进行改造，前端是确定，那么JS就是必须的，因此，大家也可以考虑使用JS进行全栈开发，那么后端就可以采用Nodejs。数据库，如果是对关系数据库比较熟悉，那么可以使用Mysql，但如果采用nodejs，我建议可以考虑mongodb。
JS
先说一下JS，学习ReactJS，首先要对ES6比较熟悉，现代的语言发展，其中一个目标是让语言越来越精炼，如果大家比较一下ES6, Python和Java 8之前的版本，就会发现一些差异，比如ES6不需要语句用”;”结尾，一些新的操作符“=>, …”，有些情况下可以省略return语句，比如
const addColor = (title, array) => array.concat({title})
上边的函数是返回一个新数组， Python 的代码段不使用{,}，而采用自然缩进。所以，现代的编程语言变得越来越短小精湛，也因此可阅读性和维护性越好。
ES6中有Class的概念，但它的实现与OO语言C++/Java等不同，不是虚函数而是原型链。JS是解释性的语言，而不是像其他语言需要编译后执行，所以他的编码风格也与OO语言有较大的不同，它更偏向Function Programming，所以，ReactJS中的Class主要用于一些组件的实现上，大家可以看一下Scratch 3.0 GUI的源码，使用Class的原因是要管理组件的生命周期，如果可以话，应该尽量的使用Function Programming而不是Class，他的效率要高于Class，而且，你会发现，写出的高阶函数会很漂亮。
Scratch 3.0 采用的是React Redux， Facebook 提供的一套解决方案，我个人觉得这个架构比MVC的架构要好一些，这方面的资料很多，大家可以学习一下再自行比较一下。
Nodejs
再说一下后端采用的方案，Jakarta EE的方案很多，这里就不做介绍了，这里提一下nodejs的方案。Nodejs采用google的V8引擎，使用js语言，所以它与Java的编译后执行的语言在代码执行层面上的效率会有差距，另外，Nodejs是单线程的，Java是多线程的。但Nodejs使用的是异步回调的方式，大家可以参照一下Nginx的架构，所以Nodejs在应对大规模并发的情况下，表现十分优秀，相对多线程也更加容易调试。另外，Nodejs的开发、部署比Jakarta来说，那便利的就不是一点点了。
Nodejs的开发一定要熟悉异步编程的模式，对Promise的使用要得心应手，NPM中有太多的Module来实现Restful API，比如Express。
Mongodb
最后再说一下数据库，关系型的数据库大家都很熟悉，但如果采用Nodejs，我个人的建议是Mongodb，这种No-sql的数据库在数据结构上与JS语言是一种自然的结合，不像在使用ORMapping的架构中，你要编写很多的代码或者配置进行映射，在Nodejs中，会是一种自描述的编写方式，比如：
Work.updateOne({
_id: work_id
}, {
$addToSet: {
'sections': section
}
})
.then(doc => resloves(doc))
.catch(e => rejects(e))
这样的代码的可读性更好一些！。
好，这一节我们主要讲了一下后端技术选型的问题，下一节，我们再讨论一下业务逻辑的一些简单考虑！