Backend & API

Why an API changes things

While a company has only a website, the question never arises. It appears with the second tool: a mobile app, a back-office, a shop, an ERP. Each needs the same data — customers, products, orders.

Without an API, every tool keeps its own copy, and copies diverge. The stock shown on the site is no longer the warehouse stock; the customer updated in the CRM stays unchanged in invoicing. An API provides one source that all of them read.

REST or GraphQL

REST covers most needs: simple, universally understood, easy to cache. It is our default choice.

GraphQL wins when very different clients query the same data with varying needs — a mobile app wanting three fields where the site displays thirty. It avoids multiplying endpoints.

The choice follows usage, not fashion. A well-designed REST API beats a GraphQL adopted because it looked modern.

What matters before performance

Authentication and permissions. Who can read what, change what. This is the first thing to design, not the last to add — grafting it on afterwards always leaves holes.

Input validation. Any incoming data is suspect until checked, including from your own application.

Documentation. An undocumented API forces people to read the code to understand it. We deliver documentation generated from the code itself.

Logs. Without traces, a production incident stays a guessing game.

Connecting to what already exists

Many projects do not start from scratch: they have to talk to an ERP, a payment gateway, a shipping service, a CRM.

Odoo exposes its own API, which lets a website or mobile app read real stock and create orders without duplicating data. That is what we do when we build both sides — see our [Odoo service](/en/services/odoo).