flagr
flagr copied to clipboard
Feature/import and export flag
The changes in this PR are about adding the capability of import/export flags into the system.
Description
I thought that it can be handy to copy flags from different environments and to enable an easy way to bootstrap the system from flags list.
Motivation and Context
I tend to use flagr in two different environments - DEV and PROD. When I need to add a new flag, first I add it to DEV, then create the same flag manually in PROD. I found it useful to automate the process I tend to do and make it easier to use this library.
How Has This Been Tested?
Locally, manually.
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
Codecov Report
Merging #272 into master will not change coverage. The diff coverage is
n/a
.
@@ Coverage Diff @@
## master #272 +/- ##
=======================================
Coverage 81.76% 81.76%
=======================================
Files 26 26
Lines 1530 1530
=======================================
Hits 1251 1251
Misses 210 210
Partials 69 69
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 7979b1d...d2cc332. Read the comment docs.
nice!
Thanks for the PR! I appreciate the effort, but I think assembling too many requests and logic from frontend is no better than exposing the export/import logic via Flagr's API.
My thoughts of Flagr API for export/import
- Frontend code is harder and fragile to test, ideally, two APIs should be enough.
GET /export
andPOST /import
- Assemble the logic to the backend allows higher abstraction. For example, we can use swagger to clearly define what's the expected format for
POST /import
, and put enough validation code to gate the input. - It allows not only Flagr's UI to leverage the export/import, but also programmatically for other clients.
- From Flagr's current API, we already have export to sqlite3 and evaliation_cache's JSON format, it's easy to extend to export flags' JSON format. https://checkr.github.io/flagr/api_docs/#tag/export
Also, for critical UI like this, I'd like to have a dedicated page/tab for export and import, a mistake for clicking the import in production can be very dangerous.
@yosyad What do you think?
Thanks for the PR! I appreciate the effort, but I think assembling too many requests and logic from frontend is no better than exposing the export/import logic via Flagr's API.
My thoughts of Flagr API for export/import
- Frontend code is harder and fragile to test, ideally, two APIs should be enough.
GET /export
andPOST /import
- Assemble the logic to the backend allows higher abstraction. For example, we can use swagger to clearly define what's the expected format for
POST /import
, and put enough validation code to gate the input.- It allows not only Flagr's UI to leverage the export/import, but also programmatically for other clients.
- From Flagr's current API, we already have exported to sqlite3 and evaliation_cache's JSON format, it's easy to extend to export flags' JSON format. https://checkr.github.io/flagr/api_docs/#tag/export
Also, for critical UI like this, I'd like to have a dedicated page/tab for export and import, a mistake for clicking the import in production can be very dangerous.
@yosyad What do you think?
I think that you are right. We can preserve the existing UI, maybe move it to another page, and implement all its logic in backend.
@yosyad Any progress?
Stale pull request message