Integration Platform (Future Ecosystem expansion)

[xd-Park3rr]

Hi Thomas, the question is related to the future of the SaaS ecosystem as a whole and i would love your honest feedback:

The idea is a standalone, open-source Apache Camel-based eIPaaS template — something any organization can deploy independently and use as the foundation for their own custom integration platform. It would be completely decoupled from PlatformPlatform to start, so any team can adopt it regardless of stack.

Out of the box it would cover the core integration concerns:

• OAuth 2.0 auth management (Authorization Code, Client Credentials, token refresh/rotation)
• A connector framework with a consistent contract that teams can extend with their own integrations
• Webhook ingress, HMAC verification, and payload routing
• Data transformation (JSONata/JOLT)
• Route orchestration with retry policies and dead letter queues

The stack would be Apache Camel + Quarkus, containerized and deployed as a sidecar service. Camel exposes a management REST API using its native REST DSL with a full OpenAPI specification, so any service — whether .NET, TypeScript, or anything else — can call it through standard HTTP. This means it slots naturally into PlatformPlatform's existing Vertical Slice Architecture and Azure Container Apps deployment model without requiring any changes to how PlatformPlatform is structured today.

The longer-term vision, and where this gets interesting for PlatformPlatform specifically, is a first-class integration management feature — where the platform UI lets you configure connections, manage credentials, and control routes directly through the admin interface. The eIPaaS template would be the engine underneath, and PlatformPlatform becomes the control plane sitting on top of it. This would follow the same DDD and CQRS principles PlatformPlatform already uses, with integration configuration stored as first-class domain objects.

The proposal is to start it as its own OSS project, keep it fully decoupled, but design the API contract and domain model from day one so that PlatformPlatform configuration support is a natural future extension rather than a retrofit.

Would love to know if this resonates with the direction you're taking the project, and whether there's interest in collaborating or at least aligning on the integration contract early.

[tjementum]

Thanks for reaching out and for your interest in PlatformPlatform!

I'll be honest, I'm not fully familiar with the technologies you're mentioning, so I'm not sure I fully understand the proposal or how it would fit naturally with PlatformPlatform.

PlatformPlatform is a personal project with strong opinions, where I draw on my own experience to showcase how I believe B2B SaaS cloud products should be built. For that reason, I'm not taking on collaborators, as I want the project to stay a reflection of that vision. It's not a framework with stable APIs or upgrade paths either. I intentionally keep the architecture fluid so I can evolve it freely. There's no guaranteed update mechanism, though projects built on it can use AI-assisted tooling to pull in changes.

I appreciate the interest though!

[xd-Park3rr]

Hey, totally understand and appreciate the honest response!

I'll be working on it anyway as a separate project. I know the pain of wiring up third-party integrations from scratch every single time, and that's exactly the problem I want to solve.

I've already decided to use PlatformPlatform as my ongoing foundation for every B2B SaaS product I build, which is why I'm so motivated to expand the integration domain — both for myself and for others who end up in the same situation.

The eIPaaS itself will be an entirely separate repo — a standalone Apache Camel-based project that has nothing to do with PlatformPlatform's internals. My fork of PlatformPlatform will simply have a lightweight integration layer that connects to it, so the two stay completely decoupled.

The broader goal is to create a real open-source alternative to Nango — a proper OSS starter kit that gives any company a solid foundation for their own integration platform, rather than depending on a third-party iPaaS vendor. Something that's yours to own, extend, and run yourself.

Thanks again for building PlatformPlatform — it's a genuinely great foundation to build on.