I feel it's more of a platform service, used across all the services in RDS. Ans : Not only RDS it can also be given to external people to integrate it.
We can use this to release a feature, to allow a subset of people to access the feature. (beta users)
Ans : for 1% of users, to a specific user or to a group of users.
The backend is build in node js
Ans : We need to check some language which is highly quick (very scalable and responsive)
The current database is Mongodb.
Ans : We can check on the database to be on Mongodb or move to Dynamodb.
Open questions
what are the features that are yet to be developed?
Already developed paths
GET Feature Flags
create feature flag
edit feature flag
delete feature flag
find feature flag
Is the UI developed completely?
Ans : Not yet
Is this deployed somewhere?
Ans : No
Are we having plans to move to AWS -> yes
what all AWS services are we planning to use?
Ans : Lambda(serverless) based on pricing.
Since its platform service, I feel we have not created an SDK, should I explore how it can be done?
Ans : Yes, we can check on creating an SDK for react native, SDK for native android, SDK for web, SDK for ios. (create epics
for them)
What all sites are we trying to integrate to?
Ans : All sites.
How user management is handled, explore that.
Ans : we have user model , we can use that.
If MongoDB, how are we planning to host it self-managed or cloud-managed?
Ans : Look at the price diff and decide on that.
How much scalability do we want the service to serve?
Ans : For now around 2k to 2.5k users.
What should be the runtime? Docker or lambda?
Ans : We can start with Lambda and move to docker based on the usage.
Choose the language based on the runtime.
E.g Java takes time for cold start in lambdaAns : To avoid coldstart we can use Cloudfare workers, it doesn't have coldstart like Lambdas.
How much scalable is railway.app (the current deployment platform for website-backend)
What is the pricing for railway.appAns : Currently we use the free tier
Memory per container. 512 MB
CPU per container 2 vCPU
Shared disk 1 GB
The database can be SQL or NoSQL (need to think more on this)
Ans : Mostly it will be NoSql.
Look out for how the existing feature flag service works launch darkly
The plan of release should be like
Version - 1: Have the feature flag enabled on the user level (for a user)
Version - 2: Have the feature flag enabled on the group of users
Version - 3: Have it for a percentage of users
How the user journey would be
Ans. How feature flag can be created -> from dashboard site by super_user
The feature flag would be accessed by consumer to check if the user is authorised to use the feature.
Check on the user API, do we have an API that returns the users belonging to a group (This is for version-2)
The data access pattern will be like
a. get me all the users belonging to the group
b. get the feature flag for a user
c. to get X per cent of random users, which do not have the feature flag enabled.
Create API designs by @vikhyat187
a. To create a feature flag
b. To read a feature flag
c. To update a feature flag
d. To delete a feature flag
We can use Dynamodb for database
Gaurav will compare the costing between Docker with least memory and lambda
My understanding of feature flag service.
Ans : Not only RDS it can also be given to external people to integrate it.
Open questions
what are the features that are yet to be developed?
Already developed paths
Is the UI developed completely? Ans : Not yet
Is this deployed somewhere? Ans : No
Are we having plans to move to AWS -> yes
Since its platform service, I feel we have not created an SDK, should I explore how it can be done? Ans : Yes, we can check on creating an SDK for react native, SDK for native android, SDK for web, SDK for ios. (create epics
for them)
What all sites are we trying to integrate to? Ans : All sites.
https://github.com/Real-Dev-Squad/todo-action-items/issues/59 https://www.atlassian.com/continuous-delivery/principles/feature-flags