DEV Community: Yunus Emre Altanay

How I Built a PII Tokenization Middleware to Keep Sensitive Data Out of LLM APIs

Yunus Emre Altanay — Mon, 06 Apr 2026 09:25:18 +0000

The Problem I Kept Ignoring

Every time we sent a customer transcript to an LLM API, we were sending real data — credit card numbers, home addresses, full names, national IDs — in plaintext to a third-party server.

Most teams I've talked to handle this in one of two ways:

Ignore it and hope the provider's data processing agreement covers them
Prompt engineer around it — "don't repeat personal information in your response" — which does nothing about what's already been transmitted

Neither is acceptable in a production system handling real user data. So I built llm-hasher — a PII tokenization middleware that sits between your application and any LLM API.

The Core Idea

The LLM doesn't need to see the actual credit card number to summarize a support transcript. It just needs to know a credit card number was mentioned. So instead of:

"Hi, my card is 4111-1111-1111-1111 and email is john@example.com"

The LLM receives:

"Hi, my card is CREDIT_CARD_john12_4f8a2b and email is EMAIL_john12_9c3d1a"

It can still reason about the context. It just never touches the real values. When the response comes back, you detokenize it and restore the originals.

Architecture

Your App ──► POST /v1/tokenize ──► llm-hasher ──► tokenized text
                                       │
                              detects PII locally
                              (Ollama, no cloud)
                              stores in encrypted vault

Your App ──► [your LLM call with tokenized text]

Your App ──► POST /v1/detokenize ──► llm-hasher ──► original text restored

Three moving parts: a detector, a vault, and an HTTP service wrapping both.

Detection: Hybrid Regex + LLM

PII falls into two categories that require different detection strategies.

Structured PII — credit cards, emails, IBANs, IPv4 addresses — has well-defined patterns. Regex handles these with sub-millisecond latency and 100% recall on valid formats. No need to involve a language model.

Contextual PII — names, addresses, national IDs, passports — is where regex breaks down completely. "John Smith" looks identical to "Smith & Wesson" to a pattern matcher. You need semantic understanding.

For contextual PII, llm-hasher sends the text to a locally running Ollama instance. The model (default: llama3.2:3b) extracts entities and returns structured JSON. Because Ollama runs on your own server, this detection step never touches an external API — your raw data stays on your infra.

The hybrid approach gives you the best of both: speed and precision for structured types, semantic understanding for contextual ones.

Chunking for Long Texts

Sending a 5,000-word transcript to Ollama in one shot causes problems — context window limits, degraded accuracy on long inputs, serial latency.

llm-hasher chunks large texts (configurable, default 800 words) and processes chunks in parallel goroutines:

// Simplified — actual implementation handles overlap and deduplication
func (d *Detector) detectParallel(ctx context.Context, text string) ([]Entity, error) {
    chunks := chunk(text, d.cfg.ChunkSize)
    results := make(chan []Entity, len(chunks))

    var wg sync.WaitGroup
    for _, chunk := range chunks {
        wg.Add(1)
        go func(c string) {
            defer wg.Done()
            entities, _ := d.detectWithOllama(ctx, c)
            results <- entities
        }(chunk)
    }

    wg.Wait()
    close(results)
    return merge(results), nil
}

A 5,000-word document with 6 chunks processes in roughly the same time as a single chunk — latency scales with the slowest chunk, not the total count.

The Vault: AES-256-GCM Encrypted SQLite

Token-to-value mappings are stored in a local SQLite database. Each value is encrypted with AES-256-GCM before being written.

Key design decisions:

Context scoping with your own IDs. Instead of generating opaque foreign UUIDs that you'd need to track on your side, you pass a context_id from your domain:

{
  "text": "Hi, my card is 4111-1111-1111-1111",
  "context_id": "zoom_call_789"
}

This means your Zoom call processor can detokenize with zoom_call_789 without needing to store a mapping between your ID and a vault-generated UUID.

