Splits as Configuration

Comments

10 comments

  • Official comment
    Trevor Stuart

    Francisco, we wanted to quickly follow-up as we have now released dynamic configurations which should address some of your use case.  You can read more in our documentation or on our blog.  Right now, each Split has a minimum of two treatments.  We will keep you updated should this change and/or configurations become a global object accessible and not attached to specific split treatments.

    Comment actions Permalink
  • Dave Murphy

    Hi Francisco, we're looking to prioritize our dynamic configs project in the next 6 months.  More to come.

    1
    Comment actions Permalink
  • francisco.alvarez

    This is great, I'm going to take it out for a spin ;)

    0
    Comment actions Permalink
  • francisco.alvarez

    @Trevor how should I set up the .split file to account for configurations in localhost?

    0
    Comment actions Permalink
  • Bilal Al-Shahwany

    Hi Francisco, each SDK language in our documentation has a section on how to use localhost mode with an sample of .split file content.

    For example here is the Java SDK link: https://help.split.io/hc/en-us/articles/360020405151-Java-SDK#localhost-mode

    Thanks

    Bilal

    0
    Comment actions Permalink
  • francisco.alvarez

    Thanks for the reply Bilal. 
    We used to have a .split file that held the features for localhost, but now when adding the yaml format it doesn't seem to work. 
    Do we need to rename the file to split.yaml?

    0
    Comment actions Permalink
  • Bilal Al-Shahwany

    Hi Francisco, if you like to use yaml file, you do need to pass the yaml file name in the builder call, as its shown in the doc link.

    SplitClientConfig config = SplitClientConfig.builder().splitFile("..../split.yaml").build();

    SplitClient client = SplitFactoryBuilder.build("localhost", config).client();

    If you have questions, feel free to send them to support@split.io, we will be happy to help out.

    Thanks

    Bilal

     

     

    0
    Comment actions Permalink
  • Trevor Stuart

    Francisco - I wanted to check back in here and see if this matched your need. Hope you're well.

    0
    Comment actions Permalink
  • francisco.alvarez

    Hi Trevor. Yes, it did! It's a pretty cool feature.
    The one thing that gave me some trouble is the .yml file for localhost testing.
    I wish I could write the configuration object in a more natural way.

    Current:
    - feature-flag:
        treatment: "on"
        config: "{\"key1\": \"value\", \"key2\": \"value\", \"key3\": \"value\"}"
     
    Desired:
    - feature-flag:
        treatment: "on"
        config:
            key1: "value"
            key2: "value"
            key3: "value"
    0
    Comment actions Permalink
  • Pato
    Hey Francisco,
     
    Thanks for the feedback once again. The reason in this first release we did it as a String in one line was to also support nested structures somewhat seamlessly. For example, see below. This nested structure would be a bit trickier if we follow your desired approach.
     
    That said, we continue to hear feedback and ideas to continue to improve this functionality and make it even more usable for everyone's uses cases.
     
     
    - feature-flag:
        treatment: "on"
        config: "{\"key1\": {\"key1_1\" :\"value_1_1\"} , \"key2\": \"value\", \"key3\": \"value\"}"
    0
    Comment actions Permalink

Please sign in to leave a comment.