偶然在微博看到在SegmentFault上的一个共享Header和Footer的问题,而正好我们也解决了这个问题。在这里,就分享一下我们的经验咯。
我们的业务环境和58同城、搜房网这一类站点差不多。我们维护的站点主要有三个页面:
总体上和Google类似,有一个简洁的首页,一个搜索结果页,以及目标网站页。在旧有的系统中,这三个不同的页面都是同一个代码库中。
而对于我们的新系统来说,这些都是独立的项目。因为我们需要同Google一样可以快速打开首页,首页就变成了一个部分内容是动态的,但是大部分时间是静态网站。这一点可以参考我之前的另外一篇文章《编辑-发布-开发分离》,仅仅只在编辑更新内容的时候,才生成新的首页(静态页面)。在这时,由于能限制用户的访问速度,莫过于CDN了。
同时,我们还有几个不同的博客及十几个引流站点,这些都需要使用同样的Header和Footer。对应于我们的其他页面,我们使用React来构建,这意味着我们需要不同的模板。
并且当我们在设计新的系统的时候,我们有了一个更新网站UI的计划。这意味着我们在替换旧有的系统完成之前,我们需要更新所有网站的UI,WTF!
So,在这时我们设计了第一个Share Header和Footer的架构。
接着,由于Release时间的限制,我们并没有在一开始的时候实现基于脚本的共享方式。因此我们使用了内部的UI框架,同时这个UI框架将会在我们的所有站点上使用——我们可以使用同样的HTML和CSS。
因此在我们的新站点上,我们使用基于Bower与GitHub的Release方案——我们使用Grunt作为构建工具。每次在本地启动Server的时候,我们都会更新依赖。因此,在我们的站点上,我们只需要更新bower.json中的版本号即可。
而对于我们的旧有站点上,因为是一个遗留系统,没有这么先进的工具。并且从理论上来说,不应该会太多的时间和精力在上面,于是我们选择了手动复制的方案。
对于博客和其他站点,一部分使用手动复制,一部分使用iFrame加载。因此在Release新版本的时候,我们会上传新的Header和Footer到AWS S3上。
对于iFrame的站点来说,他们就实现了动态更新。对于其他站点来说,就需要手动更新。虽是如此,但是对于业务已经固定的网站来说,Header和Footer只会一年更新一两次。不过,如果发生收购和被收购时,会多更新一两次。
那么,对于那些使用的不是基于HTML,而是使用模板的站点怎么办?
最明显的一个问题就是使用React的站点。因为大部分的模板引擎都是可以支持class="",而React你只能用className=""。所以要么,我们将HTML写在基本的模板文件里,如base.html;要么我们将class替换成className。架构变换成如下所示的结构:
所以,在这时理想的方式就是通过某种类型的模板来生成对应的模板。即我们只需要有一个JSX的模板文件,然后替换其中的相应内容即可。