Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List use-cases relevant to feature toggling #138

Open
HendrikThePendric opened this issue Nov 2, 2020 · 2 comments
Open

List use-cases relevant to feature toggling #138

HendrikThePendric opened this issue Nov 2, 2020 · 2 comments

Comments

@HendrikThePendric
Copy link
Contributor

Hello all,

Below I'd like you to list use-cases that might be relevant for our feature toggling endeavours. Some general pointers:

  • Think of things such as:
    • Changes in API requests (new/renamed resource, changes in request payload/params)
    • Changes in API responses
    • Changes in resource permissions
    • New features (new resource or new properties on resource)
    • Etc.
  • If you're not sure if the use-case you came up with is relevant, but think it might be, write it down anyway

🙏

@HendrikThePendric
Copy link
Contributor Author

HendrikThePendric commented Nov 2, 2020

Here's my list:

  • Support for attachments in messageConversations
  • User model overhaul, resulting in fewer properties to be available and the creation of the userLookup resource
  • Migration from dataTables to visualizations and changes in response shape that came with that migration.

If I think of any other cases I'll update this comment.

@paschalidi
Copy link
Contributor

paschalidi commented Nov 13, 2020

After talking with @Bekkalizer and @JoakimSM we came up with the following scenario:

As of today on the capture app we are using a backend endpoint which is exposed. This endpoint is part of the the importer “service” of the backend.

This is basically a single endpoint which given a variety of arguments the user defines will do actions like PUT, POST, UPDATE and DELETE. They key point is to remember that as of today this is a single endpoint doing multiple actions.

So now there is an effort made by the backend team to rewrite this part of the backend application and provide the same functionality this one endpoint provides. This will result to multiple breaking changes. There is also the possibility that there will be dedicated endpoints for all the actions that I mentioned above (PUT, POST etc) in contrary to the one endpoint that we are having now.

This means basically that part of the Capture app will have to be rewritten a bit when we switch to the new version of the importer since the endpoints contain the same functionality overall, but there will be a lot of small differences between the two versions.

As you can imagine this is something we want to keep in mind while implementing the feature toggle solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants