مقارنة REST و GraphQL في البيئات الإنتاجية: التنازلات، مشكلة N+1، وحقيقة الكاش

🔌 RESTful API vs GraphQL

REST مش مجرد GET / POST / PUT / DELETE

وGraphQL مش مجرد "REST بطريقة مختلفة"

الاختيار الصح بيبدأ من المشكلة، مش من الـtrend.

📚 Table of Contents

• الفكرة في دقيقة
• يعني إيه RESTful API؟
• REST Architectural Constraints
• Resource-Oriented Design
• HTTP Methods
• Safe و Idempotent Methods
• HTTP Status Codes
• Statelessness
• Caching في REST
• REST Example
• مشاكل REST: Over-fetching و Under-fetching
• يعني إيه GraphQL؟
• GraphQL Query
• GraphQL Schema
• Resolvers
• N+1 Problem و DataLoader
• GraphQL مش أسرع دائمًا
• GraphQL Caching
• GraphQL Security
• REST vs GraphQL
• When to Choose REST
• When to Choose GraphQL
• Hybrid Architecture
• Common Misconceptions
• Production Checklist
• الخلاصة
• Further Reading

⚡ الفكرة في دقيقة

ناس كتير أول ما تتعلم تعمل API تحفظ:

GET
POST
PUT
DELETE

وبعدها تقول:

"أنا كده بعمل RESTful API."

لكن الحقيقة:

وجود HTTP Methods لا يجعل الـAPI RESTful تلقائيًا.

وفي الناحية التانية، أول ما تسمع:

GraphQL

ممكن تتخيله:

"REST بس بطريقة مختلفة."

لكن GraphQL بيغير طريقة التفكير نفسها في تصميم الـAPI.

بشكل مبسط:

REST
Client → Resource → HTTP Method → Representation

GraphQL
Client → Query → Fields / Graph → Resolvers → Data

والاختيار بينهم مش:

REST ❌
GraphQL ✅

لكن:

What problem are we solving?
          ↓
What data shape do clients need?
          ↓
What caching / security / performance model do we need?
          ↓
Choose the architecture

🧠 يعني إيه RESTful API؟

REST اختصار لـ:

Representational State Transfer

وهو Architectural Style وليس Framework أو Library.

REST اتقدم كـarchitectural style للأنظمة الموزعة، وRichard Fielding شرح قيوده ومبادئه في أطروحته التي قدمت REST كطريقة لتوجيه تصميم Web architecture. citeturn0search0turn0search3

الفكرة الأساسية:

فكر في الـSystem كـResources.

بدل ما تفكر في Actions:

/getUser
/createOrder
/deleteProduct

تفكر في Resources:

/users
/orders
/products

وبعدين تستخدم HTTP semantics للتعبير عن العملية.

🧱 Resource-Oriented Design

مثال:

GET /users/5

هات الـUser رقم 5.

POST /users

أنشئ User جديد.

PUT /users/5

استبدل/حدّث تمثيل الـUser رقم 5 بالكامل وفق semantics الخاصة بـPUT.

PATCH /users/5

عدّل جزء من الـUser.

DELETE /users/5

احذف الـUser.

الفكرة:

URL
 ↓
What resource?

HTTP Method
 ↓
What operation semantics?

❌ أمثلة مش Resource-Oriented

الـAPI دي ممكن تشتغل عادي جدًا:

POST /getAllProducts
POST /deleteUser
GET /createOrder
POST /updateProduct

لكن استخدام HTTP Methods بهذا الشكل لا يجعل التصميم RESTful تلقائيًا.

أفضل:

GET /products
DELETE /users/5
POST /orders
PATCH /products/10

مهم جدًا

مش كل endpoint لازم يكون حرفيًا CRUD.

بعض العمليات لا تكون Resource CRUD بشكل مباشر، وقد تحتاج تصميمًا يعتمد على Action/Command أو Resource جديد.

مثال:

POST /orders/123/cancellations

أو حسب الـdomain:

POST /orders/123/cancel

المهم هو إنك تكون واعيًا بالـdomain semantics بدل تحويل كل شيء إلى CRUD بشكل أعمى.

🏛️ REST Architectural Constraints

دي النقطة اللي بتفرق بين:

HTTP API

و:

REST-style API

REST مبني على مجموعة من architectural constraints، من أهمها:

