Carder is an audience engagement platform for events and conferences which supports multi-tenancy and is designed with a cloud-first architecture.

I built Carder as part of a university project. The assignment had two parts: to come up with an idea for a digital business, and analyse its viability; and to develop (part of) the digital product or platform. My primary focus was on developing the licensing and billing system, and underlying services such as events and attendee management, the multi-tenant architecture of the platform, authentication, and integrations with a payments processor.

Below, I talk about:

Events in the MICE sector (Meetings, Incentives, Conferences, and Exhibitions) have many areas in which technology can be used to improve the attendee experience. When carrying out my business analysis, a few issues became apparent. Attendees often had connectivity problems inside venues; and while many of them use social media to engage with events (e.g. LinkedIn), they found it to be an impersonal/inauthentic way of networking.

For event organisers, the biggest challenges were getting access to quality data and reducing paper waste (e.g. from brochures and event materials).

Once the business proposition was validated, I began to prototype various parts of the platform. These prototypes were created in Figma, which allowed me to quickly iterate and to get a better idea of how the data should be structured behind the scenes. Thinking about user journeys and their needs revealed the need for some adjustments to the database schema: for instance, I had to think about the best way to implement polymorphic relationships between various entities.

The component developed for the assignment was Carder's licensing system. This comprised of a back-end API (written in TypeScript, using the Hono.js framework, deployed on Deno Deploy) and a React.js front-end (Single Page Application). The database used for the project was Postgres (deployed on Neon).

There were two aspects of development that were challenging:

• ensuring the system is secure against CSRF attacks
• representing complex relationships (due to polymorphism in the business logic)

CSRF Prevention

Since some operations in the system could trigger high-stakes actions (e.g. initiating a payment), it was important to ensure that these operations could be linked to user intent. Cross-Site Request Forgery is an attack vector where a malicious 3rd party tricks a user into a performing an action (e.g. by making them make an unintended authetnicated request to an endpoint).

To defend against this, I implemented "intent continuity tokens" (i.e. the "synchroniser token pattern"). These were dispensed when a user navigates to an interface for a high-stakes action and attached to the request to the respective endpoint.

Representing polymorphic relationships

In Carder, there are cases where a table may have a relationship to a record that could belong to different tables. An example of this is the permissions management system. One access policy may apply to an event in the events table; another access policy may apply to a document in the documents table. This is called polymorphism.

Representing polymorphism in a relational datbase is challenging. If we want to retain relational integrity protections by the database (by using foreign keys), we will end up with a "wide table." Each row would have a lot of empty fields for foreign keys to every type of entity that it can be associated with. This is a very rigid approach. Instead, we can use only two fields— a discriminator, which indicates which table the target record is in; and the ID of the record being referenced.

This approach generally trades off referential integrity, as most databases (e.g. MySQL, Postgres) do not support foreign keys that point to more than one table. Because of this, we have to ensure referential integrity in the application code, and/or via mechanisms like triggers and check constraints.

Not having referential integrity can create problems. Consider, for instance, a security policy that is assigned to some resource in the database. If that resource is deleted, the policy should be deleted too. If you fail to delete the policy, and another resource is created with the same ID, it will still have the policy attached to it.

Therefore, we need to ensure that IDs are globally unique and monotonically increasing. UUID7 can be suitable for this, but in the case of Carder, I decided to go with ULIDs (Universally Unique Lexixographically-sortable ID). ULIDs not only meet the criteria above, but they have some features which make them particularly useful— they contain no special characters (i.e. they're URL-safe), and they utilise Crockford's base32 alphabet, which reduces ambiguity when being read by a human.

UI Showcase

Carder's UI was developed using React.js, with Tanstack Router for routing and state management, TailwindCSS for styling, and a mix of React Motion and CSS view-transitions for motion design.

Thanks to the use of Zod validators on the backend (generated dynamically based on the database schema), in future, it will be possible to achieve end-to-end type safety by sharing types between the front-end and back-end.