Deduplication within a context. The same PII value within a context always maps to the same token. If a name appears five times in a transcript, the LLM sees the same token each time — so it can reason about the entity consistently across the full text.

TTL support. Tokens can have an expiry:

{
  "text": "...",
  "context_id": "session_abc",
  "ttl": "24h"
}

For compliance scenarios (GDPR right to erasure), there's a hard-delete endpoint:

DELETE /v1/contexts/{context_id}

This removes all mappings for that context from the vault. Once deleted, detokenization is impossible — by design.

Detokenization: Single-Pass Multi-String Replace

Naive detokenization would loop through each token and do a string replace — O(n×m) where n is text length and m is token count. For a transcript with 40 entities, that's 40 passes over the text.

llm-hasher builds an Aho-Corasick automaton from the token set and does a single linear pass:

func (v *Vault) Detokenize(text string, mappings map[string]string) string {
    replacer := strings.NewReplacer(flatten(mappings)...)
    return replacer.Replace(text)
}

Detokenization latency is effectively constant regardless of token count — typically under 5ms even for large documents.

Real-World Integration

Python — LLM Proxy Pattern

import requests
import openai

# 1. Tokenize before sending to LLM
resp = requests.post("http://localhost:8080/v1/tokenize", json={
    "text": transcript,
    "context_id": f"zoom_{call_id}"
})
tokenized = resp.json()

# 2. Send tokenized text to your LLM
llm_response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "Summarize this call transcript."},
        {"role": "user",   "content": tokenized["tokenized_text"]}
    ]
)

# 3. Detokenize the LLM response
final = requests.post("http://localhost:8080/v1/detokenize", json={
    "text": llm_response.choices[0].message.content,
    "context_id": f"zoom_{call_id}"
})
print(final.json()["original_text"])

Go — Library Mode

If you don't want to run a separate HTTP service, import the hasher package directly:

import "github.com/yemrealtanay/llm-hasher/pkg/hasher"

h, err := hasher.New(
    hasher.WithOllama("http://localhost:11434", "llama3.2:3b"),
    hasher.WithVault("data/vault.db", ""),
)
defer h.Close()

result, err := h.Tokenize(ctx, transcript, "zoom_call_789", nil)
// result.Text contains tokenized transcript

original, err := h.Detokenize(ctx, llmResponse, "zoom_call_789")

Performance Characteristics

Scenario	Typical Latency
Short text, regex PII only	< 5ms
Short text with LLM detection	2–8s (model dependent)
Long text (5,000 words), 6 parallel chunks	3–10s
Detokenize (any size)	< 5ms

The dominant cost is Ollama inference. On a modern laptop with llama3.2:3b, expect 2–4 seconds per chunk. A GPU or a larger/faster model changes this significantly. If your use case is async (batch processing, background jobs), the latency is generally acceptable without hardware changes.

For latency-sensitive paths, run tokenization asynchronously before the user-facing LLM call — most pipelines have a natural point to do this.

What It Doesn't Do (Yet)

It's not a firewall. If someone deliberately encodes PII to evade detection (e.g., spelling out digits), llm-hasher won't catch it. It handles the common case, not adversarial inputs.

Ollama recall isn't 100%. The LLM detector misses things, especially in noisy or multilingual text. Tuning confidence_threshold and chunk size helps, but there's no guarantee of perfect recall without human review.

No streaming support yet. Tokenization requires the full text — SSE/streaming tokenization is on the v2 roadmap.

Running It

git clone https://github.com/yemrealtanay/llm-hasher
cd llm-hasher
make docker-up

Docker Compose starts Ollama, pulls llama3.2:3b (~2GB), and starts the service on port 8080. Check it's running:

curl http://localhost:8080/healthz
# {"status":"ok"}

For production, set an explicit vault encryption key:

# Generate
openssl rand -hex 32

# Set in .env
VAULT_KEY=<your_64_char_hex_key>

If VAULT_KEY is not set, a key is auto-generated and saved to data/vault.key. Fine for development, not for production — you need the key to survive restarts.

What's Next

The v2 roadmap includes built-in LLM proxy endpoints (OpenAI-compatible and Anthropic), so instead of calling llm-hasher then your LLM separately, you point your existing OpenAI client at llm-hasher and it handles tokenization transparently in the middle. This would make adoption essentially zero-config for teams already using the OpenAI SDK.

Contributions are welcome, especially for v2 LLM provider adapters — each provider is a well-defined, self-contained implementation.

Learning to Learn: The Real Skill of a Developer

Yunus Emre Altanay — Sun, 02 Nov 2025 15:06:46 +0000

Learning Go is easy.
Five videos, two blogs, a bit of coding, and a few right questions to ChatGPT — and you’ll have your “hello world.”
But the point isn’t learning Go.It’s learning how to learn any technology quickly.
Because tomorrow it’ll be Rust, and the next day, AI will turn it all into some meta-language anyway.

Technology no longer expects humans to be knowledgeable it expects them to be adaptable. Mastering one framework isn’t a skill; being able to understand the logic behind any framework is.The difference now isn’t how much you know, but how fast you can learn.

Knowledge expires. But your way of learning stays. It’s no longer about writing code — it’s about debugging your own learning algorithm.

Why Traditional Learning Fails

Because technology moves at warp speed while we still study like it’s a classroom. We start with articles, videos, notes, repetition and before we know it, we’ve consumed the same information three times from different sources, yet still haven’t built anything.

Traditional learning was made for static worlds. You’d read a book once and the information stayed valid for years. Now the documentation changes between page refreshes. Your handwritten notes are already outdated.

Modern learning isn’t linear it’s cyclical:
Try → Fail → Fix → Try again.
The shorter that loop, the faster you evolve. Traditional methods simply can’t keep up.

The Mistakes We Make While Learning

The most common one: we try to feel like we’re learning, instead of actually learning. We watch videos, take notes, and say “I get it now,” yet we never produce anything. The brain isn’t learning it’s just getting a dopamine hit.

Then comes the obsession with understanding everything before acting. But understanding isn’t the cause of learning it’s the byproduct. Try first, then comprehension comes later. Run the code. Break it. Fix it. The brain extracts meaning from the scars left by failure.

And of course, the speed obsession. Everyone’s shouting, “I learned Rust in a week!” No they learned the syntax, not the thinking model. Speed is being confused with depth. Real learning is still slow but continuous.

Information Is Everywhere, Understanding Is Not

Thanks to AI, it’s now impossible not to access information. But understanding? Still a personal journey. AI gives you answers but if you don’t figure out why those answers work, you’ve learned nothing.

The problem today isn’t ignorance it’s shallowness. Everything is within reach, yet nothing sinks in. We copy a command, it works, and we never ask why. But meaning is born inside that “why.”

Unlimited access to understanding is possible only in one way: by keeping your curiosity muscle alive. Don’t move on the moment you get an answer.
Stop and ask, “Why does this work?” That’s the moment learning actually happens not when you get the answer, but when you question it.

Learning Methods and Mental Endurance
Active Recall

Passive learning is the brain’s enemy. Watching videos, reading articles, taking notes they feed information in but skip the processing part. Active recall means forcing your brain to work. Ask yourself:

“Can I actually explain this topic?”

Close your sources, open a blank page, and explain in your own words. If you can’t form sentences, you haven’t learned it. Learning isn’t about taking in information it’s about reproducing it. That tiny moment of mental friction is where real learning begins.

Spaced Repetition

The brain is built to forget. Trying to memorize everything at once is like writing to RAM it disappears when you power off.

Spaced repetition means planning to forget. Revisit a topic after 1 day, 3 days, 7 days, 14 days. Each time you recall it, your brain re-discovers it, and the connection gets stronger.

Simple rule:

“Review not when you’ve forgotten, but right before you forget.”

That’s when your brain upgrades short-term data into long-term memory.
Learning isn’t a single event it’s a series of well-timed mental workouts.

Zettelkasten (Linked Notes)