Fielding يوضح أن REST لا يساوي مجرد HTTP endpoints؛ الـuniform interface نفسه يتكون من قيود مثل identification of resources، manipulation through representations، self-descriptive messages، وhypermedia as the engine of application state. citeturn0search0

ملاحظة مهمة

في الـindustry، مصطلح REST API غالبًا يستخدم بشكل أوسع وأقل صرامة من REST architectural style كما وصفه Fielding.

لذلك ممكن تلاقي API ممتازة وناس تسميها RESTful رغم أنها لا تطبق كل قيود REST النظرية، خصوصًا HATEOAS.

🔄 HTTP Methods

Idempotent لا يعني أن العملية تُنفذ مرة واحدة.
يعني أن تكرار نفس الطلب له نفس الـintended effect على الـresource من ناحية semantics.

🛡️ Safe و Idempotent Methods

Safe

الـSafe method لا يُفترض أن يسبب تغييرًا في حالة الـresource من خلال الطلب نفسه.

مثال:

GET /products/5

ممكن السيرفر يعمل:

• Logging
• Metrics
• Analytics

لكن الـGET نفسه لا يُفترض أن ينفذ mutation على الـresource.

Idempotent

لو نفذت:

PUT /users/5

مرة:

name = Amr

ثم نفذته مرة ثانية بنفس الـbody:

name = Amr

الـintended state النهائية نفسها.

أما:

POST /orders

فإعادة نفس الطلب قد تنشئ Order جديد كل مرة.

لذلك POST ليس idempotent بشكل افتراضي.

Idempotency Keys

في عمليات حساسة مثل Payments، ممكن تستخدم:

POST /payments
Idempotency-Key: 8b7c...

عشان تمنع duplicate processing عند retry.

ودي نقطة مهمة جدًا في Production APIs.

📡 Statelessness

REST يعتمد على فكرة:

كل Request يجب أن يحتوي على المعلومات اللازمة لفهمه ومعالجته.

مثال:

GET /profile
Authorization: Bearer <token>

الـServer لا يحتاج أن يتذكر:

"ده نفس الـrequest بتاع من شوية"

عشان يفهم الطلب الحالي.

ليه Statelessness مفيدة؟

             Load Balancer
             /     |     \
            ▼      ▼      ▼
         Server  Server  Server
            A      B      C

أي Request ممكن يروح لأي instance.

وده يساعد في:

• Horizontal scaling
• Load balancing
• Failover
• Simpler server-side state management
• Debugging

Fielding يوضح أن stateless constraint يجعل كل interaction مستقلًا، مع trade-off يتمثل في إمكانية زيادة البيانات المتكررة المرسلة مع الطلبات. citeturn0search0

📦 HTTP Status Codes

REST-style APIs تستفيد من HTTP semantics بدل اختراع status codes خاصة بكل حاجة.

401 vs 403

401
↓
Who are you?

403
↓
I know who you are,
but you're not allowed.

🧊 Caching في REST

دي واحدة من أقوى نقاط REST.

مثلًا:

GET /products/5

ممكن يستخدم:

Cache-Control
ETag
Last-Modified
If-None-Match
CDN
Browser Cache
Reverse Proxy

مثال:

HTTP/1.1 200 OK
Cache-Control: public, max-age=300
ETag: "product-5-v12"

بعدها:

GET /products/5
If-None-Match: "product-5-v12"

لو البيانات لم تتغير:

304 Not Modified

فيتم استخدام النسخة الموجودة في الـcache بدل إرسال الـbody كاملًا.

HTTP caching وETag/If-None-Match موثقان ضمن HTTP semantics، وMDN توضح كيف يمكن لـETag أن يؤدي إلى 304 Not Modified عند عدم تغير الـresource. citeturn0search1turn0search5

🛒 REST Example

تخيل E-Commerce App عنده Profile Screen فيها:

• User information
• Last orders
• Items داخل كل Order
• Cart count

ممكن الـFrontend يعمل:

GET /users/5

ثم:

GET /users/5/orders

ثم لكل Order:

GET /orders/101/items
GET /orders/102/items
GET /orders/103/items

ثم:

GET /cart/summary

فتصبح شاشة واحدة:

1. GET /users/5
2. GET /users/5/orders
3. GET /orders/101/items
4. GET /orders/102/items
5. GET /orders/103/items
6. GET /cart/summary

وممكن تزيد أو تقل حسب تصميم الـAPI والـUI.

📤 مشاكل REST: Over-fetching و Under-fetching

Over-fetching

Endpoint يرجع data أكثر من المطلوب.

مثلاً:

GET /users/5

يرجع:

{
  "id": 5,
  "name": "Amr",
  "email": "...",
  "phone": "...",
  "address": "...",
  "birthDate": "...",
  "profileImage": "..."
}

بينما الشاشة محتاجة:

{
  "name": "Amr"
}

إذًا:

Server
 ↓
Too much data
 ↓
Client

Under-fetching

Endpoint واحد لا يوفر كل البيانات المطلوبة.

Screen
 ↓
Need user
 ↓
Need orders
 ↓
Need order items
 ↓
Need cart

فتضطر تعمل Requests إضافية.

Client
 ├── GET /users/5
 ├── GET /users/5/orders
 ├── GET /orders/101/items
 └── GET /cart/summary

لكن مهم

Over-fetching وUnder-fetching مش "عيوب قاتلة" في REST.

ممكن تقللها باستخدام:

• Better endpoint design
• Embedded resources
• Aggregation endpoints
• BFF (Backend for Frontend)
• Query parameters / sparse fieldsets

🧬 يعني إيه GraphQL؟

GraphQL هو query language + execution model للـAPIs.

الفكرة الأساسية:

الـClient يحدد شكل البيانات التي يريدها، والـServer ينفذ الطلب وفق الـSchema.

بدل ما يكون عندك endpoints كثيرة لكل شكل Response، ممكن يكون عندك GraphQL API تعرض Graph من البيانات.

GraphQL رسميًا يعتمد على Schema تصف ما يمكن للـClient طلبه، والـrequests يتم validation وexecution ضد هذا الـschema. citeturn1view1

🔎 GraphQL Query

مثال:

query GetUserDashboard {
  user(id: 5) {
    name

    orders {
      total

      items {
        productName
        price
      }
    }

    cart {
      itemsCount
    }
  }
}

والـResponse يكون قريبًا من شكل الطلب:

{
  "data": {
    "user": {
      "name": "Amr",
      "orders": [
        {
          "total": 250,
          "items": [
            {
              "productName": "Keyboard",
              "price": 100
            }
          ]
        }
      ],
      "cart": {
        "itemsCount": 3
      }
    }
  }
}

GraphQL يسمح للـClient باختيار fields محددة، ويمكنه traversing للعلاقات للحصول على بيانات مترابطة في request واحدة. citeturn1view0

🧩 GraphQL Schema

الـSchema هو العقد الذي يحدد:

إيه البيانات والعمليات التي يمكن طلبها؟

مثال:

type User {
  id: ID!
  name: String!
  email: String!
  orders: [Order!]!
}

type Order {
  id: ID!
  total: Float!
  items: [OrderItem!]!
}

type Query {
  user(id: ID!): User
}

الـClient لا يستطيع ببساطة طلب:

user {
  passwordHash
}

إلا لو هذا field موجود ومسموح به في الـschema.

GraphQL schema تصف أنواع البيانات والـfields والـarguments والـQuery/Mutation/Subscription entry points، ثم يتم validation للطلبات ضدها. citeturn1view1

🔀 Query / Mutation / Subscription

GraphQL عنده 3 operation types رئيسية:

query
mutation
subscription

Query

للقراءة:

query {
  user(id: 5) {
    name
  }
}

Mutation

لتغيير البيانات:

mutation {
  createUser(input: {...}) {
    id
    name
  }
}

Subscription

للـreal-time updates:

subscription {
  orderUpdated {
    id
    status
  }
}

🧠 Resolvers

GraphQL مش بيجيب البيانات بالسحر.

لازم السيرفر يعرف:

لما الـClient يطلب field معين، أجيب البيانات منين؟

هنا يأتي دور Resolvers.

مثال:

Query.user
      ↓
User Resolver
      ↓
User Service
      ↓
Database

وبعدين:

User.orders
      ↓
Orders Resolver
      ↓
Orders Service
      ↓
Database

ثم:

Order.items
      ↓
Items Resolver
      ↓
Database

