I've spent the last 10 years building software systems for businesses across Kuwait and the Gulf, and I'd estimate that 40% of the projects I review have an API design problem embedded somewhere—usually not catastrophic, but expensive to fix once you're live.
The irony is that choosing between REST and GraphQL isn't actually that hard. The real work is understanding what your actual business needs, which turns out to be the part most teams skip.
What REST is, and why most Gulf businesses should start here
REST is straightforward: you request a resource (a customer, an invoice, a payment transaction) by calling a specific URL endpoint. The server sends back JSON. You get what you asked for. It's been around since the mid-2000s, and every programming language has mature libraries for building and consuming REST APIs.
For a typical Kuwait business—a manufacturing company that needs to sync inventory with e-commerce, or a consulting firm managing client projects and billing—REST is probably the right choice. Here's why:
REST forces you to think clearly about your data structure. When you design an endpoint `/api/customers/{id}`, you're declaring "a customer is a thing with these properties." That clarity matters. I've watched teams jump straight to GraphQL specifically to avoid making these decisions, and it always comes back to haunt them six months later when they're trying to debug data consistency issues.
REST is also predictable for enterprise clients. If you're building a system for a Saudi bank or a UAE manufacturing company with multiple departments, REST endpoints are straightforward to document, cache, and secure. Your IT team knows exactly what traffic is flowing where.
The downside: if you're building multiple client applications—a web app, a mobile app, a partner portal, an internal admin tool—REST can lead to either over-fetching (you get data you didn't ask for) or under-fetching (you need to make five requests instead of one). That's where GraphQL enters the picture.
When GraphQL actually makes sense
GraphQL lets you ask for exactly the fields you need, in one request. A mobile app can ask for customer name, phone, and payment history. A web app can ask for the same data plus email, billing address, and note history. The same API endpoint handles both—the client describes what it needs, not the server.
I'd recommend GraphQL if:
- You're building a SaaS platform where different customers have vastly different feature sets and data structures. A logistics SaaS might need shipment tracking for some clients but not others. GraphQL handles that elegantly.
- You're integrating with multiple third-party services where you need to query different data shapes from different providers in a single request. I worked on a marketplace platform for a Kuwaiti client that integrated restaurant data, delivery tracking, and payment status—GraphQL let the frontend ask for exactly what it needed.
- You're managing a complex internal data graph where requests naturally span relationships. "Get this employee, their manager, their department budget, and open projects" is simpler in GraphQL than REST, where you'd chain multiple endpoints.
The catch: GraphQL adds operational complexity. Caching becomes harder. Monitoring becomes harder. Your team needs to understand query optimization or your database will get hammered by inefficient requests. I've seen startups in the Gulf choose GraphQL early, then spend months tuning their Postgres instance because they had queries that looked fine to a developer but were joining 12 tables.
My honest take: most Gulf businesses don't need GraphQL yet. You're better off shipping REST fast, proving your business model, then migrating to GraphQL when you actually have the client diversity problem. Reverse migrations are painful.
The reality of Kuwait payment gateway integration
This is where theory meets local business reality.
Kuwait has two dominant payment gateways: KNet (the national network used by all local banks) and KOOKY (a newer option). There's also PayFort by Amazon for some use cases. If you're building an e-commerce system or a subscription platform, your API needs to handle these specifically.
Here's what I've learned from actual implementations:
KNet integration requires offline fallback thinking. KNet uses a two-stage process: you redirect the customer to KNet's payment page, they pay, then KNet redirects back to you with a response. If your internet connection drops between the payment and the redirect, you don't know if the payment succeeded. Most developers miss this. You need background jobs checking payment status, database transactions that handle partial states, and clear reconciliation logic. I've watched e-commerce sites go live without this and then spend their first week dealing with duplicate charges and confused customers.
KOOKY and newer gateways use APIs directly. You send payment requests programmatically. This is cleaner architecturally but requires stronger API authentication and error handling. Also, documentation is sometimes sparse. I'd recommend budgeting 20% extra development time for payment gateway integration than you initially estimate—testing requires live transactions (or staging environments that aren't always reliable), and edge cases are real.
PCI compliance isn't optional. If you're handling card data directly, you need to meet Payment Card Industry standards. Most projects avoid this entirely—let the payment gateway handle it. This means your API never touches raw card data. Your frontend sends card details directly to KNet's API, not to your backend. Your backend only handles the authorization response.
Real mistake I've seen: Storing KNet reference IDs incorrectly
KNet returns a reference ID for every transaction. This is your only way to look up a payment later. I worked with a client whose system was generating its own transaction IDs and only loosely tracking KNet's ID. When disputes came up (and they always do), they couldn't reconcile payments. We rebuilt their payment logic to make KNet's reference ID the source of truth. It took two weeks. Store this cleanly from day one.
REST vs GraphQL: A decision framework for your project
Here's how I'd think about it:
Choose REST if: Your data structure is relatively stable, you're serving one or two client applications (web + mobile), your team is comfortable with REST patterns, or you're unsure and want to ship fast. REST is forgiving. You can always refactor later.
Choose GraphQL if: You know for certain you're building multiple dramatically different client experiences (web, mobile, partner API, internal tools), your business model requires extreme flexibility in data shapes, or you have a team that's already comfortable with GraphQL and has time to handle the operational overhead.
Choose both if: You're building a large platform and can afford the infrastructure. Use REST for stable, high-traffic operations (payments, authentication, critical data). Use GraphQL for the complex internal graph your product team builds on top. This is what large SaaS platforms do, but it's overkill for 90% of Gulf businesses.
The hidden cost of GraphQL: operational readiness
GraphQL looks elegant until you're debugging a query that's running 50 database queries at once because someone nested relationships too deeply. Before choosing GraphQL, honestly assess: can your team monitor and optimize query performance? Do you have a staff database engineer? If not, REST will serve you better. Shipping something that works is worth more than shipping something architecturally pure that your team can't maintain.
Building your API: the three things that actually matter
Authentication and authorization. Most developers think about authentication ("who are you?") but gloss over authorization ("what are you allowed to do?"). I worked on a CRM for a Saudi firm where the original API let any customer see any customer's data. The bug didn't surface until their competitors could literally see each other's contracts. Now we treat authorization as a first-class concern. Use role-based access control (RBAC) from day one.
Error handling and logging. A good API tells you exactly what went wrong. "Payment failed" is useless. "Payment failed: KNet returned error 123 (insufficient funds)" is actionable. Log every payment attempt, every gateway interaction, every authentication failure. This is boring work but it's the difference between spending 30 minutes debugging an issue and spending three hours.
Rate limiting and monitoring. If your API becomes popular (or gets hammered by a competitor's bot), you need to detect it and respond. Rate limiting isn't just about protecting your infrastructure—it's about fairness. All clients should have predictable performance. I'd implement rate limiting and monitoring before your API hits production.
The local context: building APIs for Gulf businesses specifically
Kuwait, Saudi Arabia, the UAE, and Qatar all have specific regulatory and business contexts:
- Data residency: Some clients require data to stay within the GCC or even within a specific country. Your API architecture needs to respect this. Don't assume you can put everything in a cloud provider's US region.
- Currency handling: If you're processing payments in KWD, AED, SAR, or QAR, be precise. Your API needs to handle currency conversion explicitly, not implicitly. I've seen invoices off by 2% because of hidden rounding.
- Business hours: Gulf businesses often operate on different schedules. Bank systems sometimes go down for maintenance during specific windows. Your API should gracefully handle payment gateway downtime and retry intelligently.
- Language and localization: Error messages, audit logs, and API documentation should be available in both English and Arabic. This isn't a fancy add-on—it's a baseline expectation.
What to build first, what to build later
If you're starting an API-driven project today, here's my honest roadmap:
Weeks 1-2: Authentication. User account creation, login, session management. Get this rock-solid before anything else touches your database.
Weeks 3-4: Your core data endpoints. Customers, invoices, orders—whatever your business is about. Keep it simple. Two or three REST endpoints that do one thing well.
Weeks 5-6: Payment gateway integration. This will take longer than you estimate. Leave buffer here.
Weeks 7-8: Error handling, logging, and monitoring. This feels like overhead but it's what separates systems that work from systems that work until they don't.
Week 9+: Optimization. Only after you have working code that's been used by real customers do you know what to optimize.
Don't skip any of these. Don't try to build everything in week 1. Don't add caching or GraphQL before you have a working REST API. I've seen teams skip to "optimization" on day one and never finish anything.
If you're building something more complex—a multi-tenant SaaS or a marketplace—the timeline doubles, but the principle stays the same. Ship something that works, then improve it based on what you actually learn.
When to reach out for help
You should probably work with an experienced team if your project involves any of: multiple payment gateways, real-time data synchronization across systems, complex authorization logic, or integration with legacy systems. I'd also be honest if this is your first API—it's better to get the foundation right with experienced help than to refactor under time pressure later.
At Tech Vision Era, we've built APIs for everything from e-commerce platforms serving the entire Gulf region to internal CRM systems for consulting firms to SaaS platforms with thousands of users. If you want to talk through your specific situation—whether you're just thinking about it or you're mid-project and something's not working—WhatsApp us at +60 10 247 3580. We give honest advice about what you actually need versus what sounds cool.