Next Generation of Edgee Components

[SachaMorard]

Each component WIT interface defines a set of core functions that components must implement, along with their expected types and behaviors. The interfaces are designed to be composable, allowing components to work together seamlessly while maintaining clear boundaries of responsibility.

You'll find bellow ideas of new components interfaces. I wrote them with typescript semantic for a better understanding.

Interface Specifications

1. Data Collection Components (already exists)

Handles various types of data collection and analytics integration.

Subcategories:

• Analytics
• Data Warehouse Integration
• Conversion API
• etc…

Core Interface:

export interface DataCollection {
    export Page(event: Event, settings: Settings): Result<EdgeeRequest, string>
    export Track(event: Event, settings: Settings): Result<EdgeeRequest, string>
    export User(event: Event, settings: Settings): Result<EdgeeRequest, string>
}

2. Request Handler Components

Manages HTTP requests, cookies, and security concerns.

Subcategories:

• Native Cookie Management
• Security Controls
• Function Execution

Core Interface:

export interface RequestHandler {
    import GetCookie(name: string): Option<string>
    import SetCookie(name: string, value: string): boolean
    import Fetch(request: Request): Promise<Result>
    export Handle(request: Request): Result<Response, string>
}

3. Consent Management Components (CMP)

Handles user consent and privacy preferences.

Subcategories:

• CMP Integration
• Consent Mapping

Core Interface:

export interface Consent {
    import GetCookie(name: string): Option<string>
    import SetCookie(name: string, value: string): boolean
    import Stitch(selector: string, content: string): boolean
    export MapConsent(settings: Settings): Option<Consent>
    export Handle(settings: Settings): Option<Consent>
}

4. Content Stitching Components

Manages content modification and optimization.

Subcategories:

• Web Performance Optimization
• SEO Enhancement
• A/B Testing
• Dynamic Content Injection

Core Interface:

export interface Stitching {
    import GetCookie(name: string): Option<string>
    import GetPath(): string
    import Stitch(selector: string, settings: Settings): boolean
    export Handle(request_body: string, settings: Settings): boolean
}

Future Considerations

1. A/B Testing Extensions:
   • KV store (or memory) integration for test data
   • Traffic allocation functions
   • Variant assignment and persistence
2. Performance Monitoring:
   • Real-time performance metrics
   • Custom performance markers
   • Integration with Web Vitals
3. Security Enhancements:
   • CSP management
   • Request validation
   • Rate limiting

Note: All interfaces use Result and Option types for better error handling and null safety. The actual implementation should include detailed type definitions and error cases.

[SachaMorard]

@CLEMENTINATOR @alexcasalboni @NicolasGirardot @Jer1605 @KokaKiwi food for thought! Don't hesitate to give your opinion.

[alexcasalboni]

Looks great @SachaMorard 👌

Because these are WIT interface, I would avoid the "protocol" concept in generate (since we also renamed all the edgee::protocol stuff into edgee::components). Let's just talk about interfaces/types that need to be implemented/exported. I would call those interfaces something like DataCollectionComponent, ConsentComponent, StitchingComponent, etc.

A few more detailed comments:

1. DataCollection sub-categories: does the sub-category have any impact on the interface? so far it looks like there's no difference, so it's only a matter of where the data is going. Do you think there should be any difference in the way the page|track|user requests are handled for non-analytics sub-categories?
2. Request Handlers: I wonder if this interface should be more restrictive in terms of the Response return value? maybe they should only get write-access to response headers? I would look into each use case and clarify what is required to achieve it.
3. CMP interface: what is the intended input/output of the inject function? it doesn't seem immediately clear - what's being injected and where? maybe the function name should be more explicit?
4. Content stitching interface:
   • I'd consider renaming body_transform into just transform, for coherence with all the other functions (then the body input parameter kind of clarifies what's being transformed already).
   • I would also clarify whether the input body includes all the HTML response or only the <body> tag (in other words, is it the HTTP message body or the HTML body?). I assume you mean the HTTP message body, so it also includes <html>, <head>, and everything else.
   • I agree that use cases such as A/B testing and dynamic content inject would require access to some kind of KV-store to keep track of experiments or store some (user-related) raw data such as recommended items, etc. The same could be super useful for the Request Handlers to implement security logics such as rate limiting.

[CLEMENTINATOR]

@clement @alex @nicolas @Julianne @jer food for thought! Don't hesitate to give your opinion.

watch out you've notified people that have nothing to do with the company !

[SachaMorard]

@clement @alex @nicolas @Julianne @jer food for thought! Don't hesitate to give your opinion.

watch out you've notified people that have nothing to do with the company !

Oh yeah, sorry... fixed

[CLEMENTINATOR]

This looks great @SachaMorard , we're just lacking a little bit of documentation on the provided apis so we can be sure we're all thinking about the same functionnalities !

[SachaMorard]

Thanks @alexcasalboni! You're right, I changed all the protocol concepts by Component or Interface for a better understanding.

Here are answers and comments:

1. DataCollection sub-categories: does the sub-category have any impact on the interface? so far it looks like there's no difference, so it's only a matter of where the data is going. Do you think there should be any difference in the way the page|track|user requests are handled for non-analytics sub-categories?

There is no difference for now between DataCollection subcategories. But who knows ;)

2. Request Handlers: I wonder if this interface should be more restrictive in terms of the Response return value? maybe they should only get write-access to response headers? I would look into each use case and clarify what is required to achieve it.

I agree, I think about having a Response return value that is strictly defined by a wit interface, like we already did with EdgeeRequest for Data Collection components.

3. CMP interface: what is the intended input/output of the inject function? it doesn't seem immediately clear - what's being injected and where? maybe the function name should be more explicit?

I changed some things:

export interface Consent {
    import GetCookie(name: string): Option<string> // for the component to get cookie
    import SetCookie(name: string, value: string): boolean // for the component to set cookie
    import Stitch(selector: string, content: string): boolean // for the component to stitch content in the page
    export MapConsent(settings: Settings): Option<Consent> // for Edgee to use this function to map CMP consent with Edgee consent
    export Handle(settings: Settings): Option<Consent> // for Edgee to launch this component function after receiving the response from the backend. This function will operate the full CMP logic
}

4. Content stitching interface: - I'd consider renaming body_transform into just transform, for coherence with all the other functions (then the body input parameter kind of clarifies what's being transformed already).

Same, I changed things following your comments:

export interface Stitching {
    import GetCookie(name: string): Option<string> // for the component to get cookie
    import GetPath(): string // for the component to get the request path
    import Stitch(selector: string, settings: Settings): boolean // for the component to add a content in the page
    export Handle(request_body: string, settings: Settings): boolean // for Edgee to launch this component function after receiving the response from the backend. This function will operate the full Stitching logic
}

Of course, these are only ideas at this stage, and I'm pretty sure the final result will be way more different :)