How JWT Works in API Authentication
Things Every Developer Should Know: JSON Web Token.
JWTs are one of the most widely used methods for API authentication, providing a secure, stateless and scalable way to verify clients.
𝗛𝗲𝗿𝗲’𝘀 𝗮 𝘀𝗶𝗺𝗽𝗹𝗲-𝘁𝗼-𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝗯𝗿𝗲𝗮𝗸𝗱𝗼𝘄𝗻 𝗼𝗳 𝗵𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀, 𝘀𝘁𝗲𝗽 𝗯𝘆 𝘀𝘁𝗲𝗽:
𝟭) 𝗖𝗹𝗶𝗲𝗻𝘁 𝗮𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻
The client (a user, app, or device) provides credentials (eg; username/password) to the authentication server.
𝟮) 𝗦𝗲𝗿𝘃𝗲𝗿 𝘃𝗲𝗿𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻
The authentication server checks the credentials against its database or identity provider to confirm their validity.
𝟯) 𝗝𝗪𝗧 𝗶𝘀𝘀𝘂𝗮𝗻𝗰𝗲
If authentication is successful, the server:
☑ Generates a JWT with claims (eg; user ID, roles, permissions).
☑ Signs the JWT using a secret key (HS256) or a private key (RS256).
𝟰) 𝗧𝗼𝗸𝗲𝗻 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆
The server sends the signed JWT back to the client in the response.
𝟱) 𝗦𝗲𝗰𝘂𝗿𝗲 𝘀𝘁𝗼𝗿𝗮𝗴𝗲
The client stores the JWT securely to prevent unauthorized access. HTTP-only cookies are the most secure and widely used method.
𝟲) 𝗔𝗣𝗜 𝗿𝗲𝗾𝘂𝗲𝘀𝘁𝘀 𝘄𝗶𝘁𝗵 𝗝𝗪𝗧
For each request to a protected API, the client includes the JWT in the Authorization header:
`Authorization: Bearer <JWT>`
𝟳) 𝗦𝗲𝗿𝘃𝗲𝗿 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗲𝘀 𝘁𝗵𝗲 𝗝𝗪𝗧
The API server verifies the JWT before granting access by checking:
☑ Signature – Confirms token integrity (not tampered with).
☑ Expiration – Ensures the token hasn’t expired.
☑ Audience (aud claim) – Checks if the token is meant for this API.
☑ Issuer (iss claim) – Confirms the token was issued by a trusted authority.
If the JWT is valid, the server grants access to the requested resource. Otherwise, it rejects the request (401 Unauthorized).
𝟴) 𝗧𝗼𝗸𝗲𝗻 𝗲𝘅𝗽𝗶𝗿𝗮𝘁𝗶𝗼𝗻 & 𝗿𝗲𝗳𝗿𝗲𝘀𝗵
Since JWTs expire for security reasons, the client needs a refresh token to get a new one:
↳ Client sends refresh token to the server.
↳ Server verifies & issues a new JWT if the refresh token is valid.
↳ New JWT replaces the expired one, and the client continues making requests.
gRPC Clearly Explained
gRPC: What It Is and Why Teams Use It
Most teams reach for REST by habit.
It works, it’s everywhere, and every tool knows how to talk HTTP+JSON.
But once you have dozens of microservices calling each other thousands of times per request, REST can quietly become the bottleneck.
That’s where gRPC shows up with a very different model: “call a function on another service as if it were local,” and make it fast.
What gRPC (and RPC) really is
Before gRPC, there’s RPC.
Remote Procedure Call (RPC) is a model where you call a function that runs on another machine, but it feels local to the caller.
You call a method, pass arguments, and get a result back. The network exists, but it’s intentionally hidden so developers can think in terms of functions instead of sockets and packets.
gRPC is a modern, open-source RPC framework released by Google in 2015. It takes the RPC idea and standardizes how services define methods, exchange data, and communicate efficiently over the network.
Two building blocks drive almost everything you feel in practice:
- HTTP/2 → The transport protocol. It keeps a long-lived connection and supports multiplexed streams.
- Protocol Buffers (Protobuf) → The data format. It’s a compact binary serialization with a schema (a defined shape).
Together, these turn “call a service” into a strongly typed operation instead of a loosely structured document exchange.
How gRPC actually works
gRPC starts with a service definition. You describe your API in a .proto file by defining services (methods) and messages (request and response shapes).
This file is the contract. Both client and server are built from it.
From that contract, gRPC generates code:
- Client stubs → Methods you call like local functions.
- Server interfaces → Methods you implement with your business logic.
When a client calls a gRPC method, the flow is straightforward:
- Serialize → The request is encoded into Protobuf’s binary format.
- Envoyer → The message travels over an existing HTTP/2 stream.
- Dispatch → The server routes it to the correct method.
- Execute → Your code runs.
- Respond → The result is serialized and streamed back.
Because gRPC uses HTTP/2, many calls share one connection and run in parallel. A slow response doesn’t block faster ones behind it, which keeps tail latency under control.
Streaming uses the same mechanism:
- Server-streaming → One request, many responses over time.
- Client-streaming → Many requests, one final response.
- Bidirectional streaming → Both sides send messages independently.
Backpressure is built in. If one side slows down, gRPC slows the stream instead of piling up memory or threads.
The core idea is simple: define a strict contract, generate code from it, and move typed messages efficiently over a shared connection.
Where gRPC pays off
gRPC is a strong fit when you control both ends and you care about efficiency.
- High call volume microservices → Lower per-call overhead adds up fast at scale.
- Latency-sensitive graphs → Multiplexing + smaller payloads reduces tail latency pressure.
- Polyglot stacks → One .proto contract generates stubs across languages, reducing “JSON drift.”
- Service mesh environments → gRPC routes cleanly through modern proxies and is common in mesh control-plane protocols.
Tradeoffs you feel immediately
gRPC’s downsides are predictable, and they usually show up early on.
- Browser calls are not native → You often need gRPC-Web or a REST/JSON gateway for front-end use.
- Debugging is less “curl-friendly” → Binary payloads require tooling like grpcurl or GUI clients with schema access.
- Contracts tighten coupling → Clients must update generated code as schemas evolve, so versioning discipline matters.
- Infra must support HTTP/2 well → Some proxies and firewalls need explicit support or configuration.
How to Decide: Is gRPC a Fit for Your System?
Use gRPC when most of the following are true:
- You control both client and server → Internal microservices inside the same organization.
- You’re performance-sensitive → Many small calls per request, or very high QPS between services.
- You’re polyglot → Multiple languages across teams and services.
- You need streaming → Real-time updates, telemetry, chat, or continuous feeds.
- You want strict contracts → You care about compile-time guarantees and explicit schemas.
Stick to REST (or layer a REST gateway in front of gRPC) when:
- You expose public APIs to unknown clients.
- You want easy browser and curl-based experimentation.
Your main pain is clarity and discoverability, not raw latency or throughput.
In practice, most teams don’t choose one or the other; they split the responsibility.
- gRPC inside your network → Service-to-service, behind an API gateway or service mesh.
- REST/JSON at the edge → For browsers, partners, and mobile apps that prefer HTTP+JSON.
Recap
gRPC is not “REST but faster.”
It’s a different model: remote procedure calls over HTTP/2, using Protobuf contracts, with first-class support for streaming and strong typing.
That makes it excellent for internal microservices, high-performance backends, and real-time systems; as long as you’re willing to invest in schemas, tooling, and a slightly steeper learning curve.
If you’re hitting the limits of REST inside your system (too many chatty JSON calls, tricky real-time updates, or a messy polyglot codebase) gRPC is worth a serious look.
API Design 101: From Basics to Best Practices
API Design 101: From Basics to Best Practices
In this deep dive, we’ll go through the API design, starting from the basics and advancing towards the best practices that define exceptional APIs.
As a developer, you’re likely familiar with many of these concepts, but I’ll provide a detailed explanation to deepen your understanding.
API Design: An E-commerce Example
Let’s consider an API for an e-commerce platform like Shopify, which, if you’re not familiar with is a well-known e-commerce platform that allows businesses to set up online stores.
In API design, we’re concerned with defining the inputs (like product details for a new product) and outputs (like the information returned when someone queries a product) of an API.
For example, to add a new product (Create), you would make a POST request to /api/products where the product details are sent in the request body.
To retrieve products (Read), you need to fetch data with a GET request from /products.
For updating product information (Update), we use PUT or PATCH requests to /products/:id, where id is the id of a product we need to update.
Removing is similar to updating; we make a DELETE request to /products/:id where id is the product we need to remove (Delete).
Communication Protocol and Data Transport Mechanism
Another part is to decide on the Communication Protocol that will be used, like HTTP, WebSockets, etc, and the Data Transport Mechanism: JSON, XML, or Protocol Buffers.
This is the case with RESTful APIs, but we also have GraphQL or gRPC paradigms
API Paradigms
APIs come in different paradigms, each with its own set of protocols and standards.
REST (Representational State Transfer)
Pros: Stateless: Each request from a client to a server must contain all the information needed to understand and complete the request. Uses standard HTTP methods (GET, POST, PUT, DELETE). Easily consumable by different clients (browsers, mobile apps).
Cons: This can lead to over-fetching or under-fetching of data- because More endpoints may be required to access specific data.
Features: Supports pagination, filtering (limit, offset), and sorting. Uses JSON for data exchange.
GraphQL
Pros: Allows clients to request exactly what they need, avoiding over-fetching and under-fetching. Strongly typed schema-based queries.
Cons: Complex queries can impact server performance. All requests are sent as POST requests.
Features: Typically responds with HTTP 200 status code, even in case of errors, with error details in the response body.
GRPC (Google Remote Procedure Call)
Pros: Built on HTTP/2, it provides advanced features like multiplexing and server push. Uses Protocol Buffers, a language-neutral, platform-neutral, extensible way of serializing structured data. Efficient in terms of bandwidth and resources, especially suitable for microservices.
Cons: Less human-readable compared to JSON. Requires HTTP/2 support.
Features: Supports data streaming and bi-directional communication. Ideal for server-to-server communication.
Relationships in API Design
In an e-commerce setting, you might have relationships like the user to orders, orders to products, etc.
Designing endpoints to reflect these relationships is important. For example, in this scenario GET /users/{userId}/orders should fetch orders for a specific user.
Queries, Limit, and Idempotence of GET Requests
Common queries also include limit and offset for pagination or startDate and endDate for filtering products within a certain date range. This allows users to retrieve specific sets of data without overwhelming the system or the user with too much information at once.
A well-designed GET request is idempotent, meaning calling it multiple times doesn’t change the result.
GET requests should never mutate data. They are meant only for retrieval.
Backward Compatibility and Versioning:
When modifying endpoints, it’s important to maintain backward compatibility. This means ensuring that changes don’t break existing clients.
Versioning: Introducing versions (like /v2/products) is a common practice to handle significant changes.
In the case of GraphQL, adding new fields (v2 fields) without removing old ones helps in evolving the API without breaking existing clients.
Rate Limitats and CORS
Another best practice is to set rate limitations. This is used to control the number of requests a user can make in a certain timeframe. This is crucial for maintaining the reliability and availability of your API. It also prevents the API from DDoS attacks.
Common practice is to also set CORS settings Cross-Origin Resource Sharing (CORS) settings are important for web security. They control which domains can access your API, preventing unwanted cross-site interactions.
Explorer la Polyvalence de Méthodes HTTP
Explorer la Polyvalence de Méthodes HTTP
Bien que la plupart des gens utilisent GET, POST, PUT et DELETE lorsque l'on travaille avec HTTP, il ya effectivement 39 différentes actions, ou “verbes”, dans la liste officielle. Dans ce post, nous allons regarder 9 de la plus populaires.
Récupère les données d'un serveur.
Envoie des données à un serveur afin de créer quelque chose de nouveau.
Utilisé pour mettre à jour une ressource existante sur le serveur ou le créer s'il n'existe pas. Par exemple, un client peut utiliser une requête pour envoyer des informations à jour sur un produit pour le serveur, d'écraser les données existantes ou de la création d'un nouveau produit d'entrée si elle n'existe pas déjà.
Lorsque vous mettez à jour votre profil sur un site de média social en changeant seulement la photo de votre profil, le serveur peut utiliser le PATCH méthode pour effectuer cette modification.
Si vous souhaitez supprimer un message ou un commentaire que vous avez posté sur un forum en ligne, une demande de SUPPRESSION peut être utilisé pour effectuer cette suppression.
Les navigateurs utilisent souvent la TÊTE pour vérifier si une page web a changé depuis la dernière visite. Cela permet de déterminer si pour télécharger l'intégralité de la page ou si la version du cache est toujours valide.
Cette méthode est utilisée par les clients pour déterminer les méthodes sont autorisées sur une ressource. Par exemple, un client peut envoyer une demande d'OPTIONS à une API pour trouver les méthodes qui sont pris en charge par l'API.
La TRACE n'est pas couramment utilisé dans la vie quotidienne des scénarios. Il est principalement utilisé pour le débogage avancé et le suivi de l'acheminement des demandes.
La méthode CONNECT est principalement utilisé pour établir des connexions SSL/TLS via un proxy. C'est surtout transparente pour la plupart des utilisateurs et est géré par le navigateur ou le client web.
Comment GIT Fonctionne ?
Git’s popularity is undeniable, as it has become an essential tool for version control and collaboration, making it nearly impossible to ignore its significance in modern coding workflows.
Démystifier RESTful Api: Votre porte d'entrée Moderne de Développement Web
Démystifier RESTful Api: Votre porte d'entrée Moderne de Développement Web
RESTful API, or Representational State Transfer API, serves as the backbone of modern web applications, acting as a virtual file cabinet that stores and manages data on the vast expanse of the internet. Understanding how RESTful APIs work is fundamental for developers and businesses looking to harness the power of the web.
🔗 REST, short for Representational State Transfer, employs standard HTTP methods to interact with data. Let’s break down these methods to help you grasp their significance:
- Let’s say you want to retrieve information about users from your website. You’d send a GET request like this:
- GET
https://www.mounirmaaroufi.com/users
To add new data, like a blog post, you’d use a POST request:
- POST
https://www.mounirmaaroufi.com/blog
For updating data, such as editing a blog post, the PUT request is used:
- PUT
https://www.mounirmaaroufi.com/blog/{blog_id}
When it’s time to remove data, like deleting a blog post, a DELETE request is employed:
- DELETE
https://www.mounirmaaroufi.com/blog/{blog_id}
La façon la plus Simple de Faire un retour à la Bouton du Haut
☑️ Le moyen le plus simple pour faire un retour en arrière vers le haut est d'appuyer sur le bouton "Back" (retour) ou "Return" (retour) de votre clavier.
✔️ 𝙏𝙝𝙚 𝙒𝙞𝙣𝙙𝙤𝙬.𝙨𝙘𝙧𝙤𝙡𝙡𝙏𝙤() 𝘮𝘦𝘵𝘩𝘰𝘥 𝘴𝘤𝘳𝘰𝘭𝘭𝘴 𝘵𝘩𝘦 𝘸𝘪𝘯𝘥𝘰𝘸 𝘵𝘰 𝘢 𝘱𝘢𝘳𝘵𝘪𝘤𝘶𝘭𝘢𝘳 𝘱𝘭𝘢𝘤𝘦 𝘪𝘯 𝘵𝘩𝘦 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵.
✔️ 𝘄𝗶𝗻𝗱𝗼𝘄.𝘀𝗰𝗿𝗼𝗹𝗹𝗧𝗼(𝘅-𝗰𝗼𝗼𝗿𝗱, 𝘆-𝗰𝗼𝗼𝗿𝗱)
⦿ 𝙭-𝙘𝙤𝙤𝙧𝙙 𝘪𝘴 𝘵𝘩𝘦 𝘱𝘪𝘹𝘦𝘭 𝘢𝘭𝘰𝘯𝘨 𝘵𝘩𝘦 𝘩𝘰𝘳𝘪𝘻𝘰𝘯𝘵𝘢𝘭 𝘢𝘹𝘪𝘴 𝘰𝘧 𝘵𝘩𝘦 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 𝘵𝘩𝘢𝘵 𝘺𝘰𝘶 𝘸𝘢𝘯𝘵 𝘵𝘰 𝘣𝘦 𝘥𝘪𝘴𝘱𝘭𝘢𝘺𝘦𝘥 𝘪𝘯 𝘵𝘩𝘦 𝘶𝘱𝘱𝘦𝘳 𝘭𝘦𝘧𝘵.
⦿ 𝙮-𝙘𝙤𝙤𝙧𝙙 𝘪𝘴 𝘵𝘩𝘦 𝘱𝘪𝘹𝘦𝘭 𝘢𝘭𝘰𝘯𝘨 𝘵𝘩𝘦 𝘷𝘦𝘳𝘵𝘪𝘤𝘢𝘭 𝘢𝘹𝘪𝘴 𝘰𝘧 𝘵𝘩𝘦 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 𝘵𝘩𝘢𝘵 𝘺𝘰𝘶 𝘸𝘢𝘯𝘵 𝘵𝘰 𝘣𝘦 𝘥𝘪𝘴𝘱𝘭𝘢𝘺𝘦𝘥 𝘪𝘯 𝘵𝘩𝘦 𝘶𝘱𝘱𝘦𝘳 𝘭𝘦𝘧𝘵.
Vérifiez la pleine mise en œuvre du code avec le bouton dans la section des commentaires
_________________________________
😃 𝙉𝙞𝙘𝙚 𝙢𝙖𝙣, 𝙘𝙝𝙚𝙚𝙧𝙨 🥂
𝗜𝗳 𝘆𝗼𝘂 𝗹𝗲𝗮𝗿𝗻 𝗮 𝗻𝗲𝘄 𝗰𝗼𝗻𝗰𝗲𝗽𝘁 𝘁𝗼𝗱𝗮𝘆 , 𝘀𝗵𝗼𝘄 𝗺𝗲 𝘆𝗼𝘂𝗿 𝘀𝘂𝗽𝗽𝗼𝗿𝘁 , 𝗵𝗶𝘁 𝘁𝗵𝗲 𝗹𝗶𝗸𝗲(👍) 𝗯𝘂𝘁𝘁𝗼𝗻 ❤️
𝗜 𝗵𝗮𝘃𝗲 𝗯𝗲𝗲𝗻 𝗽𝗼𝘀𝘁𝗶𝗻𝗴 𝗮𝗯𝗼𝘂𝘁 𝘄𝗲𝗯 𝗱𝗲𝘃 𝘁𝗿𝗶𝗰𝗸𝘀,
𝗜 𝗮𝗰𝗰𝗲𝗽𝘁 𝗲𝘃𝗲𝗿𝘆 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝗼𝗻 𝗿𝗲𝗾𝘂𝗲𝘀𝘁,😃 𝗹𝗲𝘁’𝘀 𝗰𝗼𝗻𝗻𝗲𝗰𝘁 Mounir Maaroufi 🌍
How to Become A Full-Stack Developer
Blog
How to Become A Full-Stack Developer?
After all, a quick Google search for “full stack development” renders an impossibly long list of acronyms: HTML, CSS, JS, MySQL, and PHP, just to name a few. At heart, full stack developers are highly versatile jacks-of-all-trades in an industry that demands comprehensive programming knowledge.
Take a breath: learning how to become a full stack web developer isn’t as difficult or time-consuming as you initially might think. In this article, we’ll walk you through the basics of full stack development, what you need to learn, and how you can prepare yourself for a full-blown career in development.
Wondering what’s next? Here’s a sneak peek at our six steps to becoming a full stack developer:
- Identify The Skills You Need to Learn
- Determine Your Ideal Timeline
- Start Learning in a Format That Suits You
- Begin Building Your Portfolio
- Start the Job Search
- Ace the Interview
Web Development Process
Blog
Web Development Process
Every web development project has to go through certain steps that take the project from initiation to completion. Here Mounir Maaroufi has shared an Infographic for Web Development Process.