GraphQL implementations قد تجمع schema definitions والـresolver functions معًا أو تفصل بينهم حسب المكتبة، والـresolver هو جزء من تنفيذ الـfields المطلوبة. citeturn1view1

💥 N+1 Problem و DataLoader

دي من أشهر مشاكل GraphQL.

تخيل:

100 Users

وكل User عنده Orders.

ممكن التنفيذ يعمل:

1 query
↓
Get 100 users

100 queries
↓
Get orders for each user

الإجمالي:

101 database queries

وده:

N+1 Query Problem

🚀 DataLoader

من الحلول الشائعة:

User IDs
[1,2,3,4,5,...100]
        ↓
DataLoader
        ↓
Batch
        ↓
One query

بدل:

SELECT * FROM orders WHERE user_id = 1;
SELECT * FROM orders WHERE user_id = 2;
SELECT * FROM orders WHERE user_id = 3;
...

ممكن تعمل query تجمع IDs:

SELECT *
FROM orders
WHERE user_id IN (1,2,3,...100);

DataLoader هو utility شائع في GraphQL data fetching لتقليل requests إلى backends عن طريق batching وcaching. citeturn1view2

⚡ GraphQL مش أسرع دائمًا

دي من أشهر الـmisconceptions:

"GraphQL أسرع من REST."

مش قاعدة.

GraphQL ممكن يقلل عدد round trips أو كمية البيانات المطلوبة من client، لكن السيرفر نفسه قد ينفذ عمليات أكثر تعقيدًا.

مثلاً:

GraphQL Request
      ↓
Parse
      ↓
Validate
      ↓
Execute
      ↓
Resolver A
      ↓
Resolver B
      ↓
Resolver C
      ↓
Database
      ↓
Response

لو الـResolvers مكتوبة بشكل سيئ:

GraphQL
   ↓
N+1
   ↓
1000 DB queries
   ↓
💥

بينما REST endpoint بسيط ممكن يكون:

GET /products/5
      ↓
One optimized query
      ↓
Fast response

🧊 GraphQL Caching

REST عنده advantage طبيعي مع HTTP caching لأن:

GET /products/5

واضحة للـBrowser/CDN/Proxy.

GraphQL غالبًا يستخدم endpoint مثل:

POST /graphql

لكن GraphQL ليس ممنوعًا من caching.

يمكن استخدام:

• Client-side normalized cache
• Persisted queries
• Response caching
• CDN strategies
• GET for query operations
• Cache keys based on operation/query/variables
• Field-level caching حسب الـimplementation

لكن المشكلة:

REST
GET /products/5

سهل جدًا فهمه كـHTTP cache key.

بينما:

POST /graphql
query + variables

يحتاج strategy أكثر تعقيدًا.

GraphQL caching ممكن، لكنه يحتاج تصميمًا أكثر من مجرد الاعتماد على URL + HTTP semantics.

🔐 GraphQL Security

GraphQL يعطي الـClient flexibility قوية.

وده ممتاز.

لكن flexibility بدون controls ممكن تبقى مشكلة.

مثلاً:

users {
  orders {
    items {
      product {
        reviews {
          author {
            orders {
              items {
                ...
              }
            }
          }
        }
      }
    }
  }
}

Query عميقة جدًا ممكن تعمل ضغط ضخم على:

• CPU
• Memory
• Database
• Internal services

عشان كده GraphQL production APIs قد تحتاج:

• Depth limits
• Complexity limits
• Rate limiting
• Query timeouts
• Persisted queries
• Query allowlists
• Monitoring
• Authorization
• Introspection policy حسب environment

🔒 Authorization في GraphQL

في REST ممكن يكون واضح:

GET /admin/users

لكن في GraphQL:

query {
  user {
    name
    email
    salary
    permissions
  }
}

محتاج تفكر:

Can user call this query?
        ↓
Can user access this object?
        ↓
Can user access this field?
        ↓
Can user access this nested relation?

يعني الـauthorization ممكن يحتاج يكون أكثر دقة على مستوى:

• Operation
• Object
• Field
• Resolver
• Business rule

🧱 REST vs GraphQL

🆚 نفس الـFeature بالطريقتين

REST

GET /users/5
GET /users/5/orders
GET /orders/101/items
GET /cart/summary

الميزة

كل endpoint واضح.

العيب

ممكن تعمل عدة round trips.

GraphQL

query {
  user(id: 5) {
    name
    orders {
      total
      items {
        productName
        price
      }
    }
    cart {
      itemsCount
    }
  }
}

الميزة

Client يحدد data shape.

العيب

السيرفر يحتاج ينفذ graph traversal بكفاءة.

🟢 When to Choose REST

REST غالبًا اختيار ممتاز لما:

1. CRUD واضح

Users
Products
Orders
Categories

2. HTTP caching مهم

GET
ETag
CDN
Cache-Control

3. Public API

API واضحة وسهلة الاستهلاك.

4. Simple Frontend

لو الـscreens بسيطة:

List
Details
Create
Edit
Delete

GraphQL ممكن يكون unnecessary complexity.

5. File Uploads / Webhooks

REST غالبًا أبسط للتعامل مع:

• Multipart uploads
• Webhooks
• Simple callbacks

🔵 When to Choose GraphQL

GraphQL يبدأ يكون attractive لما:

1. UI معقد

Dashboard فيها:

User
 ├── Orders
 │    └── Items
 ├── Recommendations
 ├── Notifications
 └── Cart

2. Clients مختلفة

مثلاً:

Web
Mobile
Tablet
Smart TV

وكل واحد محتاج data shape مختلف.

3. البيانات مترابطة

GraphQL ممتاز في traversing العلاقات.

4. UI requirements بتتغير بسرعة

بدل إنشاء endpoint جديد لكل شكل Response، الـClient يطلب fields مختلفة ضمن الـSchema.

5. Backend Aggregation

لما الـAPI تجمع data من:

Database
   +
REST services
   +
Microservices
   +
External APIs

GraphQL ممكن يعمل كـaggregation layer أمام الـclients.

🤝 Hybrid Architecture

أكبر غلطة:

"هنحول كل حاجة GraphQL."

مش لازم.

ممكن:

                    ┌──────────────┐
                    │   Frontend   │
                    └──────┬───────┘
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
         REST APIs                  GraphQL
              │                         │
              ▼                         ▼
        Simple CRUD              Complex Screens
        Uploads                  Aggregation
        Webhooks                 Mobile
        Public APIs              Dashboards
              │                         │
              └────────────┬────────────┘
                           ▼
                    Services / DB

REST

ممكن تستخدمه لـ:

• Login
• Uploads
• Webhooks
• Simple CRUD
• Public endpoints
• Cache-heavy resources

GraphQL

ممكن تستخدمه لـ:

• Dashboards
• Aggregated data
• Complex UI
• Mobile clients
• Flexible read models

وده مش تناقض.

REST وGraphQL ممكن يعيشوا مع بعض في نفس system.

🧪 Common Misconceptions

❌ "عندي GET وPOST يبقى REST"

لا.

HTTP methods وحدها لا تكفي لتطبيق REST architectural style.

❌ "REST قديم وGraphQL جديد"

لا.

هما approaches مختلفة لحل مشاكل مختلفة.

❌ "GraphQL أسرع"

مش دائمًا.

ممكن يقلل round trips وover-fetching، لكن execution ممكن يكون أعقد.

❌ "GraphQL endpoint واحد دائمًا"

غالبًا GraphQL APIs تستخدم endpoint واحد، لكن GraphQL specification نفسها لا تفرض أن كل deployment لازم يكون endpoint واحد.

❌ "GraphQL يلغي Backend logic"

لا.

الـResolvers والـservices والـdatabase calls والـauthorization كلها ما زالت موجودة.

❌ "GraphQL يحل N+1 تلقائيًا"

لا.

ممكن GraphQL implementation تعمل N+1 بسهولة لو الـresolvers غير مصممة صح.

❌ "REST يعني CRUD فقط"

لا.

REST مبني على architectural constraints، وCRUD مجرد طريقة شائعة لتصميم Resource operations.

❌ "PUT وPATCH نفس الحاجة"

لا.

PUT
→ replacement semantics

PATCH
→ partial modification

التفاصيل الدقيقة تعتمد على representation وAPI contract.

📊 Decision Matrix

الألوان هنا تعني مدى ملاءمة الـapproach للـrequirement، مش إن technology "أفضل" بشكل مطلق.

🏗️ Production Architecture

REST