Most people treat note-taking like hoarding. But archiving isn’t learning.
Zettelkasten is a way to organize notes by connections, not hierarchy.

Each note links to another ideas form a web.

For example, a note on “learning psychology” connects to “active recall,” which connects to “memory systems.” One day you realize you’ve built a second brain.

In this system, knowledge isn’t static it grows. Each new idea touches an old one, keeping the whole system alive. For developers, this is gold.
It’s not a library; it’s a mental map.

Feedback Loop

Teaching something is the fastest way to learn it. Explaining tests your own reasoning process. Writing documentation, mentoring, or just explaining your code out loud — all of these force your brain to organize knowledge. If you get stuck while explaining, that’s where your gap is.

Learning becomes a cycle:

Try → Teach → Spot the gap → Fix it.

Even explaining to yourself works. Turn on the camera, talk it out, record a voice note. The moment you pretend to be observed, your brain starts cleaning up the mess.

A 5-Step Framework to Learn How to Learn

Knowing the methods isn’t enough you have to systematize them. Here’s a simple model that turns theory into habit.

Map It

Before learning anything, ask:

“What does the map of this topic look like?”
The goal of day one isn’t understanding it’s seeing the outline. What are the subtopics, the key ideas, the dependencies? Draw a map. Give your brain a sense of direction.

Build Small Loops

The fastest way to understand something is to use it immediately. Not in big projects in tiny experiments. New framework? Don’t build a full app make a one-endpoint test. New language? Rebuild a small function.

The goal isn’t perfection; it’s to wire the reflex of try → break → fix → repeat.

Explain to Retain

If you don’t teach it, you’ll forget it. Write, talk, draw, explain even to yourself.

“Explaining is the brain’s compile step.”

That’s when knowledge becomes structured and permanent.

Reflect & Refactor

Every few days, review your process.

“What did I actually understand?”
“What didn’t stick?”
Learning to learn is really refactoring your learning system. Simplify it, optimize it, make it sustainable.

Link Everything

Connect new ideas to old ones. A technology, a concept, a pattern each becomes durable when it links to something you already know. This is why Zettelkasten works: linked memory stays alive. Your brain remembers through relationships, not isolation.

Short Formula

Map → Build → Explain → Refactor → Link

Once this loop becomes a habit, you’ve learned how to learn. Because you no longer ask how to learn one thing you know how to learn anything.

Conclusion

Access to information is no longer a problem. The real challenge is transforming that information into understanding. Languages, frameworks, technologies they’ll keep changing. But those who build their learning system will never fall behind.
Code, architecture, even programming paradigms will shift.
But one truth remains:

Those who learn how to learn never start from zero.

The Art of Asking Questions in the Age of AI

Yunus Emre Altanay — Tue, 23 Sep 2025 10:44:10 +0000

In one of my older writings, I argued that “asking the right question” was the golden key to getting quick and useful answers from people. Back then, developer communities, forums, and Telegram groups were the holy grounds where our questions lived. Everyone had Google, but the real magic was asking the right people in the right way. Ask poorly, and you’d either get mocked or dismissed with: “Dude, do your own research first.”

Today, things are different. Instead of bad-tempered humans, we now face an always-eager, sometimes confused AI. Large Language Models (LLMs) like ChatGPT have rewritten the rules of the game.

Superpowers and Weaknesses of AI

Thrives on raw input

Feed AI code snippets, error logs, and outputs—it digests them instantly. A human would need to parse, think, and simulate first.

Infinite patience

Humans get tired or annoyed. AI doesn’t. Throw a 3-page prompt at it; it won’t ask for a coffee break.

Wrong context = plausible nonsense

The danger zone. Wrong or incomplete context yields answers that look right but waste hours. Context is everything.

Core Principles for AI-Era Questions

1. Research First, Then Ask AI

“Google it first” is still true. Now it means:

Search docs, forums, or GitHub issues.
Use AI to simplify, expand, or validate what you found.

2. Provide Maximum Context

Details matter:

Language, version, framework
Error messages, code snippets
Expected output

