Currently some parts are reliant on Upstash (mainly the ratelimiting). To be truly self-hostable we should get rid of this.

This would include the following

• Remove the @upstash/redis dependency

and either

• Remove the @upstash/ratelimit dependency
• Add a new rate limiting library

or

• Make the @upstash/ratelimit dependency work without the upstash redis client

Problem:
Currently we show buttons to create an environment/flag/test for the respective empty state. While this is helpful in general, it will leave the user guessing how Abby works in general.

Thoughts:
We could potentially give a link to the docs or show some useful cli commands for the respective framework. This would indicate how code-focused Abby is as well as quick overview of all existing solutions.
This could be

To get started select your framework (+ package manager)

pnpm install @tryabby/next
pnpx @tryabby/cli login
pnpx @tryabby/cli init

Description:
Abby should have an integration for Express. This Integration should behave pretty closely to the existing Integrations and have feature parity.

Acceptance Criteria:

• Must be inside of packages/express
• Must be named @tryabby/express
• Needs to consume @tryabby/core internally
• Must be written in Typescript and have the same type quality as React etc.
• needs to have the following functionality
  • expose a middleware function which has some internal cache for the Abby API call
  • a function which returns the user's currently selected variant as well as the onAct method
  • a function which returns the value of the given feature flag
  • a function which returns the value of the given feature flag
• there should be tests for the types and the code

If i got it right with tryabby/next 5.1.0 useFeatureFlags was introduced. But is there an equivalent to use outside of a react context. Like getFeatureFlagValue is one for useFeatureFlag?

The package only contains README.md and package.json

Image source: https://www.npmjs.com/package/@tryabby/svelte?activeTab=code

Steps to reproduce:

1. pnpm i @tryabby/svelte

2. ❯ ls -la node_modules/@tryabby/svelte
   .rw-r--r-- 1.8k felix 28 Oct 21:12 package.json
   .rw-r--r-- 5.8k felix 28 Oct 21:12 README.md

Steps to reproduce:

• navigate to /flags or /configs in an Abby project
• if you don't have a flag/config created already, create one
• on that flag/config click the "..." menu on the left and choose e.g. "Edit Name"
• let the popup appear and close it again
• try to click anything on the page

Expected behaviour:
Every just works as before.

Current behaviour:
Nothing is clickable

Hint: I would think that the backdrop of the popup has not been removed correctly and prevents the clicks from going through.

Devtools funktionieren derzeit nicht mit Angular Universal.

Error:
ReferenceError: document is not defined

We could use an OLAP DB such as Clickhouse / Timescale.

With A/B testing at scale, we will have a lot of requests and querying those using a regular DB (currently MySQL). This will add a lot of stress to the regular DB. Also it will be slower since it's not optimised for this

The current charts (Project -> A/B Tests -> Advanced Stats) don't look nice. They should be recreated using https://www.tremor.so/ with their components

Derzeit muss nach einem ändern eines Cookies durch das Devtool die Seite immer neugeladen werden.
In den anderen Integrationen und Examples klappt dies ohne refreshen.

Currently Abby is using Prettier & Eslint. Biome seems to have better DX and is faster so I think it would be cool to migrate!

Problem:
When a User signs up we lose the UTM parameters they used when signing up.

Solution:
The UTM parameters are stored in the users table when a user signs up

Description:

There should be an example App highlighting the Features of Abby for Sveltekit. This should look similar to the Next.js Example.

Acceptance Criteria:

• Create the example in apps/sveltekit-example
• Highlight all Abby Features (useAbby, useFeatureFlag, useRemoteConfig)
• Re-Use the Project from the Next.js Example

The new Prisma version allows the usage of the planetscale serverless diver. We should use this for non-dev environments.

Further reading: https://github.com/prisma/prisma/releases/tag/5.4.0

Description:
Abby should have an integration for Vue (preferrably also Nuxt). This Integration should behave pretty closely to the existing Integrations and have feature parity (see React Docs)

Acceptance Criteria:

• Must be inside of packages/vue
• Must be named @tryabby/vue
• Needs to consume @tryabby/core internally
• Must be written in Typescript and have the same type quality as React etc
• needs to have the following functionality
  • useAbby -> a function which returns the user's currently selected variant as well as the onAct method
  • useFeatureFlag -> a function which returns the value of the given feature flag
  • useRemoteConfig -> a function which returns the value of the given feature flag
• there should be tests for the types and the code

Description:
Abby should have an integration for Remix. This Integration should behave pretty closely to the existing Integrations and have feature parity. The next integration should be an easy starting point here

Acceptance Criteria:

• Must be inside of packages/remix
• Must be named @tryabby/remix
• Needs to consume @tryabby/core and @tryabby/react internally
• Must be written in Typescript and have the same type quality as React etc
• needs to have the following functionality
  • useAbby -> a function which returns the user's currently selected variant as well as the onAct method
  • useFeatureFlag -> a function which returns the value of the given feature flag
  • useRemoteConfig -> a function which returns the value of the given feature flag
• there should be tests for the types and the code

When you have to many feature flags / remote configs / ab tests the Abby Devtools might exceed you screen height and you can't scroll back up. This results in you not being able to close the Devtools as you can't reach the top with the "X" button.

Steps to reproduce:

