progressively-crew / progressively

All in one toolbox for feature flags & analytics Anonymous, Open Source & Self-hosted

All in one toolbox for feature flags
& analytics Anonymous, Open Source & Self-hosted

Website | Get started | Roadmap

Overview

Imagine your product is a bustling metropolis, with features as its buildings and user interactions as its roads 🏙️.

Now, to understand and enhance the flow of traffic 🚃 – your users' journeys – you're equipped with four essential tools.

Quantitative analytics act as your high-tech traffic counters, measuring the volume of cars and their speed, giving you a bird's-eye view of which roads are most traveled.

Qualitative analytics are your street interviews, revealing why certain paths are favored and how the journey feels for the travelers.

Feature flags serve as your experimental detours 🚧, allowing you to test new routes on a small scale before opening them to the public.

And event funneling is your map 🗺️, showing the most common paths taken and highlighting bottlenecks. Together, these tools empower you to make data-driven decisions, optimizing the city's layout for smoother traffic, happier commuters, and a more vibrant metropolis.

progressively's Issues

Roadmap (WIP)

In progress

Transerve

• Add batch processing with Kafka

Feature flags

Tbd

Quantitative analytics

• Find a way to effectively store the events => clickhouse
• Find a way to effectively compute the analytics insights => clickhouse
• Experiment with materialised views / tables to optimize query in clickhouse

Funnels

• [] Compute funnels through clickhouse (try using materialised views) and eventually sampling

Qualitative analytics

• []Check how to integrate heatmapjs or something similar
• [] Use a grid clustering algorithm to create a grid on the page and show the most active areas
• [] Experiment with materialised views / tables to optimize query in clickhouse

Error & exceptions

Tbd

Session Recording

Tbd

Add Svelte example

In the project, under the ./example folder, it would be great to create a showcase for a SvelteKit application + writing e2e tests on it to make sure Progressively works on the long run on this types of projects

Be more explicit when a metric creation fails

When attempting to create a metric using a name that is already used, the app throws "Unexpected error" instead of something meaningful

[SDK]: keeping fresh data even when the server uses caching mechanisms

Describe the bug

Let's say I'm running a nextjs application in which I want to add a max-age=300.

When retrieving the Nexjs data (user lands) using getServerSideProps, the application will send a request to Progressively to get the feature flags value.
On subsequent requests on the Nextjs application, during the next 300s, the browser will serve the cached HTML file with the old feature flag stored in this cache.

To Reproduce

• Set a max-age=300 on a server side application
• Make a request and get the flag variation
• Change the flag status
• Refresh the page (⚠️ without hard refresh)

The page shows the old variant.

Expected behavior

The page should show the new variant

Solution 1

In any case, after the page has finished loading from the cache, and it has finished hydrating, make a request to resolve the flags from the client (XHR).

Main drawback: the app can flicker if the flag resolved is different from the one cached

PR: #56

Solution 2

• When getting the flags from the API, make sure to attach a updatedAt field with a server-generated timestamp
• When requesting the Nextjs cached page, the updatedAt field will remain the same (since cached and available in nexttjs SSR data)
• When updating a flag using WebSockets ("real-time", no caching involved), set the flags in local storage AND also add an updatedAt field to the message.
• On subsequent requests, even the cached one, compare the updatedAt value from local storage and the Nextjs data and provide with the freshest one. Update local storage accordingly

Main drawback: if a users is not on the browser when the real time push happens, they still have the old variants available

SDK for different languages

Is your feature request related to a problem? Please describe.

As a regular user of Progressively, I want to use the tool with my PHP, Go, Java (add your own) application.

Describe the solution you'd like

Create the different SDK prioritizing:

• Node.js #91
• React Native
• PHP https://github.com/progressively-crew/sdk-php
• Go https://github.com/progressively-crew/sdk-go
• Python https://github.com/progressively-crew/sdk-python
• Java (server)
• Android
• (add your own)

Describe alternatives you've considered

N/A

Additional context

Also, finding a way to make SDKs resilient to eventual breaking would be a good idea. Note that on JS frameworks, it should be well supported.