Without this, AI can’t guess your intent.

3. Be Explicit, Define the Output Format

Weak ask: “Explain this.”
Strong ask: “Explain this in 3 bullet points, each with a code block and inline comments.”

The clearer your request, the more useful the answer.

4. Ask Step by Step

Instead of:

“Build me a login system.”

Try:

Draft the flow
Add details
Suggest test cases
Refine the code

Small steps prevent irrelevant dumps.

5. Request Version and Source Info

Ask directly:

“Which PHP version does this work for?”
“What documentation does this come from?”

This stops you from applying outdated or mismatched advice.

6. Add Safety Nets

AI isn’t flawless. For production code:

Always ask for test scenarios
Run everything in staging first
Don’t skip validation

Practical Prompt Templates

Debugging

My goal:

Environment:

Code:

Error / Expected:

Expected output:

1) Explain the root cause

2) Suggest a 3-step fix

3) Add test instructions for each step

Design / Architecture

Context:

Constraints:

Problem:

Expected output:

1) 3 alternative solutions with pros/cons

2) Best option + 6-step plan

3) Risks and mitigation strategies

Concept Learning

Topic:

Level:

Expected output:

1) 3-sentence summary

2) Key concepts listed

3) Simple example

4) 2–3 reliable resources

From Human Question to AI Prompt

Original Human Question:

“X data isn’t being posted, and Y function doesn’t work. What do I do?”

AI-Optimized Prompt:

Goal: Send form data via POST to https://api.example.com/forward

Code:

Problem: Request goes out but service returns 500. Log shows ‘Undefined index: body’.

Expectation: Data should be sent, service should return 200.

Expected output:

1) List 5 possible causes

2) Steps to check each cause

3) Example fix in code

No guessing. AI now has the full picture.

Common Mistakes (and Fixes)

No: “It doesn’t work.”
Include logs, environment, and code.

No: Huge, vague asks
Break problems into smaller parts.

No: No format instructions
Say “step by step + code block.”

No: Blind trust
Always test before deploying.

Questions Still Matter

Once, asking well earned you respect in forums. Now, it earns you better AI answers.

Good prompts = good results.
AI doesn’t “know”—it reflects the quality of your input.

So treat AI like your soldier: arm it with context, precision, and clear goals. Technology changes, but the art of asking remains timeless.

Questions still matter—only the address has changed.

Artificial Intelligence, Devin and Farewell to Software Developers(!)

Yunus Emre Altanay — Sun, 17 Mar 2024 17:12:30 +0000

OpenAI has undoubtedly revolutionized our lives. Yes, it has revolutionized the lives of every person, regardless of their profession and their distance from the computer, but we would not be unfair if we say that it touched the lives of software developers the most. CoPilot, developed by Github and OpenAI, was perhaps one of the first footsteps of this revolution. It enabled us to write code faster and easier, and it was improving and improving itself every day. Chatgpt, which was later made available to everyone, Gemini, which has just started to enter our lives, many other artificial intelligence tools, and finally Devin, which is claimed to be the world's first artificial intelligence software engineer.

The revolutions that have come one after another in this short time have undoubtedly created a change in the lives of us software developers. Some people are afraid of losing their profession, while others are about to be convinced that this profession is an unreasonable profession to choose and has no future. Some have found ways to use these technologies to their advantage. Learning faster, writing code faster, delegating simpler tasks to artificial intelligence and finding time to deal with more complex tasks. Some companies seem to have found ways to employ fewer developers. Or everyone thinks that technology companies, which have recently made serious layoffs, are able to work with fewer software developers thanks to Artificial Intelligence.

The revolutions we mentioned above are not the first revolutions of software. This is not the first time that software developers have made such a shocking progress and have to keep up with it.

As humanity, we have created 9000 different programming languages since the emergence of the first computer. Some of these languages became very popular in their time and were used by everyone. Experts in these languages emerged and continued to develop better software as if they would never be shaken.