flowchart LR
    C[Client] --> CDN[CDN / HTTP Cache]
    CDN --> LB[Load Balancer]
    LB --> API[REST API]
    API --> S[Services]
    S --> DB[(Database)]

GraphQL

flowchart LR
    C[Client] --> G[GraphQL API]
    G --> V[Validation]
    V --> R[Resolvers]
    R --> D[DataLoaders / Services]
    D --> DB[(Database)]
    R --> X[External Services]

Hybrid

flowchart TD
    C[Web / Mobile Clients] --> G[GraphQL]
    C --> R[REST]

    G --> S[Shared Services]
    R --> S

    S --> DB[(Database)]
    S --> X[External APIs]

🛡️ Production Checklist

REST

• صمم الـAPI حول Resources وليس أفعال عشوائية
• استخدم HTTP methods حسب semantics
• فرّق بين PUT وPATCH
• استخدم status codes بشكل صحيح
• حافظ على Statelessness حيث يناسب التصميم
• استخدم HTTP caching عندما يكون مناسبًا
• استخدم ETag / Last-Modified عند الحاجة
• صمم idempotency للعمليات الحساسة
• استخدم pagination للـcollections الكبيرة
• خطط للـversioning
• وثق الـAPI باستخدام OpenAPI
• اختبر authorization على كل protected resource

GraphQL

• صمم Schema واضحة
• استخدم meaningful operation names
• افهم Query / Mutation / Subscription
• صمم resolvers بكفاءة
• عالج N+1
• استخدم DataLoader عندما يكون مناسبًا
• ضع depth limits
• ضع complexity limits
• استخدم rate limiting
• راقب expensive queries
• صمم authorization على مستوى field/object عند الحاجة
• فكر في persisted queries للـproduction use cases المناسبة
• صمم caching strategy
• تعامل مع introspection حسب security policy

Architecture

• اختار technology بناءً على requirements
• لا تستخدم GraphQL لمجرد أنه Trend
• لا تستخدم REST لمجرد أنه "الطريقة القديمة"
• قيّم caching
• قيّم latency
• قيّم network conditions
• قيّم client diversity
• قيّم operational complexity
• قيّم security model
• فكر في Hybrid Architecture عندما تكون مناسبة

🧭 سؤال الاختيار الحقيقي

بدل:

"REST ولا GraphQL؟"

اسأل:

1. مين الـClients؟
        ↓
2. شكل البيانات ثابت ولا متغير؟
        ↓
3. هل البيانات مترابطة بشكل كبير؟
        ↓
4. هل HTTP/CDN caching مهم؟
        ↓
5. هل عندنا Mobile clients؟
        ↓
6. هل الـAPI Public؟
        ↓
7. هل نحتاج Client-driven data fetching؟
        ↓
8. هل الفريق مستعد لتشغيل GraphQL complexity؟
        ↓
9. ما هو security model؟
        ↓
10. ما هو operational cost؟

بعدها اختار.

🎯 الخلاصة

GraphQL مش:

"REST الجديد."

وREST مش:

"طريقة قديمة لازم نستبدلها."

REST ممتاز لما:

Resources واضحة
+
HTTP semantics مهمة
+
Caching مهم
+
Operations بسيطة

GraphQL ممتاز لما:

Data graph معقد
+
Clients متعددة
+
UI requirements متغيرة
+
Client يحتاج يحدد fields

لكن أهم نقطة:

المهندس الشاطر مش اللي يقول "أنا بستخدم GraphQL".

ومش اللي يقول:

"REST أحسن وخلاص."

المهندس الشاطر هو اللي يسأل:

What problem are we solving?

ثم يختار الـarchitecture التي تحل المشكلة بأقل:

Complexity
+
Risk
+
Operational Cost

وأفضل Architecture مش هي الأكثر trendy.

هي اللي تناسب الـrequirements فعلًا.

📚 Further Reading

REST

• Roy Fielding — REST Architectural Style
• Roy Fielding — REST Conclusions

GraphQL

• GraphQL — Official Queries Guide
• GraphQL — Official Schema & Types Guide
• GraphQL — Official Best Practices

DataLoader

• GraphQL DataLoader

HTTP

• MDN — HTTP Caching
• MDN — ETag

🚀 Don't choose REST or GraphQL because it's popular.

Choose the one that fits the problem.