xabaril / esquio Goto Github PK
View Code? Open in Web Editor NEWEsquio is a Feature Toggle Library for .NET Developers.
License: Apache License 2.0
Esquio is a Feature Toggle Library for .NET Developers.
License: Apache License 2.0
At this moment, the base contract for IToggle depends on IRuntimeFeatureStore to get all the configuration data from the store. This is a hard dependency for implementors and also imply many store queries for each feature.
DefaultFeatureService do this query and can get all the execution context to check if toggle is active or not.
The proposal is create a new abstraction like ToggleExecutionContext and pass this to all IToggle with the enought information to evaluate toggles.
Tracking is a fundamental issue in toggles, may it be used to track experiments malfunctions or track usage.
Esquio should be able to track features usage, per session and track possible exceptions derived from features so it can offer usage and exceptions related to toggles.
At this moment, UI can only recover a new Api Key from the store, to be used on integration pipelines like Azure DevOps tasks, but is not possible set the name , expiration time, and managing created Api Keys.
We need to improve the UI and include all necessary to maintain Api Keys!
Include Ring option spec for allow different toggle values depending on actual Ring, the idea is tests different environments, deploys with different feature parametrization.
At this moment, ClaimValue is not honoring all claims of the same type on Identity claims and only evaluate first claim.
This fix is reported on Esquio V2 #111 and is fixed on V2 but we need to fix also on V3
Improve HTTP API
At this momment we have GradualRolloutHeaderValueToggle but not HeaderValueToggle. Some toogles like Location can be improved using the Header value added by some cloud providers, gateways.
We need to design measure / tracking feature toggle execution API in order to get statistics about feature / toggle activations.
This API need to be async
With the feature / toggle information user/app can also send a payload. On ASP.NET Core Request information will be this extra payload.
On ASP.NET Core Request dataq can be the extra payload.
UI will add new dashboards to show overall information.
We need to improve our documentation and overview slides to include missing topics.
Please add the docs site link to the repository description
So isntead of
Esquio is a Feature Toggle Library for .NET Developers.
It would be
Esquio is a Feature Toggle Library for .NET Developers https://esquio.readthedocs.io
I have found two abnormal behaviors related to products page.
There is some kind of validation inconsistency with the "New product" modal window. "Save changes" button is being enabled even when validations are invalid. It occurs when I leave name or description fileds untouched.
I can edit product's description and leave it empty, saving correctly.
Here is an animated gif that shows it:
I tried to take a look at the code, but I practically don't know blazor :(
I think ClaimValueToggle only evaluates only first apperance of the claim of the same type.
For example I have claims collection on http context containing claim of type Role with value "Role1" an claim of type Role with value "Role2", I guess it searches only for the firstone, but I have an user assigned to multiple roles so I have multiple claims of type Role assigned in http context
At this momment Esquio UI use settings controller to get information about configured Authority and Audience parameter values used on authorization flow but ClientId is a magic string :-(
At this moment, Esquio client endpoint, only Support request state of single feature. Will be interesting to add more features like:
We discuss on allow mark some features as client features in order to help the client endpoint.
New Blazor Client Wasm hosted on ASP.NET Core is a perfect model to use Esquio Client Endpoint, we can include a new library to allow use this ClientEndpoint:
Add new IServiceCollection extensions to enable services depending on feature state, is like a factory but with some sugar to simplify developers code
Due to the amount of new features for Esquio 3 and the GA of Blazor Wasm on 2020 Q2 we decide to create a new and awesome. We try to
At this moment, the UI does not save the assembly name as part of type information, when the feature service is executed, if not assembly name is specified, solve types does not work well.
The file build.sh is not in the repo
Esquio needs to keep a list of changes of all features in order to have a change log page.
Cleanup csproj, basically:
Our Feature tag helper define 3 different properties Names, Include and Exclude. There is no difference between Names and Include, probably wiht Include and Exclude is enought.
On the scenarios where all your feature toggle are by username enable to the 50%, always the same users has them enable. Add the possibility to use the username + the feature name to randomize the users per feature.
At this moment, Esquio ErrorBehavior and NotFoundBehavior is not on our docs. Add description for this enumerations and also a sample of use.
Consider adding new behavior for NotFound feature scenario with Throw. This could make sense on development to ensure configuration data.
At this moment we have Enabled property on Feature definition. With this property we can do the same scenarios that On and Off toggle solve.
Consider adding a new configuration store based on Redis Cache
Create and improve Github actions for Esquio 3 including new features like Archive features! Added convenient docs for new/modified actions
Upgrade blazor references (Esquio UI and Esquio.Blazor.Wasm ) to RC1 version
Trying to get empty DB tables created with Esquio.EntityFrameworkCore.Store
I'm unable to do it, It seems to be created when I use that Esquio.UI, but I might dont want to use it
Is it possible to automaticaly create DB if it does not exist, therefore I can use sql script or use EF migrations to insert data there
services.AddEsquio(setup =>
{
setup.RegisterTogglesFromAssemblyContaining<ClaimValueToggle>();
}
)
.AddAspNetCoreDefaultServices()
.AddEntityFrameworkCoreStore(options =>
{
options.DefaultSchema = "RCM";
options.ConfigureDbContext = o => { o.UseSqlServer(Configuration["ConnectionStrings:MSSQLConnection"]); };
});```
I was trying to get started with Esquio, however, when following the Getting Started guide for ASP.NET Core, I got compilation errors on the .AddConfigurationStore()
bit.
Turns out you also need to pull in the Esquio.Configuration.Store
package, which defines this extension method. Is there a dependency missing on the "meta package", or should the docs be expanded with this detail?
At this moment, EndpointFallback behavior is configured for all endpoints, but is some scenarios may be necessary configure different fallback behaviors ( not found, redirect to, etc ) for each configured endpoint.
After feedback session we extract more information about this issue:
Product parameter is configured on AddEsquio and for us there is no sense to use different product names on the sample application. The proposal is removed all productName parameter options on different services and use default configured value on EsquioOptions.
It should release demo app from repository and publish it in private azure registry.
EsquioUI docker image will take latest tag from DockerHub
KownTypes toggles on UI only work with Esquio assembly, we need to include custom assemblies to scan and work on the UI.
Well,
We receive a lot of feedback about why not the HTTP API use slug for all items ( products, features etc ). At this moment, the HTTP API is based on resource id's and this experience is not the best for some scenarios like Azure DevOps Task, Esquio CLI etc..
For Esquio 2 we need to consider using slug on our HTTP API.
A lot of current Esquio.Contrib toggles can work on different scenarios and not depends on external services. Probably we can include this toggles directly on AspNetCore out-of-box !
Add a new store, and probably remove db store, that allow get feature/toggle information using http request to Esquio UI. This allow clientes to get with features but without access to configuration database, and reduce some security concerns related with direct access to configuration db and also multi-tenants apps.
Some interesting features of this store will be:
Hi @lfraile
AzureDevOps extensions overview is not included on our docs directory, used by ReadTheDocs!, can you consider moving the overview.md into doc folder or create a new walkthrought on this topic?
Thanks
At this moment, EsquioMiddleware use Newtonsoft for Json serialization, we can remove this unnecesary dependency.
At this moment, the EsquioMiddleware is not honoring the ErrorBehavior configuration that we can do when configure Esquio on Asp.Net Core apps.
After feature flag is tested or released to some ring, users etc this will be enabled or disabled for all rings, users etc. At this moment we have Rollout and Rolloff options to set a feature enabled or disabled for all conditions, but this continue to be showed on the UI.
Adding archive flag to Feature enable us to decide if the feature is managed by the UI or is intented to be archived and removed also from user code.
Review docker EsquioUI container build and release
Are there any docs yet on how to run the Esquio UI in Docker? I can start it just fine, but I'm not able to login, probably because there's no database configured. Not sure how to configure that though, or even what my options are storing the database?
At this moment, our configuration store based on EntityFrameworkCore introduce a hard dependency on StoreContext. If some user need extend this context to introduce new entities, properties etc need inherit from StoreContext. Extensibility with inheritance is not a good idea.
ASP.NET Core Identity solve this problem well and probably we can do the same technique!!
Is there a specific reason that you only started targetting from netstandard 2.1 effectivly limiting this to .net core 3.x? Most of your dependecies support netstandard 2.0 which keeps them open for a broader spectrum of consumers (even in the full .net framework via 4.8). I understand that you would like the UI and api to be run as .net core 3.x apps, but maybe a client could allow for a more relaxed netstandard 2.0 version? Or am I missing something?
At this momment our partitioner is not plugable and can't be replaced if the behavior don't fit for some customer.
Making the partitioner plugable is not hard and will be a good extension point for Esquio
At this moment, CORS is not enabled on Esquio UI, we need enable it and expose a simple way to configure it directly or from environment variables for docker deployments
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.