But revolution was always at the door. Programming languages that are closer to human language, easier to learn and write, and developed for specific tasks have emerged and started to replace popular languages. Slogans that everyone can now learn software were already being shouted in the mid-1990s. In the early 2000s, it was said that software would be taught in primary schools, everyone would be a software developer, and we would continue our daily work, needs and communication with software languages. It was discussed whether programming languages could also be used for human communication.

As programming languages became easy to learn and fun to write, a thesis was put forward every day about which profession was finished and which type of person was no longer needed. Software had become an enemy to people who did not know it.

However, new technologies and languages were also the enemy of software developers. Software developers who did not improve themselves and did not follow innovations that specialized in only one language were lost on the dusty shelves of history. Good software developers produced better software and made the work of both people and themselves easier. This has led to the development of better software developers and the elimination of worse software developers, and has continued to this day.

When software developers developed Google Translate in 2006, it was thought that the translation profession was coming to an end. However, today, Google Translate continues to pave the way for better translators to be trained, for foreign language learners to learn more languages, and for those who do not know the language to benefit, rather than ending the profession of translators.

Technology develops, everyone has to keep up with it. Those who cannot keep up will perish. Programming, which is done with small holes and protrusions drilled into copper plates, has become full of artificial intelligence tools that show us all classes starting with that letter when we press a letter, enable us to update and correct the entire code with a single click, and produce examples when we tell us the code we want to write.

These developments will not destroy software developers, but they will definitely contribute to the development of better software and software developers.

We are now in Devin's era. He can design and code a certain level of software tasks on his own. So what does this mean? This now means a great opportunity for us, software developers, to do much more complex and bigger jobs. According to some, it is a farewell to software developers.

I can understand why the good news that every new artificial intelligence tool will bring the end of software developers is spreading so much on social media. For the last 20 years, software developers have threatened the professions of many people with their innovations and inventions. Of course, imagining that it is their turn may feed our sense of pleasant fantasy and revenge.

However, this new era is nothing more than a light that progresses much faster and indicates that many more software developers can do much bigger things.

Nvidia CEO made a statement in the past weeks implying that learning software is no longer necessary and that we are teaching software to our children in vain. But isn't that all big companies want anyway? Don't bother, we will do it on your behalf and you just pay us.

No. Software is growing like never before and will continue to grow. Maybe it is not a very distant possibility for the dreams made in the late 90s to come true. However, in order to achieve this, we need an artificial intelligence that helps us, rather than an artificial intelligence that controls us. Otherwise, it will be impossible for us to distinguish whether the thing to which we are entrusting our vital decisions is an artificial intelligence or a giant company.

In order to realize this, instead of saying goodbye to software developers, we should know that we need them more...

The Art of Asking Questions

Yunus Emre Altanay — Fri, 16 Jun 2023 14:27:43 +0000

Especially if you have just started software and I can clearly say that even if you haven't started yet, you have asked or wanted to ask hundreds of questions to people working in the software industry. Although I guess what your questions are, in this article, instead of answering these questions, I will try to explain how you can ask effective questions and increase your chances of getting an answer. In addition, although you may not realize it in the article, "asking a question" is a much more important and serious issue than you might imagine. That's why I recommend that you read this article and the "question guide" that I will share at the end, very seriously and carefully.

I said increasing your odds of getting an answer because asking the right question can really increase your odds of getting an answer. Also, this is a possibility because there is no rule that you will get answers to all your questions. People may want to spare their precious time to help you, or they may easily choose not to help you for hundreds of reasons, such as a small word mistake in your question, your reactions to previous answers, your contribution to the community, or even for no reason.

No matter what level of knowledge you have, you will ask questions of others. As your experience in software increases, you will witness a serious change in two things.

The depth and quality of the questions you ask will increase.
You will ask fewer questions and have the ability to find answers yourself faster.

The questions of someone who has not yet started the software are usually as follows;

Where should I start? Which language should I learn? Can I find a job? I went to school, can I find a job? Which language can I find a job faster if I learn? Which language should I start with? I learned X language, what should I do now? Can I learn by myself? Which course should I go to?

