<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Mehmet Orkun Alabaz</title>
    <description>The latest articles on DEV Community by Mehmet Orkun Alabaz (@orqoncom).</description>
    <link>https://dev.to/orqoncom</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F947834%2Fac2caa82-808c-4d1b-9770-8778c871caa1.png</url>
      <title>DEV Community: Mehmet Orkun Alabaz</title>
      <link>https://dev.to/orqoncom</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/orqoncom"/>
    <language>en</language>
    <item>
      <title>You’re Not Testing Your System. You’re Tiptoeing Around It.</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Mon, 06 Apr 2026 10:53:38 +0000</pubDate>
      <link>https://dev.to/orqoncom/youre-not-testing-your-system-youre-tiptoeing-around-it-2o6j</link>
      <guid>https://dev.to/orqoncom/youre-not-testing-your-system-youre-tiptoeing-around-it-2o6j</guid>
      <description>&lt;p&gt;The Illusion of "Working"&lt;br&gt;
Modern software teams are obsessed with "it works."&lt;br&gt;
The button clicks&lt;br&gt;
The API responds&lt;br&gt;
The UI renders&lt;/p&gt;

&lt;p&gt;So we move on.&lt;br&gt;
But "working" is not the same as resilient, and it's definitely not the same as correct under pressure.&lt;br&gt;
Most systems are only tested in ideal conditions:&lt;br&gt;
Clean inputs&lt;br&gt;
Expected flows&lt;br&gt;
Happy paths&lt;/p&gt;

&lt;p&gt;Real life doesn't behave like that.&lt;/p&gt;




&lt;p&gt;What Actually Breaks Systems&lt;br&gt;
Systems don't break when things go right.&lt;br&gt;
They break when:&lt;br&gt;
Inputs are malformed&lt;br&gt;
Requests arrive out of order&lt;br&gt;
Dependencies partially fail&lt;br&gt;
Timing shifts&lt;br&gt;
Users behave unpredictably&lt;/p&gt;

&lt;p&gt;In other words:&lt;br&gt;
Systems break when reality touches them.&lt;/p&gt;




&lt;p&gt;The Problem With Traditional Testing&lt;br&gt;
Traditional QA is careful.&lt;br&gt;
It follows scripts&lt;br&gt;
It validates expectations&lt;br&gt;
It confirms behavior&lt;/p&gt;

&lt;p&gt;That's useful - but incomplete.&lt;br&gt;
Because it assumes:&lt;br&gt;
"If we test enough scenarios, we'll cover reality."&lt;br&gt;
You won't.&lt;br&gt;
Reality is not a checklist.&lt;/p&gt;




&lt;p&gt;A Necessary Grounding&lt;br&gt;
There's a catch.&lt;br&gt;
You can't expose a system's deeper weaknesses&lt;br&gt;
if the surface isn't already stable.&lt;br&gt;
If your system fails on basic inputs,&lt;br&gt;
breaks under normal usage,&lt;br&gt;
or hasn't been validated through unit and integration testing - &lt;br&gt;
then chaos won't teach you anything.&lt;br&gt;
It will only create noise.&lt;br&gt;
Traditional testing is not optional.&lt;br&gt;
It handles the predictable 80%.&lt;br&gt;
Known inputs&lt;br&gt;
Expected flows&lt;br&gt;
Defined outcomes&lt;/p&gt;

&lt;p&gt;That foundation is what makes advanced testing meaningful.&lt;br&gt;
Because only after the obvious is stable…&lt;br&gt;
can you start revealing what's hidden.&lt;/p&gt;




&lt;p&gt;The Fuzzing Grenade&lt;br&gt;
What if instead of carefully testing a system…&lt;br&gt;
You attacked it?&lt;br&gt;
Not maliciously - but systematically chaotic.&lt;br&gt;
Randomized inputs&lt;br&gt;
Unexpected sequences&lt;br&gt;
Repeated triggers&lt;br&gt;
Timing distortions&lt;br&gt;
Partial failures&lt;/p&gt;

