soketi/soketi 0.29.0

on GitHub

1. Limits on an app-by-app basis

Starting with this version, you can set maximum presence channel members' size, maximum presence channel members count, and other limits at the app-level, with fallback to the server-declared defaults.

MySQL

You need to add the following fields to your table:

`max_presence_members_per_channel` tinyint(1) NULL,
`max_presence_member_size_in_kb` tinyint(1) NULL,
`max_channel_name_length` tinyint(1) NULL,
`max_event_channels_at_once` tinyint(1) NULL,
`max_event_name_length` tinyint(1) NULL,
`max_event_payload_in_kb` tinyint(1) NULL,
`max_event_batch_size` tinyint(1) NULL

Setting any of them to null or '' will ignore the setting, and use the limits associated with the server-level declared defaults

Existing apps running on <0.29.0 will still work even if you don't have these fields added after the migration to 0.29.0. You should add these fields to keep your database up-to-date or to have the choice to, later on, imply limits to your apps.

PostgreSQL

You need to add the following fields to your table:

max_presence_members_per_channel integer DEFAULT NULL,
max_presence_member_size_in_kb integer DEFAULT NULL,
max_channel_name_length integer DEFAULT NULL,
max_event_channels_at_once integer DEFAULT NULL,
max_event_name_length integer DEFAULT NULL,
max_event_payload_in_kb integer DEFAULT NULL,
max_event_batch_size integer DEFAULT NULL

Setting any of them to null or '' will ignore the setting, and use the limits associated with the server-level declared defaults

Existing apps running on <0.29.0 will still work even if you don't have these fields added after the migration to 0.29.0. You should add these fields to keep your database up-to-date or to have the choice to, later on, imply limits to your apps.

DynamoDB

Your items in DynamoDB can have the following new fields:

MaxPresenceMembersPerChannel: { N: '-1' },
MaxPresenceMemberSizeInKb: { N: '-1' },
MaxChannelNameLength: { N: '-1' },
MaxEventChannelsAtOnce: { N: '-1' },
MaxEventNameLength: { N: '-1' },
MaxEventPayloadInKb: { N: '-1' },
MaxEventBatchSize: { N: '-1' },

Not setting any of the above fields will ignore the setting, and will fallback to the limits associated with the server-level declared defaults.

Existing apps running on <0.29.0 will still work even if you don't have these fields added after the migration to 0.29.0. You should add these fields to keep your database up-to-date or to have the choice to, later on, imply limits to your apps.

2. Added MODE variable for the running mode

The app itself is full-stack, meaning it works as an HTTP API, WebSocket Server, and Queue processor, all at once. The MODE variable is now introduced to help you scale apps that use external drivers (like Redis for queue). You may want to have two fleets: one that actively interacts with the userbase HTTP/WS, and one fleet that scales independently to process queues for webhooks.

MODE=full

The default mode, and is the mode in which the apps <0.29.0 currently run. (no breaking changes expected for this feature)

MODE=server

It does not process queues. It will only serve HTTP/WS requests to your clients.

MODE=worker

You need to pair this specific mode setting with PORT to choose a different port to run on. The servers running in this mode will have an HTTP server running so that you can check for /metrics, / (health checks), and /ready (readiness checks). There are NO WebSocket endpoints running.