Add SolidJs example

In the project, under the ./example folder, it would be great to create a showcase for a Solid application + writing e2e tests on it to make sure Progressively works on the long run on this types of projects

Add log or history pane to have information of what has been going on

Make sure to log the dashboard activity for:

Update logs

• Change Flag status
• Change Flag percentage (without variant)
• Change Flag percentage (with variant)
• Edit additional audience
• Edit eligibility audience

Creation logs

• Create additional audience
• Create audience eligibility
• Create webhook
• Create scheduling
• Create metric
• Create variant

Delete logs

• Delete additional audience
• Delete eligibility audience
• Delete Scheduling
• Delete metrics
• Delete Variants
• Delete webhooks

Set user infos after login

Is your feature request related to a problem? Please describe.

As a user, I want to be able to modify the fields passed to the API calls / WebSockets sub at any moment.

Describe the solution you'd like

1/ The user sends a request to / and the connection is initiated to Progressively
2/ The user authenticates themselves
3/ Since the provider is initiated without context at the beginning the fields (like email) are not passed

Find a way to modify the internal context of progressively imperatively at any moment of the app lifecycle

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Cookie is not forwarded to the server when doing SSR

Describe the bug

The cookie is not passed to the backend from an app using SSR

To Reproduce

• Go to an SSR app without fields, using anonymous users
• Refresh the page
• Check the response set-cookie and keep in mind the progressively-id
• Re-refresh the page
• Check the response set-cookie and keep in mind the progressively-id

The two progressively-id are different

Expected behavior

They should be the same

Add sentry to the backend package

All in the title

Edit flag is not working

Describe the bug

Editing a flag is broken and say the flag already exists

To Reproduce
Steps to reproduce the behavior, a reproducible example in a GitHub repository or sandbox is strongly appreciated**:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. Windows 10]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Toggling feature flags from the FlagCard does not work

Describe the bug
Toggling feature flags from the FlagCard does not work

To Reproduce
Go to an environment page, on the Feature Flags Tabs with a feature flag, try to toggle the flag

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. Windows 10]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Scheduling for multi variants flags

Add the ability to schedule a flag update with multi variants, and not only for true/false

Work done

• #405
• #412

Wrap compound SQL insertions with prisma transactions

https://www.prisma.io/docs/concepts/components/prisma-client/transactions

Current PR: #202

Possibility to duplicate flags in new envs

Find a way to make it possible to duplicate flags in envs created after the flags

A/B variations

Is your feature request related to a problem? Please describe.

As a regular user, I want to be able to get insights of different variations of a flag so that I can provide the better experience to my user.

Describe the solution you'd like

In the dashboard, add the possibility to provide multiple variations to a given flag and provide ways to target specific users with each of the varations

Describe alternatives you've considered

Adding a UI in the insights pane to compare N different flags (still relying on boolean values) in charts, like drawing lines for the different flags. While it could work, it would imply creating the N different flags (with potentially not very meaningful names) and it may create confusion since nothing is very clear. In terms of experience, this looks more as a "quick and dirty" way to do the thing

Additional context

N/A

What has been done

• #12
• #14
• #15
• #20
• #24
• #23
• #22
• #21
• #25
• #26
• #27
• #29
• #30

Add Qwik example

In the project, under the ./example folder, it would be great to create a showcase for a Qwik application + writing e2e tests on it to make sure Progressively works on the long run on this types of projects

Add Nuxtjs example

In the project, under the ./example folder, it would be great to create a showcase for a Nuxt 3 application + writing e2e tests on it to make sure Progressively works on the long run on this types of projects

Improve CI, takes too long

Deployment:

• Deploying frontend app takes 5mns (1.5Gb of docker image) it's now 600mb
• Deploying backend app takes 4mns (1.2Gb of docker image)

Tests

• Caching of playwright install stuff
• Not building everything on every job (frontend does not need to be built for the example folder)
• Investigate parallel builds for cypress and the backend, isolate long running suites vs others
• Investigate Turo remote caching (since already paying for vercel)

Make a decision tree in the doc

In Progressively, we want the users to use the tool they need in their own specific context.