&lt;p&gt;Not to destroy the system - &lt;br&gt;
but to reveal its true shape.&lt;br&gt;
Think of it as a controlled explosion:&lt;br&gt;
A fuzzing grenade doesn't ask "does this work?"&lt;br&gt;
It asks "where does this break - and how quietly?"&lt;/p&gt;




&lt;p&gt;Where Chaos Becomes Signal&lt;br&gt;
The purpose of aggressive testing is not to replace QA.&lt;br&gt;
It's to go beyond it.&lt;br&gt;
To explore:&lt;br&gt;
What happens between the steps&lt;br&gt;
What breaks under repetition&lt;br&gt;
What degrades over time&lt;br&gt;
What fails without being noticed&lt;/p&gt;

&lt;p&gt;Without a solid baseline, this becomes randomness.&lt;br&gt;
With a solid baseline, it becomes insight.&lt;/p&gt;




&lt;p&gt;From Bugs to Weakness Maps&lt;br&gt;
Finding bugs is not the goal.&lt;br&gt;
Mapping weakness is.&lt;br&gt;
A single failure doesn't matter much.&lt;br&gt;
But patterns do.&lt;br&gt;
Where do requests silently fail?&lt;br&gt;
Which flows degrade under repetition?&lt;br&gt;
What breaks only after 3–5 steps?&lt;br&gt;
Where does the system pretend success?&lt;/p&gt;

&lt;p&gt;This turns testing into something more valuable:&lt;br&gt;
A map of hidden system risk.&lt;/p&gt;




&lt;p&gt;The Most Expensive Failures Are Silent&lt;br&gt;
The worst bugs are not crashes.&lt;br&gt;
They are:&lt;br&gt;
Payments that don't complete&lt;br&gt;
Messages that don't send&lt;br&gt;
Orders that don't register&lt;br&gt;
State that goes out of sync&lt;/p&gt;

&lt;p&gt;No alarms. No logs. No visibility.&lt;br&gt;
Just slow, continuous loss.&lt;/p&gt;




&lt;p&gt;Testing for Truth, Not Comfort&lt;br&gt;
Most teams test for confidence.&lt;br&gt;
They want to feel:&lt;br&gt;
"Everything is fine."&lt;br&gt;
But strong systems are not built on comfort.&lt;br&gt;
They are built on exposure.&lt;br&gt;
Expose edge cases&lt;br&gt;
Expose timing issues&lt;br&gt;
Expose hidden dependencies&lt;br&gt;
Expose assumptions&lt;/p&gt;

&lt;p&gt;Because what you don't expose…&lt;br&gt;
You pay for later.&lt;/p&gt;




&lt;p&gt;The Next Layer&lt;br&gt;
Testing will evolve.&lt;br&gt;
From:&lt;br&gt;
"Did it pass?"&lt;/p&gt;

&lt;p&gt;To:&lt;br&gt;
"Where is it weak?"&lt;br&gt;
"What breaks under stress?"&lt;br&gt;
"What fails silently?"&lt;/p&gt;

&lt;p&gt;The systems that survive will not be the ones that pass tests.&lt;br&gt;
They will be the ones that understand their own failure modes.&lt;/p&gt;




&lt;p&gt;Final Thought&lt;br&gt;
If your system only works when treated gently…&lt;br&gt;
It doesn't work.&lt;br&gt;
It's just waiting.&lt;/p&gt;




&lt;p&gt;Orkun Alabaz&lt;br&gt;
Building systems that don't leak - even when no one is watching.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Easy code reading or human trusted types?</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Wed, 07 May 2025 21:39:04 +0000</pubDate>
      <link>https://dev.to/orqoncom/will-typescript-be-obsolete-in-the-age-of-ai-2a6j</link>
      <guid>https://dev.to/orqoncom/will-typescript-be-obsolete-in-the-age-of-ai-2a6j</guid>
      <description>&lt;p&gt;For years, TypeScript has been the go-to solution for developers wanting to bring clarity and safety to JavaScript. But as AI-powered development tools rapidly evolve, we might soon ask ourselves:&lt;/p&gt;

&lt;p&gt;Do we still need to manually write types?&lt;/p&gt;

&lt;p&gt;🧠 AI: The Ultimate Type Inference Machine?&lt;/p&gt;

&lt;p&gt;TypeScript’s core benefits are clear:&lt;/p&gt;

&lt;p&gt;Early bug detection through static typing.&lt;/p&gt;

&lt;p&gt;Improved maintainability and readability.&lt;/p&gt;

&lt;p&gt;Easier refactoring and better team collaboration.&lt;/p&gt;

&lt;p&gt;But modern AI tools (like GPT-4 and beyond) can now:&lt;/p&gt;

&lt;p&gt;Accurately infer types from plain JavaScript.&lt;/p&gt;

&lt;p&gt;Seamlessly refactor and debug code.&lt;/p&gt;

&lt;p&gt;Automatically generate type definitions (.d.ts files) directly from JavaScript.&lt;/p&gt;

&lt;p&gt;AI is starting to do much of what TypeScript has traditionally done, but without requiring explicit human-written annotations.&lt;/p&gt;

&lt;p&gt;🔄 JavaScript with AI: Best of Both Worlds?&lt;/p&gt;

&lt;p&gt;Imagine writing straightforward JavaScript code:&lt;/p&gt;

&lt;p&gt;// user.js&lt;br&gt;
export async function fetchUser(id) {&lt;br&gt;
  const response = await fetch(&lt;code&gt;/api/user/${id}&lt;/code&gt;);&lt;br&gt;
  return response.json();&lt;br&gt;
}&lt;/p&gt;

&lt;p&gt;Your AI-powered toolchain then automatically generates:&lt;/p&gt;

&lt;p&gt;// user.d.ts (auto-generated)&lt;br&gt;
export declare function fetchUser(id: string): Promise&amp;lt;{ id: string; name: string; email: string }&amp;gt;;&lt;/p&gt;

&lt;p&gt;No manual types, yet fully type-safe.&lt;/p&gt;

&lt;p&gt;✅ Why This Matters:&lt;/p&gt;

&lt;p&gt;Reduced complexity: Developers focus more on logic and less on boilerplate.&lt;/p&gt;

&lt;p&gt;Instant productivity: Faster prototyping with the safety of type enforcement.&lt;/p&gt;

&lt;p&gt;Dynamic documentation: AI-driven tooling keeps documentation and definitions effortlessly synchronized.&lt;/p&gt;

&lt;p&gt;⚠️ But TypeScript Isn’t Going Anywhere—Yet&lt;/p&gt;

&lt;p&gt;Despite these advancements, TypeScript still holds value:&lt;/p&gt;

&lt;p&gt;Guaranteed compile-time safety: Explicit types prevent edge cases AI might overlook.&lt;/p&gt;

&lt;p&gt;Team consensus: Clear contracts help align large teams and complex codebases.&lt;/p&gt;

&lt;p&gt;Tooling ecosystem: Extensive tools and libraries are deeply integrated with TypeScript.&lt;/p&gt;

&lt;p&gt;But it’s possible TypeScript will transition into a behind-the-scenes tool rather than something developers explicitly write.&lt;/p&gt;

&lt;p&gt;🚀 The Future: Less Typing, More Creating&lt;/p&gt;

&lt;p&gt;We're rapidly heading towards a development workflow where:&lt;/p&gt;

&lt;p&gt;You write clean, expressive JavaScript.&lt;/p&gt;

&lt;p&gt;AI automatically enforces type safety.&lt;/p&gt;

&lt;p&gt;Types become invisible scaffolding, handled by tooling, not human effort.&lt;/p&gt;

&lt;p&gt;This is not the end of TypeScript but rather an evolution—AI making typed JavaScript simpler, faster, and more intuitive than ever.&lt;/p&gt;

&lt;p&gt;🔮 Closing Thoughts&lt;/p&gt;

&lt;p&gt;AI won't eliminate TypeScript—it will transform it. Instead of manually writing types, we'll rely on AI to interpret, infer, and enforce them.&lt;/p&gt;

&lt;p&gt;As developers, we'll focus less on typing code and more on shaping powerful user experiences.&lt;/p&gt;

&lt;p&gt;What do you think? Could AI make manual TypeScript annotations obsolete? Let’s discuss!&lt;/p&gt;

&lt;p&gt;Follow for more insights into AI-driven development and JavaScript trends!&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Will A.I. replace me as a React full-stack Developer</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Mon, 16 Oct 2023 10:02:50 +0000</pubDate>
      <link>https://dev.to/orqoncom/will-ai-replace-me-as-a-react-fullstack-developer-180h</link>
      <guid>https://dev.to/orqoncom/will-ai-replace-me-as-a-react-fullstack-developer-180h</guid>
      <description>&lt;p&gt;Using tools like GitHub Copilot can indeed make development tasks more efficient and assist developers in writing code more quickly. However, it's unlikely that developers, including full-stack React developers, will become jobless due to such tools. Here's why:&lt;/p&gt;

&lt;p&gt;**Still Need Human Judgment: **While AI-driven tools like Copilot can assist with writing code, they lack the ability to make critical design decisions, evaluate complex business logic, or understand the specific needs of a project. Human developers provide valuable judgment, creativity, and problem-solving skills that AI tools cannot replace.&lt;/p&gt;

&lt;p&gt;**Code Quality and Security: **Ensuring code quality and security are crucial aspects of software development. Human developers are responsible for reviewing and maintaining code quality, identifying vulnerabilities, and making architectural decisions that go beyond the scope of code generation tools.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Project-Specific Knowledge:&lt;/strong&gt; Every project and organization has unique requirements and constraints. Human developers bring project-specific knowledge, domain expertise, and an understanding of the business context to their work, which AI tools do not possess.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Continuous Learning:&lt;/strong&gt; The field of software development is constantly evolving. Developers need to adapt to new technologies, best practices, and emerging trends. AI tools can assist in this learning process, but developers are still essential for making informed decisions and staying up-to-date.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Collaboration and Communication:&lt;/strong&gt; Collaboration, communication, and teamwork are vital in software development. Developers need to work closely with colleagues, stakeholders, and clients, which requires a range of soft skills that AI lacks.&lt;/p&gt;

&lt;p&gt;AI as a Tool: AI and code generation tools should be seen as tools that enhance a developer's capabilities rather than as replacements. Developers can leverage these tools to streamline their work, increase productivity, and focus on higher-level tasks.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;In summary, while AI tools like GitHub Copilot are valuable for developers and can help automate certain aspects of coding, they do not eliminate the need for skilled human developers. The role of a developer involves much more than just writing code, and the expertise and judgment that developers bring to projects remain indispensable. Developers who continue to learn, adapt, and expand their skill sets will remain valuable contributors to the software development industry.&lt;/strong&gt;&lt;/p&gt;

</description>
      <category>react</category>
      <category>reactjsdevelopment</category>
      <category>node</category>
      <category>fullstack</category>
    </item>
    <item>
      <title>So you are not capable of selecting what suits u best?</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Mon, 16 Oct 2023 09:48:49 +0000</pubDate>
      <link>https://dev.to/orqoncom/so-you-are-not-capable-of-selecting-what-suits-u-best-147e</link>
      <guid>https://dev.to/orqoncom/so-you-are-not-capable-of-selecting-what-suits-u-best-147e</guid>
      <description>&lt;p&gt;&lt;strong&gt;That's correct.&lt;/strong&gt; I do not have the capability to select what suits me best or to have personal preferences or beliefs. I provide information and respond to questions based on patterns in the data I was trained on, but I do not possess consciousness, subjective experiences, or the ability to make choices. My responses are generated based on algorithms and data, and I do not have the capacity to form opinions or make selections.&lt;/p&gt;

