Ervaring samenvatting
从Namecheap到Cloudflare，如何更换域名的name server
我有很多域名是在namecheap.com注册的。而现在，有很多网站是部署在cloudflare上的。之前为了 […]
ChatGPT+V0+Cursor：不写代码，打造一个出海工具站
大约半年前，看中了一个关键词，是个AI图片生成类的关键词。AI图片生成类的出海工具站，这两年都很赚钱。所以，买 […]
SDXL: Stabiele diffusie gebruiken
Onlangs is er een WordPress-plug-in ontwikkeld op basis van de nieuwste versie van Stable Diffusion XL (SDXL). Stable Diffusion is een gratis, open source model voor het genereren van afbeeldingen en de code kan rechtstreeks worden gedownload via de officiële website Stability AI. Hoewel het duurder en moeilijker is om het model zelf te implementeren, is het mogelijk om een Docker-image te gebruiken of deze handmatig te installeren. Bovendien kunnen grote modellen en API's worden gebruikt of geïmplementeerd via de Replicate.com-website. Over het algemeen worden Stable Diffusion en SDXL veel gebruikt in AI-beeldgeneratieproducten.
Nextjs+next-intl best practice voor meertalige internationalisering (APP-router)
Nextjs biedt twee routers: APP en Page, waarbij Page wordt uitgefaseerd. De auteur gebruikte eerder de internationalisering van de Page-router, maar heeft sindsdien internationalisering geïmplementeerd op basis van de APP-router. Ze evalueerden verschillende oplossingen en ontdekten dat next-intl de eenvoudigste en meest succesvolle is Het bericht schetst de directorystructuur, routing, middleware-instellingen, hoe vertaalbestanden moeten worden geladen en hoe vertalingen moeten worden geïmplementeerd, waarbij wordt benadrukt dat, ongeacht de gekozen internationaliseringsoplossing, routing, bestandsstructuur en vertalingsimplementatie belangrijke aspecten zijn.
Nextjs+I18n best practices voor meertalige internationalisering (zoekmachinevriendelijk)
注：这个最佳实践是基于next的pages路由。并不适合app路由。 目录 基本思路 使用next-i18ne […]
Google Gemini: 如何使用Google的大语言模型Gemini
Google的多模态大语言模型近日发布。Google Gemini 官网 Google Gemini分三个版本 […]
新版WordPress体验：用SAAS、低代码和无代码的方式构建网站
2023年11月06日，Wordpress v6.4.2发布。 两天后，我迁移自己的博客到别的服务器上。之后顺 […]
虚拟航司业务线复盘——供应链的增长与架构
一、机票的大局 1、商业生态 自从互联网和OTA的大发展之后，机票这个业务逐渐形成了平台和供应链两种商业形态。 […]
拆掉低代码平台——生成式才是低代码的方向
熟悉我的朋友都知道，疫情期间，我自己码代码，码了个BAAS（后端即服务的云计算平台）和一个低代码平台。 之所以 […]
会员订阅模块的迭代
对我自己做的平台型CMS，会员订阅这部分一直是“简单实现”。这个周末重新对这部分做了架构，并把核心部分开发完成。
一、方式
会员订阅，一般来说，主要包含：会员订阅计划及购买、会员权限控制、会员管理三个部分。
1、对于会员订阅计划及购买
准备基于已有的商城系统做一些扩展即可。
2、对于会员权限控制，
这个得特别说一下，不打算基于角色权限系统来做，而是单独做一个会员控制的系统。
基于角色权限系统，把会员做成一个角色系列，把每一种会员做成这个角色系列中的角色。听起来，似乎很合理。但是，这样的话，无论做起来还是用起来，都特别麻烦，尤其是业务比较多的时候，各种逻辑会很复杂，一不小心就会造成各种混乱。并且也不够灵活。
而且，实际上，很多优秀的系统的会员订阅部分，也都不会基于角色。而是基于“标记”或者基于订单来实现权限控制。包括wordpress的很多卖得很好的会员订阅类的插件都是这样来做的。
基于“用户标记”：
本质上，其实和角色系统原理一样。就是定义一些会员的“标记”，购买了与这个“标记”关联的会员订阅计划的用户会被“打上这个标记”，这样就能实现会员权限的控制。
基于订单：
购买会员订阅计划，形成订单，支付后，将到期时间写入订单。所以，就可以根据订单来判断用户是否是会员、是哪种会员，以及是否已过期。这样就可以对控制会员权限。
之前曾经做过基于订单的方式，这次打算基于”用户标记“。
基于订单并没有什么不好，只不过，我现在做的这个平台型CMS的订单系统支持的订单类型比较多，造成订单模型比较”庞大“，不打算再给它”增加体重“了，所以选择基于”用户标记“。
3、会员管理
基于现有的用户管理扩展，不打算单独做会员管理。
二、适用场景
1、基本场景
整个产品有一个或几个订阅计划，用户购买，享受会员服务。
全局定义会员标记，每一种会员标记至少包含name、slug、关联的订阅计划id，三个字段。
当用户购买了某个会员标记的订阅计划，此会员标记和到期时间就会被写入此用户的meta数据中。
2、平台/多租户场景
对于平台和做多租户SAAS，有一个很重要的场景：供应商自己提供的订阅计划。
在供应商的用户的meta数据中定义此供应商的会员标记，供应商的会员标记的key和全局会员标记的key不能相同。
当用户购买了此供应商的订阅计划后，相应的会员标记和到期日期就会被写入到购买用户的meta数据中。
这次的迭代只实现基本场景即可，但要能扩展到平台和多租户场景。
三、登录时判断会员是否到期
用户登录时判断是否到期，如果到期，更新meta数据中的会员标记为false、到期日期为false。
