Support dynamic config

[xingzhan1]

Hi team,

~~This is a feature request for supporting remote logging and dynamic config:~~

~~Remote logging: send logs and metrics from mobile app to cloud for debugging and monitoring purpose, possibly cloudwatch as the solution.~~

Dynamic config: periodically pulling config from cloud, can be used for runtime config, A/B testing, etc. Possibly AppConfig as the solution.

Thanks, Xing

EDIT: Remote logging is being tracked here - https://github.com/aws-amplify/amplify-flutter/issues/1558

[HuiSF]

Hi @xingzhan1 thanks for the request.

If you could more information about the use cases that would be very helpful for use to understand the scope.

supporting remote logging

Do you mean you need an API to allow sending any type of logs to CloudWatch any time and any where in your App?

The Amplify library functionalities are implemented on top of AWS services, such as AppSync, Cognito, Pinpoint etc, each of them should have service level logging mechanism. Take DataStore, you can enabled logging and monitoring within AppSync console (the App associated with your Amplify project), the logs will be generated in CloudWatch and you can query or generate dashboards. You can also learn more about logging and monitoring from Amplify document.

For metrics (if you meant use cases such as collecting data of how your App users use the App), the Analytics category should be able to help.

dynamic config

Currently Amplify libraries common set up API configure allows to be invoked only once, reconfigure at runtime is currently not supported. I think you could set up an infrastructure to serve Amplify configurations, but it would requires your App user to quit and restart the App to apply a new configuration.

A/B testing

I would like to learn more about this as well, do you have any specific example that would required to change Amplify configurations?

[xingzhan1]

Do you mean you need an API to allow sending any type of logs to CloudWatch any time and any where in your App?

Yes, I am more referring to the forntend log and metric in our mobile app, such as clickstream, response time, etc.

The Amplify library functionalities are implemented on top of AWS services, such as AppSync, Cognito, Pinpoint etc, each of them should have service level logging mechanism.

We are using the amplify logging already, but we would like to collect frontend log and metric as well

For metrics (if you meant use cases such as collecting data of how your App users use the App), the Analytics category should be able to help.

We are using analytic already, but we can not build alarm on those metrics. Additionally, analytic does not collect runtime log

dynamic config, A/B testing

This is something different from runtime reconfiguration. Here I am referring to integrating with dynamic config service, like AWS AppConfig, which allows application to pull some data from cloud in near realtime. The use case I have is A/B testing, which shows different feature to customers with different configuration, and by collecting metrics for different features, we can compare different features. This can be implemented by enabling/disabling a block of code by the near realtime configuration.

do you have any specific example that would required to change Amplify configurations?

A/B testing has nothing to do with changing Amplify configuration. But I do have a use case to reconfig Amplify: I would like to test mobile app with different AWS account. We have 3 aws accounts: beta, gamma and prod. We want to push any change to beta, then gamma then prod, and we would like to test in beta and gamma first. Therefore, reconfig Amplify would allows us to build the app once and test it with different aws accounts

[HuiSF]

Thanks for all the details @xingzhan1 !

While we are looking into your feedback, here are some my personal experiences with some use cases that are similar to your description.

• the forntend log and metric in our mobile app, such as clickstream, response time, etc.
• We are using analytic already, but we can not build alarm on those metrics.

We can use Analytics category to record an event with custom attribute, this enables capability to record something like clickstream and response time.

E.g. assuming a user is visiting a online order App

// after user navigates to product details page
// create a event as state of the page
AnalyticsEvent event = AnalyticsEvent('product-details-click-stream');

// when user clicks on product images
event.properties.addIntProperty('product-image', 1);

//  when user clicks on the product detail button
event.properties.addIntProperty('product-details', 2);

// when user clicks on the review button
event.properties.addIntProperty('product-review', 3); 

// when user clicks on the add-to-cart button
event.properties.addIntProperty('product-add-to-cart', 4);

// when user is going to leave from the current page
Amplify.Analytics.recordEvent(event: event);

Here I use the attribute value to indicate the order of clicks. And it's possible to apply any mathematic model here to calculate a result by adding required data points.

Similarly, to record the response time