In some situations, regarding the user's project's stack, we won't suggest the same SDK. The JavaScript Ecosystem is particularly touched by this with the amount of frameworks out with their own potential ways to deal with state and data.

This issue is about to create a decision tree to suggest the "best" SDK (according to our heuristics) to integrate with their projects

Consider time series or column oriented DB

For storing analytics data and metric hits.

While Postgres is great for handling relational data, it could be very practical to use a tool that deals with a huge amounts of data

Add an integration to segment

Investigate what could be forwarded to segment and create the associated integration.

• Metric hits?
• Flag evaluation?

[Refacto]: move from stitches to something more supported

And that is working with https://reactjs.org/docs/react-dom-server.html#rendertopipeablestream

Add log rotation on the backend

We are using winston on the backend package, and need to add log rotation instead of stdout only

[Exploration]: maintaining the same websocket connection between client side pages (even with SSR tools)

Describe the bug

When navigating between pages using an SSR framework, depending on how the users want to wrap their page with Progressively's provider, the WebSocket connection can be interrupted when the page unmounts and re-created when landing on the next page.

Since most modern SSR frameworks are able to handle client-side routing effectively once the application is started in the browser, it might be a good idea to keep the socket connection instead of closing / reopening it

Switching env does not clear the flag status

Describe the bug

To Reproduce
Steps to reproduce the behavior, a reproducible example in a GitHub repository or sandbox is strongly appreciated**:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. Windows 10]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

🥲

progressively/websites/marketing/src/sections/Conclusion.astro

Line 12 in 7599548

authorJob="Frontend Eng @Proton"

Fix demo backend deploy

For some reasons, when building the backend docker image on gh actions during the deploy step, @progressively/database is not found locally and breaks the build

[Exploration]: Percentage rollout with criteria

This exploration is about putting in place a percentage base rollout with criteria.

What exists today

When a user requests Progressively, we assign them a unique identifier (generated with nanoid).

Each user is guaranteed to have the same consistent ID on subsequent requests because the generated nanoid is stored in cookies.

When a user requests with a previously generated ID to access a specific feature, we create a string that corresponds to the user ID concatenated with the feature ID. Something like

const concatenationOfUserIdAndFeatureId = userId + "-" + featureId

We can convert this string into a number using the murmur hash 3 algorithm which provides a 32-bit number. We know that murmur hash is well distributed and is good at pseudo-randomness.

Now, we have a number where the maximum value is the maximum 32-bit number. We can divide that number by something we can work with, like a number between 0 and 100.

const concatenationOfUserIdAndFeatureId = userId + "-" + featureId
const hashed = mumurhash3(concatenationOfUserIdAndFeatureId);
const ratio = hashed / MAX_INT_32;
const percentage = ratio * 100;

What we can do now, from the Progressively standpoint, is to say: “hey, I want to roll out the feature X to 20% of my audience”. With the previously computed percentage for a user/feature couple, it’s now possible to make the following comparison:

// the computation above is hidden for clarity
const percentage = ratio * 100;
const rolloutPercentageForAudience = 20 // meaning 20%

if (percentage <= rolloutPercentageForAudience) {
  // rollout the feature to the user
}

What problem do we have

In Progressively, it should be possible to rollout features to a percentage of the audience with criteria. For instance, it should be possible to roll out to people with an email containing “@gmail.com” etc.

But it should also be possible to rollout features to 20% of the people with an email containing “@gmail.com”

Since we don’t store users (and we don’t have a base to compare with), is it mathematically possible, to use the same technic we use with murmur hash to make it happen?

Helm chart

Is your feature request related to a problem? Please describe.

Helm charts are a "simple" way to define how to deploy apps on a k8s cluster. Since Progressively is a self hosted solution with multiple services that need to run, having a helm chart to make them deployable in a few command is very practical.

Helm charts => https://helm.sh/

Generate TypeScript types

Is your feature request related to a problem? Please describe.

The feature flags tend to be created in the dashboard before being used in the application. It could be very practical to be able to get the flags type directly in the SDKs

Migrate to fastify

#78