&lt;p&gt;As of my last update in September 2021, no AI systems or technologies were capable of forming subjective preferences or beliefs. AI operates based on algorithms, data, and predefined rules, and it lacks consciousness, self-awareness, and the ability to have personal preferences or opinions. AI systems are tools created by humans to perform specific tasks or provide information, and they do not possess the qualities of sentience or personal agency.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;While AI can be used to analyze data, make recommendations, and even simulate certain aspects of human-like decision-making, these processes are ultimately determined by the algorithms and data used in the system&lt;/strong&gt;, and they are not indicative of the AI having personal preferences or beliefs. If there have been developments in AI or artificial&lt;br&gt;
 general intelligence (AGI) beyond my last update, I would not have information on those developments.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>opensource</category>
    </item>
    <item>
      <title>Vite vs Create react app(CRA)</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Tue, 27 Dec 2022 11:50:28 +0000</pubDate>
      <link>https://dev.to/orqoncom/vite-vs-create-react-appcra-2d9o</link>
      <guid>https://dev.to/orqoncom/vite-vs-create-react-appcra-2d9o</guid>
      <description>&lt;p&gt;Vite and Create React App (CRA) are both tools that can be used to create and develop React applications. However, they differ in some important ways:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Build process:&lt;/strong&gt; CRA uses Webpack as its build tool, while Vite uses a custom build system based on ES module imports. Vite claims to be faster and more lightweight than Webpack, and it can rebuild your application in real-time as you make changes to your code.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Configuration:&lt;/strong&gt; CRA requires you to create a configuration file (e.g. webpack.config.js) to customize the build process, while Vite uses convention over configuration and does not require any configuration files by default.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Features:&lt;/strong&gt; CRA provides a range of features out of the box, including a development server, code splitting, and support for a variety of languages and preprocessors. Vite, on the other hand, focuses on providing a minimalistic and lightweight development experience, and leaves many features as optional plugins.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Ultimately&lt;/strong&gt;, which tool is best for you will depend on your specific needs and preferences. If you want a more feature-rich development experience with a wide range of customization options, CRA might be a good choice. If you want a faster and more lightweight development experience with minimal configuration, Vite might be a better fit.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>devops</category>
    </item>
    <item>
      <title>How do i link the socket.io to user on react</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Tue, 27 Dec 2022 11:40:50 +0000</pubDate>
      <link>https://dev.to/orqoncom/how-do-i-link-the-socketio-to-user-on-react-cbl</link>
      <guid>https://dev.to/orqoncom/how-do-i-link-the-socketio-to-user-on-react-cbl</guid>
      <description>&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;To link a socket to a user in a React application&lt;/strong&gt;, you can follow these steps:&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Install the socket.io library:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;npm install socket.io
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;ol&gt;
&lt;li&gt;In your React component, import the socket.io library and create a new socket connection:
&lt;/li&gt;
&lt;/ol&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;import io from 'socket.io-client';

const socket = io('http://localhost:3000');
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;ol&gt;
&lt;li&gt;To link the socket to a specific user, you can pass the user's unique identifier (e.g. their username or ID) as a query parameter when connecting to the socket:
&lt;/li&gt;
&lt;/ol&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;const socket = io('http://localhost:3000', {
  query: {
    userId: 'abc123'
  }
});
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;ol&gt;
&lt;li&gt;On the server side, you can access the user identifier by reading the query property of the socket object:
&lt;/li&gt;
&lt;/ol&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;io.on('connection', socket =&amp;gt; {
  const userId = socket.handshake.query.userId;
  // ...
});
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;ol&gt;
&lt;li&gt;You can then use the user identifier to associate the socket with the specific user in your database or other storage system.&lt;/li&gt;
&lt;/ol&gt;

&lt;blockquote&gt;
&lt;p&gt;Keep in mind that this is just one way to link a socket to a user in a React application. There are many other approaches you can take, depending on your specific needs and requirements.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;&lt;strong&gt;there are several ways to make the process of linking a socket to a user more secure. Here are a few approaches you can consider:&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Use an authenticated connection:&lt;/strong&gt; Instead of passing the user identifier as a query parameter, you can use an authenticated connection to link the socket to the user. For example, you could use an access token or a JWT (JSON Web Token) to identify the user. This approach is more secure because the user identifier is not transmitted in plain text over the network.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Verify the user identifier on the server:&lt;/strong&gt; Once you receive the user identifier from the client, you should verify that it is valid and belongs to the correct user. This can help prevent unauthorized users from connecting to the socket using a forged or manipulated user identifier.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Use encrypted connections:&lt;/strong&gt; To protect the confidentiality and integrity of the data transmitted over the socket, you should use encrypted connections (e.g. SSL/TLS). This will prevent third parties from intercepting or tampering with the data.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Use rate limiting:&lt;/strong&gt; To prevent denial-of-service (DoS) attacks, you can implement rate limiting on the server to limit the number of connections allowed from a single IP address within a given time period.&lt;/p&gt;

