The short answer: put an API in between
A mobile application should access data through an HTTPS API. SQL passwords stay on the backend. The client sends session information, and the API decides which records are accessible. This creates an explicit boundary between devices, business rules and data.
Passwords in an app are not secret
Mobile packages can be inspected. Hiding the user interface is insufficient when a permanent SQL password or service key is packaged inside. Keep these credentials on the server. Clients need an application-specific API response, not a general SQL connection.
Separate identity from permission
A valid token does not grant access to every order. After validating the session, the API checks organization, role and record ownership. A user_id supplied by a device should not replace the authenticated session identity.
Design responses for the mobile experience
Paginate lists and omit fields a screen does not use. Loading, empty, connection failure and permission failure are different states. An error should explain the next useful action without exposing internal connections or queries.
An example request flow
The following is an illustrative API contract for a customer app, not a working Uygulama Cloud control API endpoint. The backend verifies the session, queries only this user’s orders and returns necessary fields.
GET https://api.example.invalid/v1/orders?cursor=<next-page>
Authorization: Bearer <session-token>
Accept: application/jsonPlan retries on mobile networks
After a failed request, a user may press the same button again. Consider idempotency keys and server-side deduplication for writes such as orders or payment initiation. Bound read retries; endless attempts and duplicate actions harm the experience.
Files and background work
The API should authorize uploads; permanent storage credentials stay off devices. File conversions and reports can move to workers. This is an example architecture: live storage and customer workers are not available on Uygulama Cloud yet.
Three questions before you begin
Are there permanent secrets in the client package? Does the API check ownership for every record? Can a retry create the same action twice? Clear answers establish a data boundary before framework selection.