09 年，由北京的团队开发了 ThinkSNS 涉足社交开源行业。这么多年累计不少客户。2014-2016，两年都在维护和开发之前基于 TP 的 ThinkSNS , 慢慢的引入新开发概念。终于，在2016年下半年，我们决定重写这个程序，抛弃之前的每一行代码。框架上，开发人员一致性的选择了 Laravel ，并取了一个看起来像手机厂商给手机命名的名字----ThinkSNS Plus 没错就是 Plus 也就是符号 + 因为我们更希望侧重移动端，这就是 ThinkSNS+。
起初没想过框架升级的问题，后来思考了一个问题，最后会不会像之前版本一样？框架难以升级？所以我们决定每周一对?laravel/laravel?的 master 分支进行合并，为了表示对?Taylor Otwell?以及 Laravel 贡献者的尊重，每一个 commit 在合并的时候都进行了保留。
由于 Laravel 本身是 MIT 协议，基于 Laravel 开发，我们也希望 ThinkSNS+ 能为开源社区贡献，所以代码上没有采用私有协议，而是选择了 Apache-2.0 协议进行开源。
这块是一个难以选择的问题，我们希望能由内置 Laravel-Mix 的契合度，又希望构建能更适合我们的应用场景，最后，我们选择 放弃 Laravel-Mix 自己做前端构建，衍生出一个新的问题，我们又希望能和 mix 辅助函数无缝配合，看了源代码后，发现问题太简单了，就是一个?mix-manifest.json?的事情而已，但是这个东西却一波三折。
起初，我们选择在?webpack.config.babel.js?中做生成函数，配合第三方包实现，功能实现了。但是如果是拓展包接入也要使用怎么办？最后开发?webpack-laravel-mix-manifest?这个前端包，来生成这个文件。
首选，拓展设计目前有两个，分别是?plus-component?和?plus-plugin?其实都是由 Composer 中间插件实现。
composer 插件?zhiyicx/plus-install-plugin
这个设计其实只是想拓展包可以快速的接入路由模板数据模型这些基础开发，也是中间插件 1.0 版本中唯一实现的拓展方式，存在了长达半年之久，可以快速的写路由、控制器、数据模型，目前我们团队出的应用拓展都是以此方式开发实现。
并封装了?php artisan component?命令安装。
这是一个很年轻的 type 在 composer 插件 1.1 版本中增加的，这个拓展方式实现原理很简单，其实就是 Laravel 的?Service Provider?，熟悉 Laravel 开发都知道，这个服务门面被称之为 "Laravel 拓展" 但是安装并不方便，需要先?composer require vendor/name?，然后在?app.php?的?providers?字段中配置，然后运行命令生成配置文件等。
考虑到 ThinkSNS+ 面向的都是站长、创业者、企业集团等用户，让他们改代码？简直不如杀了他们。所以，萌生了一个想法，如何把这个步骤自动化？让用户只需要?composer require vendor/name?就完成呢？而且，对于例如广播系统的使用，很需要一个这样的东西来方便开发拓展。所以想办法把这个步骤，在 composer require 步骤完成，由此开发了这个模式。
Laravel 的拓展不能直接以这种方式使用哟，因为我们做这个的想法是把配置移交到后台配置。
接口，在初期没有完全考虑?REST ful?所以，你能会看到 URL 命名很像 REST ful 规范，实际数据却不是，后续逐步规范化。
这里提到了 API 接口，意味着一个事情，我们抛弃了传统网页，ThinkSNS+ 核心就是一个 用户中心，然后功能全部由拓展实现，目前后台、手机端 都是采用 SPA 调用接口的形式开发。
开源代码仓库：
GitHub:https://github.com/zhiyicx/thinksns-plus（点击star，每日关注开发动态。）
相关文章