// assume there is a button that user clicks on to add a product to cart

addToCart() {
  // create an even when user clicks the button
  AnalyticsEvent event = AnalyticsEvent('product-add-to-cart-latency');
  const startTime = DateTime.now().millisecondsSinceEpoch;

  await addProductToCartRequest(); // the API call
 
  // get elapsed time to indicate the latency of add to cart API
  const addToCartLatency = DateTime.now().millisecondsSinceEpoch - startTime;

  event.properties.addIntProperty('latency', addToCartLatency);
  Amplify.Analytics.recordEvent(event: event);
}

All the data points and metrics collected by Analytics category are available under AWS Pinpoint, and can be viewed, collected and analyzed by AWS CloudWatch, which means dashboards and alarms can be created by the metrics, e.g. a latency alarm on the add to cart API.

to test mobile app with different AWS account beta, gamma and prod.

Have you thought about building different binaries with different AWS account configuration for stage testing? Dynamically switching configuration indeed sounds convenient, but it also increases surface of error... which I would personally avoid... imagine somehow something went wrong, all production users are switched to beta stage 😅

[xingzhan1]

All the data points and metrics collected by Analytics category are available under AWS Pinpoint, and can be viewed, collected and analyzed by AWS CloudWatch, which means dashboards and alarms can be created by the metrics, e.g. a latency alarm on the add to cart API.

We do use this feature to track the usage of different pages, but I can not create alarm on those events. Pinpoint only supports alarm on its own metrics.

Have you thought about building different binaries with different AWS account configuration for stage testing?

This is exactly what we are doing today - however this means we need to duplicate the build process three times, which is a bad practice for 'build once, deploy everywhere'.

[jack24254029]

I need this feature. My app has many users from different countries. For example, users of Europe will use config for Europe, users of Asia will config for Asia. If the user wants to login to Europe but the previous login is Asia, the user need to logout, restart the app, and login to Europe.

[tiny-dancer]

To stack on some more dynamic configuration value adds: https://launchdarkly.com/use-cases/

[Jordan-Nelson]

I'm going to split this into two separate feature requests for logging and dynamic config. We will continue to use this to track interest in dynamic config. I will post a new issue shortly to track remote logging.

[Jordan-Nelson]

New issue is linked above ^

[cody1024d]

I have another usecase -- dynamic resolution of userpool information.

Say I want to look up what userpool my user should be logging into. I need to first call to an API (which would require a call to configure), and then re-configure based on the fetched information (userpoolId, etc.)

Unless there's a way to do this that I'm not aware of @Jordan-Nelson

Perhaps going down to the Escape Hatch is my best bet.

[flodaniel]

For reference, these are the related tickets in the native SDKs

Android: https://github.com/aws-amplify/amplify-android/issues/560

iOS: https://github.com/aws-amplify/amplify-swift/issues/1584

[Jordan-Nelson]

Hey folks - I think there are two separate requests with in this thread. The original request from @xingzhan1 appears to be asking for a service that could load any arbitrary configuration data (not necessarily an Amplify config) from a remote server. I think several folks are looking to call Amplify.configure() multiple times or to use a different Amplify config based on region. While these issues are somewhat related (you may want to load your Amplify Config from a remote source, and then call Amplify.configure()) they are two distinct requests.

We will continue to use this issue to track interest in a new service for loading any arbitrary config data from a remote source.

I have re-opened https://github.com/aws-amplify/amplify-flutter/issues/1902 which was originally closed as a duplicate to track interest in calling Amplify.configure multiple times or using different configs based on something like region.

@jack24254029 @flodaniel @cody1024d - I believe you are looking to change the configuration at runtime or to use different Amplify configs based on region, which is now tracked in https://github.com/aws-amplify/amplify-flutter/issues/1902. This is not currently on our roadmap. If you would be able to comment on that issue with your use case, that may help drive the priority.

[krrskl]

Greetings to all!

I for one have a use case of wanting to be able to call amplify.configure multiple times during runtime

The use case is that sometimes the operation of the company has been affected by failures of certain AWS regions, and the idea is to remotely raise a DRP and be able to make that change of regions, for which it is necessary to go back to instantiate amplify