HackerTrans
トップ新着トレンドコメント過去質問紹介求人

tushr

no profile record

投稿

Show HN: FFlags – Feature flags as code, served from the edge

fflags.com
42 ポイント·投稿者 tushr·12 か月前·36 コメント

Replit replaced thanos with this

last9.io
6 ポイント·投稿者 tushr·2 年前·0 コメント

Show HN: A simple understanding of High Cardinality

highcardinality.com
2 ポイント·投稿者 tushr·2 年前·0 コメント

コメント

tushr
·11 か月前·議論
I have a bias but I would still suggest using feature flags even for on/off functions. Example of how I do it:

https://x.com/ctushr/status/1949215574980272177
tushr
·11 か月前·議論
You can checkout my reply to the same comment. I have explained it in terms which is easy understand for everyone.
tushr
·11 か月前·議論
I am surprised that tools like Gemini CLI and Claude Code are not doing this by default.
tushr
·11 か月前·議論
These features are in pipeline. It is currently targeting the developers to help them with rollbacks and release management.
tushr
·11 か月前·議論
> product, not eng, will start managing the flags at some point and needs easy access

That's the typical pattern and why most tools focus on non-technical UIs. FFlags targets a different niche. Teams where developers want to maintain control over flag logic.
tushr
·11 か月前·議論
You are right, feature flags are just toggles but the devil is in the details. When the product scales you would want to test things internally or with a close group of people on prod before you make it public (beta releases). Sometimes you would want to release features at a specific time (Apple, Figma product launches). Sometimes you would want to test if A is working better than B (A/B testing typically in eCommerce sites). Sometimes features are location-specific (Different content for different countries, netflix does this). Let's consider a scenario: You have a team of 10 engineers working on 5 different features. They merge their feature branches to a main branch which gets deployed at the end of the release cycle. Now, if one of those features isn't working as expected, the engineers will have to roll back to the last deployment which won't have any of the 5 features. With feature flags, this could be avoided by developing all features behind a feature flag.
tushr
·11 か月前·議論
That's a fair point! Basic feature flags are just toggles, true and false. But they quickly become complex as you onboard new customers and scale. You need percentage rollouts to make sure things are working before everyone starts using the features. It only makes sense for engineers to spend time building actual features and testing them in production rather than spending bandwidth on building a feature flag management tool or managing the service for the same. This is a typical build vs buy debate. :D
tushr
·11 か月前·議論
Aah! That's a miss from my end. I had it on my previous landing page. It is 100k requests a month. But, I am not adding any cap right now. I monitor the system all the time so if it goes above the free tier limit significantly I will notify.
tushr
·11 か月前·議論
Hey, Thanks! I recorded it using https://screen.studio/.
tushr
·12 か月前·議論
That was the main pain-point I faced in the orgs I have worked with. When I came to know about the OpenFeature I was instantly gravitated towards building this on open standards.
tushr
·12 か月前·議論
Thank-you! Do let me know how was your experience if you to use it.
tushr
·12 か月前·議論
This is an interesting projects. Did you get to explore how you can do the same with the dynamic documents? For instance, a google doc or MS Word file which keeps on changing with every change the graph must update.