REST APIs for web and mobile apps
An API defines the data and operations the backend exposes. We design mobile app ↔ API communication with data validation, authorisation and error handling.
In ZEiT, the Laravel backend supports the store, admin panel and Flutter API. This makes the mobile app part of the sales system, with data stored in PostgreSQL.
Business integrations and background tasks
We connect apps to external systems through APIs. The business process determines integration scope: which data is exchanged and when operations should run.
PostgreSQL provides persistent storage. We use Redis for caching or queues when work needs to run in the background. Redis queues are part of Spontan's backend.
Real-time communication
Not every feature should wait for a data refresh. In Spontan, Laravel Reverb supports real-time chat, connecting the backend to the Flutter app.
We use WebSockets for features needing live communication. Other operations can use REST APIs — the communication method follows the screen and process requirements.
When does an app need its own backend?
A backend is needed when data must be shared across devices, users, or web and mobile apps. Servers enforce roles and permissions, process integrations and run background operations. Real-time communication can complement this if the product requires it.
Not every app needs a custom backend. A tool operating only on a device may not need one, and an existing service may cover some requirements. Base the decision on the data model, access rules and integrations.
Developing and taking over an existing API
Before changes, we check API contracts and the app versions using them. The review covers authorisation, the database, queues, logs, monitoring and deployment. Changing a field or an error's meaning can affect an older app that users have not updated yet.
We agree on compatibility tests, deployment order and rollback. We introduce behaviour gradually, monitoring errors and response times, rather than assuming all API clients upgrade together.