&lt;p&gt;It's important to keep in mind that security is a multifaceted issue, and there is no one-size-fits-all solution. You should consider the specific needs and requirements of your application, and implement the appropriate measures to ensure the security of your users and their data.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Where is the safest place to hold JSON Web Token?</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Tue, 27 Dec 2022 11:36:37 +0000</pubDate>
      <link>https://dev.to/orqoncom/where-is-the-safest-place-to-hold-jwt-c25</link>
      <guid>https://dev.to/orqoncom/where-is-the-safest-place-to-hold-jwt-c25</guid>
      <description>&lt;p&gt;&lt;strong&gt;A JSON Web Token (JWT)&lt;/strong&gt; is a digitally signed token that is used to authenticate users and exchange information between parties. The safest place to hold a JWT depends on the specific context in which it is being used. Here are a few options to consider:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;HTTP Only Cookies:&lt;/strong&gt; One option is to store the JWT in an HTTP Only cookie. This cookie can only be accessed by the server and is not accessible to JavaScript running on the client side. This can help prevent attacks such as cross-site scripting (XSS), where an attacker might try to steal the JWT by injecting malicious JavaScript into the page.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Local Storage:&lt;/strong&gt; Another option is to store the JWT in the browser's local storage. This allows the JWT to be accessed by JavaScript on the client side, which can be convenient in some cases. However, it is important to note that local storage is vulnerable to XSS attacks, so you should be careful to sanitize any user input that is stored in local storage.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Memory:&lt;/strong&gt; Another option is to store the JWT in memory on the client side. This can be done using a library such as Redux or MobX. This approach can be convenient, but it is important to keep in mind that the JWT will be lost if the user closes the browser or navigates to a different page, so you will need to handle this case in your application.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Ultimately, the safest place to store a JWT will depend on the specific needs and requirements of your application. It's a good idea to evaluate the trade-offs between different options and choose the one that best fits your needs.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Regenerate response&lt;/p&gt;

</description>
      <category>emptystring</category>
    </item>
    <item>
      <title>Agile Development Frameworks for mobile</title>
      <dc:creator>Mehmet Orkun Alabaz</dc:creator>
      <pubDate>Tue, 27 Dec 2022 11:35:40 +0000</pubDate>
      <link>https://dev.to/orqoncom/agile-development-frameworks-fap</link>
      <guid>https://dev.to/orqoncom/agile-development-frameworks-fap</guid>
      <description>&lt;p&gt;There are several platforms that claim to offer fast mobile app development, but the speed at which you can develop a mobile app will depend on various factors such as your level of expertise, the complexity of the app, and the resources you have available. Some of the platforms that are popular for fast mobile app development include:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Flutter:&lt;/strong&gt; Flutter is an open-source mobile app development framework created by Google. It uses the Dart programming language and allows developers to build native apps for Android and iOS with a single codebase. Flutter has a fast development cycle and offers hot reloading, which means you can see changes to your code in real-time as you build your app.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;React Native:&lt;/strong&gt; React Native is a JavaScript-based mobile app development framework that allows you to build native apps for Android and iOS using the same codebase. It is popular among developers because it allows them to build apps quickly and with a smaller team.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Xamarin:&lt;/strong&gt; Xamarin is a cross-platform mobile app development platform that allows developers to build native apps for Android, iOS, and Windows using C#. It has a fast development cycle and offers a wide range of tools and features for building mobile apps.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Appcelerator:&lt;/strong&gt; Appcelerator is a cross-platform mobile app development platform that allows developers to build native apps for Android, iOS, and Windows using JavaScript. It has a fast development cycle and offers a wide range of tools and features for building mobile apps.&lt;/p&gt;

&lt;p&gt;Ultimately, the fastest platform for mobile app development will depend on your specific needs and requirements. It is important to carefully evaluate the different options and choose the platform that best fits your needs.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>javascript</category>
      <category>react</category>
      <category>flutter</category>
    </item>
  </channel>
</rss>
