Skip to main content

Backend Architecture

We highly recommend implementing a backend from the start of your project.

A dedicated backend helps to:

  • ✅ perform tailored computations from raw data.
  • ✅ maintain security, by not exposing your tokens.
  • ✅ manage your user sessions.

Direct API-to-UI communication would:

  • ❌ expose your system to security risks, especially, if your API access token is lost into the wild.
  • ❌ prevent you from scaling, due to our API limitations

Request Rate Limits​

Our API enforces rate limiting to prevent abuse. If your application exceeds the allowed rate, the server will return an HTTP 429 Too Many Requests status code. Use the Retry-After header to know when to retry your request.

By default, new applications have:

  • 5 requests/second for all HTTP endpoints
  • 3 concurrent WebSocket connections

Before production deployment, contact our API support team to adjust rate limits based on your needs.

✅ Dos:

  • ✅ Use exponential backoff to avoid hammering the API when retries are necessary.
  • ✅ Monitor request patterns to prevent unnecessary API calls.
  • ✅ Contact our support team to adjust rate limits when scaling for production.

❌ Don’ts:

  • ❌ Don't ignore the rate limit responses, it can cause your API access to be throttled.
  • ❌ Don't overwhelm the API with unnecessary calls (e.g., polling too frequently).

User Management System​

Our previous user management system for coaches and athletes has been deprecated. We now only support manager accounts through which all your devices are assigned.

If you need to manage multiple users or tenants, you should build your own user management system. By doing so, you can create a solution tailored to your specific needs, without being restricted by the limitations of our former system.

✅ Dos:

  • ✅ Develop your own custom user management solution.
  • ✅ Consider OAuth or other secure authentication methods for better security.

❌ Don’ts:

  • ❌ Don't rely on our deprecated user management system as it's no longer supported.

Data Persistence and WebSocket Usage​

We do not offer Database as a Service, you are responsible for storing and managing the data.

We maintain however a temporary buffer for data when WebSocket connections are interrupted. Currently, this buffer holds up to 1 month of data, but this will be reduced to 1 week in the future.

✅ Dos:

  • ✅ Set up your own database or data storage system to persist data.
  • ✅ Implement reconnection logic to retrieve and handle any missed data during API disconnections.

❌ Don’ts:

  • ❌ Don't rely on our buffer for data storage, build your own persistence layer.
  • ❌ Don't assume that data will always be highly available, ensure you can handle API reconnection scenarios.

Device network loss and retransmission​

Due to potential device network disruptions, data might not always arrive in the correct sequence. When the device network connection is re-established, live data is prioritized, while older data might be delivered in any order.

✅ Dos:

  • ✅ Take incoming data timestamps into account, and choose to ignore or reprocess older data.

❌ Don’ts:

  • ❌ Don't assume that data will always arrive in the correct order, you may face bad computations.