• add multiple feature flags or configs
• open the devtools and have the screen height exceeded

Expected behaviour:
You can scroll up and down in the devtools to you everything especially the close button at the top

Current behaviour:
No scroll possible. You can't close the devtools again.

Problem
The current initcommand is quite basic and doesn't provide much value. It requires a lot of manual work and doesn't align with Abby's level of UX/DX

Solution:
The init command should provide a full hands-on experience. The shadcn CLI is a great example of that (reference).

Potential Workflow:

1. User runs Abby init
2. Ask for the location (should default to the current dir)
3. If there is an abby.config.ts warn the user and abort.
4. Get a list of all projects available for the signed-in user
5. Show the user a list of all projects (select)
6. Let the user select a project
7. Fetch all existing items for the current project (environments, flags, remote configs, tests)
8. Show the user an overview of the config that will be written to the file
9. Allow the user to accept or cancel

Acceptance Criteria:

• User errors are caught and displayed in a nice manner
• the currentEnvironment field should be set to process.env.NODE_ENV by default
• all existing data must be set for the projects

An den Typings in der Angular Integration kann viel verbessert werden:

• Typings in den Directives
• Typings von Flags
• Typings von Tests ohne den Typ aus der config auslesen zu müssen.

Noticed a little bug today:
When updating a feature flag value in the abby dashboard, it is not visible until the page is reloaded.

Steps to reproduce:

1. Open a feature flag configuration on abby
2. Change the value of the feature flag
3. Press the "Update flag" button

Expected behaviour:

The new value is visible on the dashboard

Current behaviour:

The dashboard stays the same way as before until the page is manually reloaded

The Manage Button in the Project Settings has a different style than the other buttons. This should not be the case

Problem:

This CLI isn't really potent right now and adding feature flags is still cumbersome. Some new commands to help with that would be nice.

Acceptance Criteria:
The CLI has the following new commands

Add

• abby add flag
• abby add config

Should prompt the user for a name for the config / flag. Checks the local abby.config.ts file if the name is already taken.
If the value was config the user will get also prompted for the type of the config which is a select with the existing options.

When everything was successful, the flag / config should be added to the local config and then there should be an API call to the Abby Api which creates the Flag on the server.

The current editor is really basic and doesn't really look nice. Also it doesn't have any buttons for formatting

Abby should have an integration for NestJS. This Integration should behave pretty closely to the existing Integrations and have feature parity.

Acceptance Criteria:

Must be inside of packages/express
Must be named @tryabby/express
Needs to consume @tryabby/core internally
Must be written in Typescript and have the same type quality as React etc.
needs to have the following functionality
expose a middleware function which has some internal cache for the Abby API call
a function which returns the user's currently selected variant as well as the onAct method
a function which returns the value of the given feature flag
a function which returns the value of the given feature flag
there should be tests for the types and the code

Issue
In the new project selector it is pretty hard to tell apart the teams from each other

Solution
Allow teams to upload an image which will then be displayed in the selector

The disabled state for the Update Remote Config Modal looks odd. There should be more visual clarity that the fields are disabled and a better indicator for the current value

Since Abby now has an official Docker Image we should automatically build & push the image to some registry on merge to main.
Also, there should be an article on self-hosting in our documentation.

This should include:

• Selfhosting without a registry (local build)
• Selfhosting with a registry
• Selfhosting with Docker Compose (including DB & Redis)

Problem:
Right now the onboarding process is cumbersome and can easily be skipped.

Acceptance Criteria:

• The Selects for the experience in Feature Flags / A/B testing should be a horizontal radio group (use https://ui.shadcn.com/docs/components/radio-group)
• The continue button should be disabled until the user has made a decision on all steps

Description

In the Abby UI, there is a consistent issue where, after creating a feature flag and then updating its description, all buttons within the UI become unclickable. This behavior prevents any further interaction with the UI until the page is refreshed.

Steps to Reproduce

1. Navigate to the Abby UI in the local development environment.
2. Create a new feature flag using the standard creation process.
3. Update the description of the newly created feature flag.
4. After the description update, attempt to click any button within the UI (e.g., save, cancel, delete).

Expected Behavior

After updating the description of a feature flag, all UI buttons should remain clickable and functional, allowing the user to continue interacting with the UI without any hindrance.

Actual Behavior

Once the description of a feature flag is updated, all buttons within the UI become unclickable. This issue persists until the page is refreshed manually.

Environment

• Browser: Chrome Version 122.0.6261.129 (Official Build) (arm64)
• Operating System: Apple M2 Pro 13.3.1
• Local development environment setup using the README installation guide.

Additional Information

• No console errors are observed when the buttons become unclickable.
• The issue is reproducible consistently following the steps mentioned.

Suggested Next Steps

• Investigate the event handlers associated with the description update process.
• Check for any JavaScript errors or state management issues that might be causing the UI to become unresponsive.

This issue template provides a structured way to report the problem you're experiencing, focusing on clear reproduction steps, expected vs. actual behavior, and detailed environment information. Adjust the "Operating System" and add any additional details specific to your project's context.

Currently we still display the Code Generation Button in the Project Dashboard.
It is recommended though to use the CLI instead. It would be cool if instead of showing the code we could display the instructions for the CLI