The most important skill you need to acquire and develop before asking questions is the ability to research. All of these questions you see above have been asked millions of times and answered millions of times. Before you wait for someone to take the time to answer your question, don't stop, take time for yourself and see if your question really has an answer. Especially if you are planning to enter the sector or if you have just learned the software, that bright question that comes to your mind is very big, but most likely, thousands of people have thought of it before and I am sure it has been answered. So use Google and search.

If you start to develop your research skills from the very first levels, you will find that you are very comfortable as an experienced software developer. Use the internet and rip the information out of her heart!

After showing some professional progress, your questions focus more on technical issues. Most of the technical questions are also probably already answered. However, you may not be able to find the answer because it does not fit with your current scenario. As time progresses, you will easily find how a similar technical question has been answered regardless of your scenario, but it may be difficult to achieve at first. Because you don't have the experience to visualize how many different scenarios a technical application or piece of code can work in yet.

Then you will ask questions, but where? How? to who?

There are software groups on social media, whatsapp or telegram groups, discord channels, and many channels where you can get help with software. Search, find and join these groups related to your language or technology.

You've joined these groups, but don't see the people here as people who dedicate all their time to helping you and others like you, eagerly waiting in line to answer your questions. Everyone is there to help each other and get help when needed someday. Having to learn new things all the time is a must for software and we software developers love to be wherever we can learn new things.

So I want to remind you again, SEARCH before asking a question. Read the documents, see other answers, go through local and foreign sources. I'll recommend a very simple pattern so you can ask your question when you're sure you won't be able to find it through research.

But first, let me convince you why you need this pattern. Before asking a question, you should try to foresee the size of the area covered by that question. For example;

“I want to design a user login system, how do I do it? Can you help me?"

If this question is not a job offer, that is, I want to have a user login system in my project, I am open to your offers, bravo, you asked your first bad question. The scope of your question is so great at first glance; What language, what kind of architecture? Are you designing an API? Is this a service? What do you mean by login? Token? what? Lots and lots of questions. So you askedThe long question gave rise to huge questions. Answering these questions is not something that will happen right away. People will either make fun of you, say a few annoying things, or post an instructional video as broad as the question you ask.

The question you will ask should not be one that you can find the answer to with your education and research. No one can give you a huge education there. It cannot discover what the structure you want to build is and design an answer accordingly. So first make sure your question has a small scope and can be answered right there.

You have determined the scope of your question, but you are still far from asking it correctly.

“I want to post X information, but my Y function is not working, what can I do?”

I don't know? X information Y function, what does it do, what did you write, what is this program? I don't know what you intend to do...

While people are asking questions, they may fall into the misconception that they know the content of the code, so others can understand it. No matter how experienced he is, no one can give an answer to a structure whose contents he does not know.

Here, I will share a simple pattern with you to avoid this mistake. This pattern is the first thing I teach my students when they ask me questions. If you ask your questions through this pattern, your probability of getting an answer increases.

What Do You Want To Do?
What did you do?
What happened?
What did you expect to happen?

It's the perfect template for you to place your question in and divide it into. Before you ask your question, if you answer these questions, fill them in, and paste examples from the codes you have written, there is almost no chance that you will not get an answer to that question. Now let's fit the above question into this pattern.

What I want to do: I want to send the X information from the form filled by the user to another service via Post.
What I did: I wrote a method called Y for this and as you can see below, I think it looks right.
What happened: the information does not go, I guess the method does not work… XX error appears on the console.
What did you expect to happen: The information from the X form should have been sent to the service I wanted via this method when the submit button was pressed.
The question has become much clearer. In fact, the answer to this imaginary question has started to form in my head, I think you wrote a method, but it seems like you forgot to trigger it somewhere.

What inexperience! While I pride myself on answering the question you asked in my own fantasy world, I say you should read the following guide.

http://www.catb.org/~esr/faqs/smart-questions.html

Asking the right question is the key to getting the right answer…