记不清是什么时候开始，周末变成了宅在家里睡觉、点外卖、看电视剧，最近我终于意识到了这一成不变的生活，就像是温水煮青蛙，偶尔会感觉貌似被烫了一下，于是，就又做一个决定，以后要把生活过得更充实。
CORS 跨域请求简介
CORS，即Cross-origin resource sharing，跨域资源共享，常用于帮助浏览器实现向不同的域名发送请求的功能。
浏览器为了安全着想，采用了同源策略(即url协议、域名、端口中任何一个不一样，就认定是跨域的)。默认是不允许js向不同的域名请求资源的，这样可能发生CSRF攻击。例如B域名有个删除数据的接口，用户登录了B域名后，关闭网页，当然一般情况cookie会在浏览器保留一段时间，如果用户在访问A域名时，A域名在网页上面悄悄向B域名发送删除请求，如果浏览器没有限制，而B域名的cookie也确实存在，则会造成严重后果。
既然后果很严重，为什么还需要CORS呢，一是前端可能需要向不同的域名获取资源，二是随着前后端分离的发展，前端和后端域名如果不同，也许要跨域，如果相同，那运维就要多加配置去让两者在同一个域名下了，增加维护成本。
需要注意的是，开启CORS后，会有一定的风险，尽量不要将Access-Control-Allow-Origin设置为允许所有来源，即’*’，另外，前端一定要做好数据的验证，对于用于的输入，不要直接拿来作为html元素或者script片段进行执行
Postman 高级用法
Postman，一款功能强大的HTTP调试软件(以前只是谷歌浏览器的插件，现在已经独立成软件)，最近接触到它的一些高级用法，才发现它原来并没有我想象中那么简单，还有很多的高级用法。其主要有如下功能:
- HTTP/API调试
- 测试API接口
- 生成API接口文档
- 监控API接口
- mock接口数据
下面列举一些常用的功能使用方法。
《技巧：如何用一年时间获得十年的经验》
郝培强这个人呢，我微博上关注了他，但是一直依赖对他都不是很了解，包括看完了这本书，对他本人也不算了解，倒是更了解他的前妻和现在的妻子，如果感兴趣可以关注以下她妻子的公众号，我也是非常喜欢阅读的。无论是微博上还是圈子里，大家对他的平均都是褒贬不一的，这本书也确实有点“单薄”，但是不得不说，里面确实有“让我们众生受用的技能和相见恨晚的学习技巧的”。
Python使用graphene-sqlalchemy提供GraphQL接口
关于GraphQL本身的语法，可以参考我写的GraphQL 使用手册。
graphene是为python提供的GraphQL扩展，项目组在GraphQL Python。该项目主要有以下几个特点:
- 提供十分方便的自定义功能，从解析到查询到处理结果，都能够自定义
- 有
Dataloader功能，能解决N+1问题 - 与流行框架有现成的集成扩展
graphene-django、flask-graphql、graphene-gae以及通用的graphene-sqlalchemy - 支持复杂的Relay查询
- 支持复杂的
Connection查询，能实现分页的功能 - 支持
NoSQL、MySQL甚至直接支持Python对象作为数据源 - 最大的缺点是，文档写得太简单了，高级用法全得靠自己摸索
下面以实际的例子来说明如何使用，毕竟官方文档那啥。完整的例子见我的gist: graphene-sqlalchemy使用示例
GraphQL 简介
Github的API在V3版本使用的是Restful风格的API，在V4版本则完全使用GraphQL风格的API，我也是从这儿开始认识的。准确地说GraphQL是一种用于API的查询语言，我们可以使用它来构建强大的API。
GraphQL的优点
- 服务端所有请求入口一般只有一个
/graphql - 查询语句一般只使用
POST或者GET请求中的一种，一般不会使用其他的的HTTP动词 - 服务端统一定义资源数据结构，返回数据结构于请求数据结构一样
- 客户端想要什么就请求什么，不要的字段就不获取，不多不少，
Restful API可做不到这一点 - 客户端如果想要关联的数据，只需要一次请求，而
Restful API则需要N次 GraphQL是为了用API的人爽，REST是为了写API的人爽
使用nginx+uWSGI部署Django/Python应用
使用Django可以追溯到15年，但是这还是第一次使用Nginx+uWSGI的方式对其进行部署，以前要么是小项目直接runserver，要么用nginx做http转发，但是使用Nginx+uWSGI明显是部署Django最好的方式了。至于为什么一定要用这样的方式，这篇文章讲得比较好《部署Django项目背后的原理：为什么需要Nginx和Gunicron这些东西》