DEV Community: Theodora Cristea

Rappelo was launched: how we help solopreneurs and small businesses❗

Theodora Cristea — Mon, 23 Feb 2026 16:36:25 +0000

Intro

Hey everyone!🥰
Lately, I’ve been working closely with my co-founder, @alexandru-ene-dev, on a project born from a simple observation: for any small business or solo-operator, the inbox can easily become the place where opportunities die quietly. Not because they don’t care. Not because they don’t want to reply. But because they’re busy doing the actual work!

Rappelo is Live!

Why did we build Rappelo❓

When you're responsible for running a business, you inevitably take on multiple roles to keep everything moving. Even during moments of deep focus or important meetings, you want to stay in control and be the first to respond to a client. However, operational reality often gets in the way, the intention to reply "right after I finish this task" frequently turns into an unintentional oversight.

The Real Problem

We’ve noticed that most businesses reply hours or even days later. Not because they don't care, but because they are busy doing the actual work. Customers tend to choose the first business that responds. They go with whoever gives them attention while their interest is at its peak. If you let more than 30 minutes pass, the chances of closing that deal decrease considerably.

Every minute of waiting reduces the probability of a sale or a booking. We didn’t build Rappelo to "hunt" people, but because we want to be that first hand reached out. We want to help you to be the most helpful and prompt partner for your customers, showing them that you value their time from the very first second.

More than just a notification

Email wasn't built for speed; it was built for asynchronous communication whenever you have time, but Rappelo is built for now. While inboxes get cluttered and CRMs become too complicated, we wanted to create a safety net that keeps you focused without pulling you out of your workflow.

Rappelo helps you capture the lead, gives you a nudge if you forget to reply, and helps you contact potential clients without losing track of a single one. It’s a simple lead recovery tool that focuses on speed:

Fast Onboarding: 60 seconds onboarding
Instant Alerts: Know the second a lead hits your site
Snooze Alerts: Remind me in 10, 30 or 60 minutes
Neglect Detection: A daily nudge if a lead hasn't been contacted
Simple Dashboard: View lead status and follow-up performance analytics
Zero Complexity: No complex CRM features
Free Trial: You have 14 days free trial. No credit card required. Cancel anytime

Rappelo is officially live!

We hit the launch button on Product Hunt. To be honest, we aren't at the top of the leaderboard, but for us, today is about starting the conversation with our first 50 Founding Members who resonate with this problem.

If you have a moment to take a look at what we've built, we would truly appreciate your support on our Product Hunt page and beyond. An upvote or a short comment would mean a lot to us and help more people discover Rappelo.

Thank you so much for reading and spending your valuable time with this article.❤️ We're excited to hear your thoughts, and we’d love to have you along for the ride.

Links:
Website Rappelo
Product Hunt
Linkedin

The Developer's Safety Net - Introduction to TypeScript

Theodora Cristea — Mon, 01 Dec 2025 12:58:31 +0000

Hey everyone!👋
When developers hear about TypeScript for the first time, the same doubts, questions and confusion always show up. And that's completely normal, TypeScript can seem complicated at first. It might even feel like you're writing extra code compared to plain JavaScript, or that your code is already clear enough without it.

But in reality, TypeScript is a tool that helps us write safe, cleaner, and more understandable code.
Think of TypeScript like walking on a tightrope with a safety net🙃(compiler). If you make a mistake, the net(TS) catches you instantly and tells you exactly where things went wrong, long before the audience(your users) ever sees a problem.

JavaScript on the other hand, is like walking that tightrope without a safety net, you move fast, but even a tiny mistake(a comma, a misspelled method, an unexpected type) can bring your whole program crashing down at runtime.

If you're already using TypeScript, your code is in good hands👏, and hopefully this article will reinforce why adopting it was the right decision!
If you're not using TypeScript yet but you're thinking about introducing it in the future, I hope this article helps you make a confident choice!

In this article, we will talk about:

What TypeScript actually is?
TypeScript or JavaScript!?
Should you learn TypeScript or JavaScript first?
Why TypeScript is worth using?
What to watch out for when learning TypeScript?

1. What TypeScript actually is?

TypeScript is a superset of JavaScript, meaning it's an extended version of JavaScript. This means that any valid JavaScript code is also valid TypeScript code, so it's not an entirely new language!

In other words, JavaScript is a flexible language but lacks strict checks, while TypeScript is still JavaScript, just enhanced with a static type system. This helps us avoid mistakes before we even run the code by telling the program exactly what kind of data we expect (number, string, object...).

It's like installing an alarm system in our code that warns us ahead of time: Careful something doesn't match here!⚠️

2. TypeScript or JavaScript!?

We often fall into the trap of comparing TypeScript with JavaScript, as if the two were competitors fighting for the same spot. But this is actually the wrong way to look at it. TypeScript shouldn't be seen as something opposite to JavaScript, it should be seen as a tool for JavaScript, something that works alongside it, enhances it, and never replaces it.

The reason we tend to compare the two is because we assume TypeScript is another language trying to do what JavaScript already does. But TypeScript doesn't replace JavaScript, it builds on top of it.

Think of JavaScript as the engine of a car, powerful, capable, and essential. TypeScript is not a different engine. It’s more like adding navigation, sensors, and safety features. You’re still driving the same car, but now it guides you, warns you, and protects you from mistakes before they happen.

So the right mindset isn't JavaScript OR TypeScript, but JavaScript WITH TypeScript! JavaScript runs the program. TypeScript helps us write it better.

Once you start using TypeScript, your perspective shifts. You stop seeing rivalry between them. It becomes clear: collaboration, not competition. An upgrade, not a replacement!

3. Should you learn TypeScript or JavaScript first!?

As we've discussed, it should be pretty clear by now that you should learn JavaScript first. Why❓Because if you don't understand at least the basic concepts of JS (variables, functions, objects, async, the DOM, and so on), TypeScript will feel confusing and difficult to use. Without a solid foundation in JavaScript, you have nothing to apply TypeScript's safety features to.

4. Why TypeScript is worth using?

Large companies and development teams use TypeScript to solve real problems and save valuable time. Some of the biggest benefits of TypeScript include:

→ Early error detection: more than 80% of common JavaScript errors are caught by the TypeScript compiler before we even run the code. This means less time spent debugging and more time building new features.
→ Increased productivity (IntelliSense): TypeScript gives us a far better coding experience in our editor (especially in VS Code).
→ Smart autocomplete: it knows exactly what properties an object has and gives precise suggestions.
→ Easy navigation: you can click on a function and instantly see its structure and definitions.
→ Easier teamwork:
Everyone on the team can clearly see what shape the data has, what parameters are required, and what can or cannot be null. This drastically reduces misunderstandings and mistakes.
→ Easier to maintain: TypeScript helps keep order and consistency in a codebase that has grown significantly, making scaling and refactoring far more manageable.

5. What to watch out for when learning TypeScript?

TypeScript is an amazing tool, but it also comes with some responsibilities that we don't really have in plain JavaScript. When learning it, we need to be mindful about what our code is actually doing and what types of data you expect.

→ We have to think about types:
In JavaScript, we can often get away with writing code without worrying too much about the type of a variable. In TypeScript, we are expected to be explicit about what our variables, functions, and objects are supposed to hold.
For example, a variable is a string or a number? TypeScript wants us to define it. This is great for catching mistakes, but it also means we need to understand our own code clearly.

→ TypeScript won't magically fix bad logic:
Just because we're using TypeScript doesn't mean our code is automatically correct. TS can warn you about type mismatches, but it can't know the intended behavior. We still need to understand what our functions are supposed to do and how our data flows.

→ Be careful with any:
The any type is like turning off TypeScript's safety net. It's useful for experimenting, but relying on it too much defeats the purpose of TypeScript. Learning TS means learning to avoid any whenever possible and embrace proper types.

→ Errors are our friends:
When the compiler complains, don't ignore it. TypeScript is designed to catch problems early, not annoy us. Paying attention to its warnings will save us hours of debugging later.

Learning TypeScript isn't just about syntax. It's about understanding our code deeply and being explicit about the shape of our data. The more we practice thinking in terms of types, the safer and more maintainable our code becomes!

Conclusion❤️

If you're already using TypeScript, I can safely say you're a professional bug fixer!😂🤗
And if you're thinking about trying TypeScript, especially if you're still wrestling with bugs hiding across your application, I hope this article gave you the confidence to take your first steps into it. Every developer grows by learning new tools, and TypeScript is definitely one that will make you stronger.

If you're just getting started, take it one step at a time, and remember, mastering TypeScript is a long-term investment that truly pays off.
Keep experimenting, keep learning, and allow yourself to make mistakes, TypeScript is watching you! 😂🙃

Thank you for your time, I’ll be back soon with more TypeScript articles. If you enjoyed this post, learned something new, or if it brought back a smile thinking about your first doubts with TypeScript, don't forget to like the post, leave a comment, and to follow me!
I would really appreciate it! Happy reading!🥰

From localStorage to Database: Understanding the MongoDB Structure❗

Theodora Cristea — Wed, 19 Nov 2025 05:55:18 +0000

Intro

Hey everyone!🤗 If you are a developer who is just starting to work with databases, or perhaps you already know the basics and are looking for a recap or a more in-deph understanding, I hope this article will help you.
When I learn something new, I like to dig deeper and understand the underlying logic to ensure everything is clear. That's why I have structured this article starting from the NoSQL fundamentals all the way to the internal data storage mechanisms, concentrating on the why behind the database. So, I wish you happy reading!🥰

In this article, we will study:

1. Where we Started: The SQL World

When we work with Relational Database like MySQL or PostgreSQL, our data lines up neatly in those perfectly organized tables. We have to make sure every single row follows a rigid column blueprint, decided right from the start. If we ever need to switch up that structure, we basically hit the brakes, tackle complex changes, and cross our fingers that all the existing data still fits.
We got consistency and logic out of this, sure, but as our apps kept scaling, that stiffnes became a real bottleneck for moving fast.

2. The NoSQL story: Not Only SQL

When it comes to NoSQL databases, you might have heard that it means No SQL, but let's clear things up: it's not a total war against SQL! The correct and modern interpretation is Not Only SQL❗

Why 'Not Only SQL'❓

Because we relize that SQL is a fantastic certain tasks (where strict relationship and consistency are vital), today's modern applications (social networks, gaming, websites) demand speed and flexibility. NoSQL is a supplement, an alternative that allows us to choose the right tool for the right job. We aren't giving up on SQL, we're just adding more powerful to our toolkit.

3. From localStorage to Database

Among the many types of NoSQL databases, MongoDB falls in to the Document-Oryented category.

Imagne no longer storing data across separate rows and columns. Instead, you store a complete record, for example, a user profile with all their addresses, orders, and preferences, in a single package called a Document.

Document:

→ The Document is the basic building block. It looks exactly like a JSON (JavaScript Object Notation) object, but, technically speacking, MongoDB uses BSON (Binary JSON). Why BSON❓ Because it's a faster binary format that also includes data types that simple JSON dosen't have (like date/ time values).

→ All these Documents (which, note, do not have to look identical) are grouped into a Collection, a kind of folder that replaces the old tables. To get an idea, we can think of documents as the value stored in localStorage, but they are much more powerful than a simple string value in localStorage❗

→ The Document is the smallest and most important unit of data in MongoDB, being the complete package of information that offers tremendous flexibility by allowing:

→ Storing nested objects,
→ Storing lists,
→ Direct storage of complex data types (such as Date/Time).

Here we have a Document:


{    // unique ID 
  "_id": ObjectId("61a5c6f0e8f0b7c4d5a9b8c7"),
     // complex data type: Date/Time
  "order_date": ISODate("2025-11-18T10:00:00Z"), 
  "status": "Shipped",
      // nested object
  "shipping_address": {
    "street": "10 Example Blvd",
    "city": "London",
    "zip_code": "SW1A 0AA"
  },
    // list (Array)
  "items": [
    {
      "product_name": "Laptop Pro",
      "quantity": 1,
      "price": 1200.00
    },
    {
      "product_name": "Mouse Wireless",
      "quantity": 2,
      "price": 25.50
    }
  ]
}

Colection:

→ If a Document is the equivalent of an individual record (like a complex value stored in localStorage or a row in a SQL table), the Collection in MongoDB is the folder that holds all those records together.

→The Collection is the conceptual equivalent of a Table in a relational (SQL) database. Unlike a SQL table, where all rows must adhere to the same structure (the same columns), Documents within a MongoDB Collection can have different structures (dynamic schema)❗

→ A small example, In MongoDB, we have a Database named school. This Database contains two Collections: students and teachers.
,

→ 1. The students Collection contains two documents:

  {
    first_name: "Alice",
    last_name: "Smith",
    age: 16,
    grade: 10,
    enrollment_date: new Date("2024-09-01T00:00:00Z"),
    courses: ["Math", "Physics", "English"] // Array
  },

  {
    first_name: "Bob",
    last_name: "Johnson",
    age: 17,
    grade: 11,
    enrollment_date: new Date("2023-09-01T00:00:00Z"),
    contact: { // nested object
      phone: "555-1234",
      email: "bob@school.edu"
    }
  }

The teachers Collection contains two documents:

 {
    title: "Mr.",
    last_name: "Davis",
    subject: "Mathematics",
    tenure: true,
    phone: "555-5678"
    class_count: 5
  },

  {
    title: "Ms.",
    last_name: "Garcia",
    subject: "History",
    class_count: 4,
    office_hours: { // Nested Object
      day: "Wednesday",
      time: "2:00 PM - 3:00 PM"
    }
  }

Flexibility by Nature:

→ One user document might have a phone field, while the next one might not. This dynamic schema is the main reason developers choose MongoDB when dealing with data that evolves rapidly.

→ Therefore, MongoDB allows us to model data naturally, like objects (documents), and these objects are managed efficiently within logical groups called Collections.

The Essential Field: `_id`

→ Every Document must have a unique field named _id. This field serves as the Primary Key for the document (just like the unique ID in a SQL row).

→ If you don't specify an _id yourself when inserting data, MongoDB automatically generates one for you using a special data type called ObjectId. This ObjectId is guaranteed to be unique and even includes a timestamp, giving you information about the exact moment the document was created.

4. Basic CRUD Operations:

(Assuming the MongoDB server is installed and mongosh is ready, we can now connect to the database to see how we create collections and documents)...

→ CRUD operations represent the four basic functions that underlie any persistent data storage system. In the context of a database (such as MongoDB, although the terms apply generally), these are the methods through which we interact with Documents within a Collection.

1. Create: `insertOne()`/`insertMany()`

→ The Create operation adds new documents into a collection.

insertOne(document): this method is used to insert a single new document into the collection.

  //this will add a new document in 
  //teachers collection
db.teachers.insertOne({
  title: "Mr.",
  last_name: "Jack",
  subject: "Geography",
  tenure: false,
  phone: "555-5566"
  class_count: 6
})

insertMany([document1, document2, ...]): this method is used to insert multiple documents into the collection with a single command. The argument is an array (list) of documents.

  //this will add two documents in 
  //students collection
db.students.insertMany([
   {
     first_name: "Lea",
     last_name: "Casy",
     age: 17,
     grade: 10
   },
   {
     first_name: "Jessy",
     last_name: "Smith",
     age: 18,
     grade: 10
   }
])

2. Read: `find()`/`findOne()`

→ The Read operation retrieves documents from the collection based on filtering criteria.

findOne(query): this method returns the first document that matches the filtering criteria specified in the query object. It is ideal when you know you need a single document, for example, based on a unique ID. If no query is specified (i.e., it is empty: {}), it returns the first document found in the collection.

//find the first student with name 'Lea'
db.students.findOne({ first_name: 'Lea' })

find(query): This method returns a cursor to all documents that match the specified filtering criteria. If the query object is empty ({}), it returns all documents in the collection.

//return all of documents from students colection
db.students.find()

//find all students whose age is greater than 16
db.students.find({ age: {$gt: 16 }})

3. Update: updateOne()/updateMany()

updateOne(filter, update_operation): Updates the first document that matches the given filter.

//finds the document with `first_name 'Jessy'` and
// sets the new grade to false.
db.students.updateOne(
  { first_name: 'Jessy' },
  { $set: { grade: false } }
)

updateMany(filter, update_operation): Updates all documents that match the given filter.

// It selects documents only if the field contact is absent. ($exists: false)
// and add the 'contact' object with default phone and email values.
db.students.updateMany(
  // 1. FILTER: Select documents missing the 'contact' field
  { contact: { $exists: false } }, 

  // 2. OPERATION: Use $set to add the new 'contact' object
  { 
    $set: { 
      "contact.phone": false, 
      "contact.email": "default@school.com" 
    } 
  }
);

→ The Basic $set Operator: This is the most common update operator. It specifies which fields should be modified and what their new values are. It either replaces the value of an existing field or adds a new field if it doesn't exist.

Basic Syntax: In update calls, the update operation part will often look like this: {"$set": {"field_name": "new_value", "another_field": 123}}.

4.Delete: deleteOne()/deleteMany

→ The Delete operation removes documents from the collection.
deleteOne(filter): deletes the first document that matches the specified filter.

// delete the first student found whose first name is 'Lea'.
db.students.deleteOne({ first_name: "Lea" })

deleteMany(filter): deletes all documents that match the specified filter.

// delete all students who are currently in grade 10.
db.students.deleteMany({ grade: 10 });

Caution❗If you use deleteMany({}) (an empty filter), you will delete all documents in the collection. Always be careful when using delete operations.🙃

Delete a colection: db.students.drop(),
Delete a database: first select the database use school, then we delete it db.dropDatabase()

Conclusion ❤️

While I haven't delved into the specifics of working tools, my goal for this first article was to provide a short but solid introduction to the fundamental of MongoDB.

There is a lot to explore in the world of MongoDB, but I believe these basics are essential. If you understand how data saving and retrieval work in localStorage, you can draw a useful analogy to better grasp collections within a database.🙃
I will be back soon with more detailed posts on the subject, further deepening the concepts we've learned. I hope this introductory guide was helpful!

If you enjoyed this article, learned something new, or if it brought back a smile thinking about your first attempts in MongoDB, don't forget to like the post or leave a comment! Thank you so much for reading and spending your valuable time with this article. I look forward to connecting with you in the next one! Happy codding!🥰🤗

Frontend to Backend: From Vite to Express❗

Theodora Cristea — Tue, 28 Oct 2025 19:19:16 +0000

Intro

Hey everyone!🤗 If you're a beginner who's just started learning the backend, or maybe you already know the basics but want a deeper understanding of the logic behind servers, routing requests and all those fundamentals concepts, I truly hope this article helps you out.🥰

It's totally normal to feel confused at first or not to grasp everything immediatly, you'll figure it out eventually at the right time! Perhaps this article will clarify things, or maybe it will just confirm what you already know!

We will discuss the following concepts:

Routing: Frontend vs Backend
From Source to Server
Development vs Production: More Than Just a Command
Order Matters: Handling Critical Paths in Express

Routing: Frontent vs Backend

Routing means deciding which piece of code or which page to return when a user accesses a specific URL (a path, or "route"). Here lies the first major difference between the two worlds.

Frontend Routing (Vite, React Router)

When we work with a modern frontend framework (like React with Vite or Create React App), we don't handle the routing of static files:

→ The Dev Server is Smart: Vite's development server is designed to do one thing: help us code fast. It knows how to read our source files (those in src/) and serve them automatically under the corresponding URLs.

→ Automatic Routing: If our HTML or React code refers to /styles/main.css, the Vite server knows immediately where to find the physical file (in its memory or the file system) and sends it instantly to the browser. We don't write special code for this❗

→ Focus on Application Logic: Using libraries like React Router, we only focus on the application logic (e.g., "If the URL is /profile, display the Profile component"). This routing happens in the browser, after the JavaScript files have been loaded.

Manual Routing in the Backend (Express.js)

Express.js is just a minimal framework. It makes no assumptions and has no built-in "magic."

→ Routing is Manual: Once we put Express.js in charge as the main server, we must explicitly tell it what to do for every request that reaches it.

Do we want the POST /api/login request to verify the password in the database❓ We must write app.post('/api/login',...).

Do we want the GET /api/users request to return a list of users❓ We must write app.get('/api/users', ...).

→ Ignorance of Static Files: Without instructions, if it receives a request for /main.css, Express doesn't know this is a static file. It will look for an API route or rendering logic. Since it doesn't find one, it implicitly returns 404 Not Found.

When starting out, the Vite Development Server performs silent magic, it's automatically handling all the routing and serving of our static files (like CSS and images) directly from memory.

However, when we introduce Express.js, the magic stops. Express is ignorant and requires explicit instructions. We must manually define our API routes (app.get('/api/data')) and, most importantly, we must use express.static() to manually tell Express: "This is where you can find all the static files you need for the web page." Without this manual step, our CSS and JavaScript files will be invisible to the server, resulting in broken pages❗

From Source to Server

Static Files in Development:

During development, when we run npm run dev in our React project:

→ No Physical Folder: The Vite server reads our files (.jsx, .css) directly from the src/ directory and keeps them in RAM (memory). It does not create a physical folder with compiled files.

→ Speed: Any change we save is instantly transmitted to the browser via HMR (Hot Module Reloading), making the coding experience fluid.

→ Not Production Ready: Although fast, this mode is not stable, secure, or optimized to be accessed by thousands of real users on the internet.

From src to dist:

When and Why Do We Compile❓ Before publishing the application (moving to Production), we must compile the code:

→ The Command: npm run build.
→ Optimization: This command takes all our source files (React, CSS, etc.), minifies them (makes them much smaller), concatenates them (puts them into fewer bundles), and optimizes them for maximum loading speed.

→ The Result dist: All these optimized files are put into a new, physical folder, usually called dist or build. This folder contains the final, static version of the frontend, ready to be served.

Enter `express.static()`:

→ How Do We Serve the dist Folder❓ Now that we have the optimized dist folder, we must tell Express (the backend) that this is the folder it needs to serve publicly:

→ The Solution is express.static(): This line of code is the instruction we give the Express server:

// in production, Express serves the frontend's 'dist' folder
app.use(express.static(path.join(__dirname, 'client/dist')));

→ What It Does: Whenever an HTTP request reaches the server and does not match an API route we defined (e.g. doesn't start with /api), Express looks in the dist folder! If it finds a file matching the requested URL (e.g., /style.css), it sends it immediately to the client and stops the routing process❗

Development vs Production:

→ If we have seen the command npm run dev used in both our frontend (React) and our backend (Express) project directories, we might think they do the same thing. They don't❗ This is a critical distinction, especially when thinking about security and performance.

→ The Dual npm run dev: Two Servers, Two Purposes

When we talk about Development Mode (Dev) and Production Mode (Prod), we are describing the state and purpose of our running code.

Development Mode (our workbench):

Development Mode is our workbench, it's optimized for speed and debugging.

→ Purpose: the sole goal is to facilitate rapid coding, testing, and debugging.
→ Frontend Setup: the server runs the Vite Dev Server on one port (e.g., 5173).
→ Backend Tooling: we use tools like nodemon to automatically restart the server the moment we save a change.
→ Errors: errors are loud and detailed (stack traces) and are printed directly to your console, helping you fix issues instantly.
→ Optimization: files are served as-is, with minimal optimization, as file size and speed aren't the primary concerns.

Production Mode (the live public server)

Production Mode is the final, optimized version delivered to the public, it's built for stability and security.

→ Purpose: the goal is to deliver a stable, fast, and secure experience to the public.
→ Frontend Setup: the frontend code is first built (compiled and minified) and then served by the single Express server on its designated port (e.g., 3000).
→ Backend Tooling: we use highly optimized process managers (like PM2) to keep the server running continuously and robustly.
→ Errors: errors are logged internally but are never shown to the public user, preventing security leaks❗
→ Optimization: files are heavily minified and aggressively cached for maximum performance and faster loading times for all users.

Security Risks:

Why we don't run development mode in production❓
Running your Express server in Development Mode on a live, public server is a major security flaw and is strongly discouraged.

→ Security Leaks: Development errors often include sensitive data, such as file paths on your server, environment variables, or even glimpses into your database structure. Revealing this information to an attacker is a severe vulnerability❗

→ Performance: Dev mode is built for convenience, not speed. You will experience slow response times, poor resource management, and limited scalability under real user load.

→ Stability: Tools like nodemon are meant to restart your code whenever you save a change. This behavior is unpredictable and highly unstable for a public-facing application that needs to run 24/7❗

Order Matters: Handling Critical Paths in Express

Now, let's look at the crucial process of setting up our routes and middleware in the correct order to ensure Express handles all requests correctly.

The Role of Middleware: app.use()

In Express, a Middleware is simply a function that executes during the request-response cycle. It has access to the request object req, the response object res, and the next function next in the cycle.

→ app.use(middleware): This method is primarily used to register middleware. It executes the provided function for ALL HTTP methods (GET, POST, etc.) and for ALL paths (unless we specify a path prefix).

→ The Golden Rule: Middleware executes in the exact order they are defined in our code. Once a middleware sends a response (e.g., res.send('Hello')), the cycle stops, and no subsequent middleware or route handlers are executed❗

Example Order of Flow:

app.use(cors)
app.use(express.json)
app.use('/api', apiRouter)
app.use(express.static(dist_path)) <- This is the critical separation point❗
... other routes ...

The React Router Trap:

Why We Need app.get('*')❓This is the final piece of the puzzle that links our backend logic to our frontend application.

→ The Purpose: the app.get('*') route is the Catch-All Handler. It uses the wildcard * to match any GET request that hasn't been handled by any middleware or route defined before it.

→ The Scenario: when a user types a direct link like mysite.com/profile into their browser, the server sees a request for /profile.

Express checks the API routes (e.g., /api). No match❗
Express checks express.static() for a file named profile. No match.❗
The request falls to app.get('*').

→ The Solution: we tell Express to simply serve the main application file (index.html) for any unmatched path.


app.get('*', (req, res) => {
    // we tell Express: "Send the HTML file and let React Router handle the URL."
    res.sendFile(path.resolve(FRONTEND_BUILD_PATH, 'index.html'));

});

→ Result: The browser loads index.html, React takes over, and React Router reads the /profile URL and displays the correct component, making the single-page application experience seamless❗

Conclusion❤️

If you’re a beginner in backend development and these things didn’t make sense right away, don’t be disappointed, they can definitely be confusing at first. I think we’ve all had these questions when we were just starting out... I know I sure did❗ 🙃

The main challenge is that we need to shift our mindset and the way we think, from the automatic, in-memory serving of a frontend tool like Vite, to the more manual and structured routing approach of Express.

I hope this article helps you out, or maybe reminds you of the struggles you faced at the beginning of your backend journey.🤗
I’m really curious how many of us have gone through the same confusion at first, leave me a comment if backend development gave you a hard time too! I’d love to know I wasn’t the only one.🤗🥰

Happy reading, and if this article helped you or you found it useful, give it a reaction!🤗

More articles:
Node.js-Steps for building your first server❗
My First Node.js: Mastering the Fundamentals❗

Node.js-Steps for building your first server❗

Theodora Cristea — Wed, 15 Oct 2025 17:42:04 +0000

Introduction

Hello everyone!👋 I’m happy to be back with the second part of my Node.js exploration. After setting up My first Node.js – Mastering the Fundamentals in the previous post, today we’re taking a major step forward by taking the most important steps to create our first server!🥰

By the end of this post, you’ll have the basic knowledge needed to create a simple Node.js server, handle HTTP requests, serve static files, and build a basic API. This foundation will prepare you to build more complex backend applications with confidence.

The concepts we’ll go through:

Understanding the Event Loop
HTTP Module & Create Server: The HTTP Core
Req vs Res Objects
Simple Routing
Loading Files: Serving Static Content
Building a Simple API: API Structure
Middleware: The Middleware Pattern
Cleanup (Middleware & Handlers): Code Organisation
Get Req Body For POST: Handling Data

1. Understanding the Event Loop

Definition

The Event Loop it's the mechanism that make Node.js non-blocking, asynchronous and yet run on a single thread. We can simply say that it’s the traffic manager that decides when and how operations are executed especially those that take time (like reading files, making HTTP requests...).

The logic is the following:

→ Node.js receives a request.
→ If it’s a quick operation (like a math calculation), it’s executed immediately in the main thread.
→ If it's a slow operation (like making HTTP requests) Node.js delegates it to a background thread (libuv thread pool) or the operating system.
→ While the task run in the background, the Event Loop keep processing other requests.
→ When the background task finishes, the result is placed into a queue, and the Event Loop executes it once the main thread is free.

Imagine this as a simple analogy:

(I hope this analogy makes more sense❗)
...You’re a waiter in a restaurant,🙃
→ You (the Event Loop) take orders from customers (requests),
→ The chefs in the kitchen (thread pool) cook the meals (long operations).
→ You don’t stand around waiting for one meal, you serve other tables meanwhile.
→ When the chefs finish, they notify you, and you deliver the food. This way, no customer gets stuck waiting, and everything runs efficiently.

Simple code example:

console.log("Start");

setTimeout(() => {
  console.log("Timeout done");
}, 2000);

console.log("End");

//Output: 
Start
End
Time done

2. HTTP Module & Create Server

The http module is a native, built-in Node.js library that provides the core functionalities for creating HTTP servers. The essential method is http.createServer(), which set up our server. This method accepts a callback function that executes every time a request received at the server, providing access to the req (request) and res (response) objects.

Simple Analogy

We can say that our server works as the receptionist at a hotel.🙃

→ import http from 'http': This is like hiring the receptionist and equipping them with the Instruction Manual (the HTTP Module) on how to communicate with clients.
→ http.createServer((req, res) => { ... }): This is setting the receptionist at the desk and establishing the fundamental rule: "Every time a client (req) makes a request, you must give them a response (res)."
→ server.listen(3000): This is like installing a telephone(on a specific port, like extension 3000) that clients can use to call and access your services.

Simple code example

const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello World!');
});

server.listen(3000, () => {
  console.log('Server is running on http://localhost:3000');
});

http.createServer() → creates the server,
req → represents the incoming request,
res → represents the outgoing response.

3. Req vs Res Objects

The `req` (Request) Object Definition:

The req (Request) object is an instance of the IncomingMessage stream created by Node.js every time the server receives an HTTP request. It holds all the information sent by the client, including the HTTP method (GET, POST, etc.), the requested URL path, and the full set of headers.

The res (Response) Object Definition:

The res (Response) object is a Writable Stream through which your server sends data back to the client. Its role is to control exactly what the client receives and how they receive it, allowing you to set the HTTP Status Code, define Headers (like Content-Type), and send the response body.

Simple Analogy

req → represents the request coming from the client.
It’s like a guest walking up to the receptionist and saying what they want:

"I’d like a single room for two nights."
"Can you tell me the check-out time?" 🙃

→ The receptionist (server) receives this request and reads it to understand what action to take.
→ So req = the letter or message from the client to the receptionist.

res→ represents the response the server sends back to the client.
It’s like the receptionist replying to the guest:

"Sure, your room is booked for two nights."
"Check-out is at 12:00 PM."

→ The receptionist uses the information from the request (req) to provide the correct response (res).
→ So res = the response or message from the receptionist to the client.

Simple code:


import http from 'http'; 

const server = http.createServer((req, res) => {
    const url = req.url;
    console.log(`Path requested: ${url}`);

    // we can set the Status Code and Header (using the res object)
    res.statusCode = 200; 
    res.setHeader('Content-Type', 'text/html'); 

    // here we build and send the response body (using the res object)
    res.end(
        `<h1>Hello from Node.js!</h1>
        <p>You asked for the path: ${url}</p>`
    );
});

const PORT = 8000;
server.listen(PORT, () => console.log(`Server running at port ${PORT}`));
// server starts on the specified port

4. Simple Routing

Definition

Routing is simply how your server decides where to send an incoming request. Think of it as looking at the address (the URL path) and the goal (the HTTP Method, like GET or POST) to figure out which piece of code (handler) should run to create the correct response.

Simple Code


import http from 'http'; 

const server = http.createServer((req, res) => { //create server
    const url = req.url;
    const method = req.method; //could be GET/POST/PUT/DELETE...

    //here we set default headers for a standard response
    res.setHeader('Content-Type', 'text/html'); //type html

    // 1. basic routing based on URL
    if (url === '/') {
        res.statusCode = 200;
        res.end('<h1>Home Page!</h1>');
    } 

    //2. we check if the route is 'api/users and the method GET
    else if (url === '/api/users' && method === 'GET') {
        res.statusCode = 200; //request was successful,
        res.end('<h1>User List</h1><p>GET request received.</p>');
    } 

    // 4. we handling 404 if is not exist
    else {
        res.statusCode = 404; //not found
        res.end(
          '<h1>404 Not Found</h1><p>The requested resource does not exist.</p>'
);
    }
});

server.listen(8000, () => {
    console.log('Server running at port 8000');
});

5. Loading Files

Definition

→ Serving Static Content means sending files that don't change (like your main index.html, style sheets, images, or client-side JavaScript) directly to the client.

→ For these type of files, native Node.js uses the built-in fs (File System) module to read the file's contents from the disk. It's important to set the correct Content-Type in the response header so the browser knows how to render the content (e.g., as HTML, not plain text).

Simple Code

import http from 'http';
import fs from 'fs/promises';
import { fileURLToPath } from 'url';

//__dirname gives the directory of the current module
const __dirname = fileURLToPath(new URL('.', import.meta.url));

//create server
const server = http.createServer(async (req, res) => {
    if (req.url === '/') {
        res.setHeader('Content-Type', 'text/html'); 

        try {
          const data = await fs.readFile(`${__dirname}index.html`, 'utf8');

          res.statusCode = 200;
          res.end(data);

        } catch (err) {
            console.error('Error loading index.html:', err);
            res.statusCode = 500; // Internal Server Error
            res.end('<h1>500 Server Error Loading File</h1>');
        }
    } else {
        // ... (other routing logic)
        res.statusCode = 404;
        res.end('<h1>404 Not Found</h1>');
    }
});

server.listen(8000, () => {
    console.log('Server running at port 8000');
});

6. Building a Simple API

Definition

A well-structured API isn't just nice to look at it's intuitive to use. Think of your endpoints as the nouns (resources) in your application, and the HTTP methods as the verbs (actions).

→ When it comes to structuring your API, my advice is to use plural nouns in lowercase for your resource paths. Avoid putting verbs directly in the endpoint path, the HTTP method itself already **describes*8 the action.

For example:

Wrong: GET /get-all-users
→ Correct: GET /users

Wrong: POST /create-post
→ Correct: POST /posts

Our API should be predictable. When someone visits /users, it should clearly indicate that they're dealing with the user resource. This consistency makes our API easier to understand and more RESTful.

Simple Code

import express from 'express';

const router = express.Router();

// GET /posts
// the purpose: receiving a list of all posts 
router.get('/', (req, res) => {
    // Logic to fetch all posts from the database
    res.json({ message: "Fetching all posts" }); 
});

// GET /posts/:id
// the purpose: receiving a specific post by ID 
router.get('/:id', (req, res) => {
    // here we extracting the resource ID from the URL
    const postId = req.params.id; 

    // logic to fetch post 'postId'
    res.json({ message: `Fetching post ${postId}` });
});

// POST /posts
// the purpose: create a new post
router.post('/', (req, res) => {
    // Logic to create a new post using req.body
    res.status(201).json({ message: "Post created successfully" });
});

export default router;

7. Middleware

Definition

→Middleware is basically a function that runs between the time a request reaches our server and the time a response is sent back. It has access to the request (req), the response (res), and a next() function that decides what happens next.

→If the middleware doesn’t finish the request itself, it calls next() to let the next piece of code handle it.

Simple code

import express from "express";

const app = express();

  //the middleware function runs before every request handler
const logger = (req, res, next) => {
  // here we log the current time, HTTP method, and requested URL
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);

  // we call next() to pass control to the next middleware or route
  next();
};

//  and we apply the middleware to all routes in the app
app.use(logger);

// Example route, handles GET requests to /users
app.get("/users", (req, res) => {
  // just send a simple text response
  res.send("List of users");
});

// Start the server on port 8000
app.listen(8000, () => console.log("Server running on port 8000"));

8. Cleanup (Middleware & Handlers):

→Code organization is about how we structure our project so it’s clean, readable, and easy to maintain. It means separating our code into logical parts, so that routes, middleware, and core logic don’t all live in the same file.

The logic is the following:

→ Separate responsibilities - each file or function should do one thing well.
→ Keep routes simple - no business logic directly inside routes.
→ Use folders for structure (routes/, controllers/, middleware/, etc.).
→ Handle errors properly using a global error handler.
→ Name clearly - your folder and file names should describe their purpose.

Simple code

app.js file

import express from "express";
import userRoutes from "./routes/users.js";
import { errorHandler } from "./middleware/errorHandler.js";

const app = express();
app.use(express.json());

// here we use the user routes
app.use("/api/users", userRoutes);

// here we have a global error handler
app.use(errorHandler);

app.listen(3000, () => console.log("Server running on port 3000"));

routes/users.js file

import express from "express";
import { getUsers, createUser } from "../controllers/users.js";

const router = express.Router();

// our routes should be simple, just map endpoints to controller functions
router.get("/", getUsers);
router.post("/", createUser);

export default router;

9. Get Req Body For POST

→ Handling the request body means reading the data a client sends to our server, usually when creating or updating something (like POST, PUT, or PATCH requests...).
→ This data often comes as JSON or URL-encoded form data, and we need to parse it so our code can use it.

Key Points we should understand

→ Raw data first: When the server receives a request, the body comes in as a raw stream, it’s just a bunch of bytes.

→ Parsing is required: we need middleware to turn that raw data into something usable, like a JavaScript object.

→ Content-Type matters: the client must send the correct Content-Type header (e.g., application/json) so the server knows how to parse the data.

My advice use built-in framework parsers (like express.json() in Express) early in your application's setup to automatically populate the req.body property.

Simple code

import express from "express";
const app = express();

// middleware to parse JSON bodies
app.use(express.json());

// POST route to create a new user
app.post("/users", (req, res) => {
  const { name, email } = req.body; // req.body already parsed

  // we us a basic validation
  if (!name || !email) {
    return res.status(400).json({ error: "Name and email are required" });
  }

  // here we simulate the creation of a new user
  const newUser = { id: Date.now(), name, email };
  res.status(201).json({ message: "User created!", user: newUser });
});

app.listen(3000, () => console.log("Server running on port 3000"));

→ Here express.json() parses incoming JSON requests automatically.
→ req.body now contains a normal JavaScript object.
→ By doing this, the route handler can read, validate, and use that data directly.

Conclusion ❤️

I hope this post is helpful and maybe even helps improve your understanding of Node.js fundamentals.🤗 I haven’t gone into too much detail, but I’ll be back with more Node.js content in future posts.

If you enjoyed this post, found it helpful, or it just sparked your curiosity, feel free to leave a comment or give it a reaction, I’d really appreciate it!🤗

Happy coding, and see you in the next post!

My First Node.js: Mastering the Fundamentals❗

Theodora Cristea — Fri, 10 Oct 2025 18:10:02 +0000

Intro

Hey everyone! Lately, I've been focusing heavily on backend development, and I finally decided it was time to dive into Node.js. I'd been putting this moment off for a while, and now it's here❗

Honestly, I used to feel a bit intimidated when thinking about backend concepts-things like creating servers, working with databases...😳and general infrastructure.I wasn't sure what Node.js had in store for me...until just a few days ago.🤗

To my surprise, I genuinely love it! It's quite accessible and logical in how it operates, especially since I already have JavaScript knowledge.

There's still a vast amount to learn in the backend world, but I'm not focused on achieving perfection; I'm focused on the progress itself. The prospect of implementing these acquired skills in future projects is highly motivating, and I'm keen to move forward!

Wish me luck on this journey!😬 Hopefully I don’t break any server while learning Node.js!😂

On a serious note, here’s what we’ll cover in detail in this first section:

1. Setting the Stage: Installation, REPL, and package.json
2. Modularity: Understanding Modules (CommonJS vs. ES Modules)
3. The Workflow: NPM Scripts, Nodemon, and .gitignore
4. Security Baseline: Environment Variables and the .env file

What is Node.js?

Node.js is a JavaScript runtime built on Chrome's V8 engine that allows you to run JavaScript on the server side. Unlike traditional JavaScript, which runs in the browser, Node.js enables you to build server-side applications, manage files and databases, create APIs, and much more using the same language.

Node.js is commonly used for server-side and back-end development, including:

➤ Web servers and real-time applications,
➤ REST or GraphQL APIs for communication between front-end and back-end,
➤ Database management (MongoDB, PostgreSQL, MySQL, etc.)
➤ Automation and server-side scripts,
➤ Microservices and scalable applications, thanks to its asynchronous, event-driven architecture.

1. Setting the Stage

Before we write a single line of server code, we need to ensure we have the runtime environment installed and that our project is properly initialized!

1.a) Installation:

The very first step is, obviously, getting Node.js into your system.
These commands should display the installed versions, confirming that both the Node.js engine and NPM (Node Package Manager) are ready to go.

node -v
npm -v

1.b) Node REPL (The Instant Playground):

REPL (Read-Eval-Print Loop) is atool for quickly testing a function, new syntax, or a native module without writing and saving an entire file.
test cod:

node
> console.log("Hello, Node.js!")

1.c) package.json:

The package.json is arguably the most crucial file in a Node.js project. It is the identity card of your application.
To create this file, navigate to your project directory and run:

npm init -y

So far, it feels like a simple, familiar cake, right?🤗

2. Modularity

A key component of any robust Node.js project is how code is organized and shared across separate files. Node.js currently supports two major module systems. Understanding the difference is crucial for you!

2.a) CommonJS (CJS) - The Classic

This was the original and long-standing standard system in Node.js.

Syntax: Uses the require() function and module.exports.
Execution: Module loading is synchronous (it stops execution until the module is fully loaded).
Usage: It's the default for files with the .js extension unless otherwise specified.

example:

// exporting module
module.exports = {
  add: (a, b) => a + b
};

// importing module
const { add } = require('./math');
console.log(add(5, 5));

2.b) ES Modules (ESM) - The Modern Standard

ESM is the official JavaScript standard (introduced in ES6) and is now fully supported and recommended in Node.js for new projects.

Syntax: Uses the import and export keywords.
Execution: Supports asynchronous loading and is generally more efficient.
Usage: Requires either the .mjs extension or setting "type": "module" in your package.json file.

// exporting module
export const subtract = (a, b) => a - b;

// importing module
import { subtract } from './math.js';
console.log(subtract(10, 3));

I suggest you be careful when working with modules, ES Modules are the modern standard, but make sure you know what type of module your project uses before importing anything. I actually ran into this myself at first❗🙃

3. The Workflow

These functionalities will help you automate and streamline your workflow, saving time and avoiding repetitive tasks.

3.a) NPM Scripts

Automate terminal commands directly from your package.json.
For example, you can create a script to start the server:

// package.json
"scripts": {
  "start": "node server.js",
  "dev": "nodemon server.js"
}

Then, you run them easily with: npm run start or npm run dev.

3.b) Nodemon(The Automatic Refresher)

Nodemon is an essential development-only NPM package. Why is it crucial❓It automatically monitors changes in your source files and restarts your Node.js server every time you save.
Installation (as a dev dependency): npm install -D nodemon

3.c) .gitignore (Keeping GitHub Clean)

This file is vital for maintaining a clean and secure repository. It instructs Git which files and directories to ignore during a commit.
Must-Ignore: The two most critical items to ignore are the node_modules directory (huge!) and the .env file (sensitive data!).

4. Security Baseline

We will have sensitive information that should never be committed to source control (like GitHub). This includes API keys, database passwords, and specific configuration settings for different environments.This is where Environment Variables come in, example of .env page:

DB_HOST=localhost
DB_PORT=5432
API_KEY=my_super_secret_key_12345

Very important! Remember to always include the .env file in your .gitignore❗ This ensures your secrets stay local and secure.

Conclusion❤️

So far, everything seems straightforward! Of course, I'll continue in the next post with a deep dive into how to create your first own server.

I'm committed to posting my learnings here with all of you, both for those who want a recap and for myself-as they say, you learn fastest by explaining to someone else.

I'm genuinely excited to have stepped into the backend world. It feels like a new beginning and has opened up new paths that really spark my curiosity. If you're reading this, you're either already familiar with Node.js or you're planning to learn it, so be proud of where you are right now. You're doing great, and you're exactly where you need to be! Keep coding!

I highly recommend you check the documentation as well HERE.
Don't overlook the official documentation! Tools and quick searches are perfect for immediate needs, but the documentation is where you'll find the complete, official context necessary for learning more about Node.js.

And if you enjoyed this post, please leave a comment or a reaction❤️! I truly appreciate the gesture and the fact that you took the time to read my work.

Good luck and happy coding!🤗

Build Your Own Infinite Carousel in React (with a Custom Hook)❗

Theodora Cristea — Mon, 15 Sep 2025 00:46:32 +0000

Hey!🥰 It’s been a while since my last post…
No ofcorse, I haven’t quit web development,🙃 and nope, I didn’t go on a long vacation either.🙃 Quite the opposite - I’ve been coding non-stop, 6 out of 7 days. I’ve been busy with a project that I’ll share with you soon, but today I want to show you something smaller but really useful:

➤ How I built a reusable infinite carousel in React, using only a custom hook, a component, and some CSS.
GitHub: Carousel
Demo: Carousel

Why another carousel❓

Carousels are everywhere: online shops, landing pages, portfolios… and let’s be honest, many developers reach for a big library when all they need is a simple slider.

There’s nothing wrong with libraries, but sometimes it’s good to be curious and understand the logic behind them. Building one yourself gives you full control and help you creating your own mini-library.

What does an infinite carousel mean❓

A classic carousel has a beginning and an end. If you reach the last image and click “next,” it either stops or jumps back abruptly. An infinite carousel creates the illusion that the list never ends.
How❓

Clone a few slides and add them to the beginning and end.
When you move too far left or right, instantly reposition the list without the user noticing. This trick gives the user the feeling they can scroll endlessly.
Sounds a bit confusing❓Don’t worry, keep reading and it will all make sense.🥰

Project structure:

I split the logic into two parts:
• InfiniteCarousel component ➤ handles the UI (images, titles, navigation buttons).
• useCarousel hook ➤ handles the logic (clones, index, transitions, auto-slide, resize).
This makes the carousel reusable: you can drop the hook into any React project and use it with any type of content.

The useCarousel hook

The hook accepts a few configuration options:

useCarousel({
  visibleSlides: 4,           // how many slides are visible at once
  gap: 32,                    // spacing between them
  autoSlideInterval: 3000,    // autoplay interval in ms
});

What it does under the hood❓

• Index tracking: ➤ keeps track of the current position with a ref.
• Transitions ➤ moves the carousel with translateX.
• Invisible reset ➤ when you go past the edges, it disables transition, instantly repositions, then continues normally.
• Auto-slide ➤ moves slides automatically, pauses on hover.
• Resize handler ➤ recalculates slide widths when the window size changes.

The InfiniteCarousel component

The UI is quite straightforward:
• ul for the list of slides,
• li for each image,
• two buttons for manual navigation.

Responsive design

With some media queries, the carousel adapts to different screen sizes:
• On mobile → 1–2 slides visible,
• On tablet → 3 slides,
• On desktop → 4 slides.

@media screen and (min-width: 500px) {
  .li-right-tea {
    width: calc(50% - 32px / 2);
  }
}

@media screen and (min-width: 900px) {
  .li-right-tea {
    width: calc(33.33% - 64px / 3);
  }
}

@media screen and (min-width: 1200px) {
  .li-right-tea {
    width: calc(25% - 96px / 4);
  }
}

Visual scheme of the logic

Let’s say we have 8 original slides: A B C D E F G H We want 4 visible at once ➤ that means we clone 4 at the beginning and 4 at the end.

Key positions:

• Start (index = 4) ➤ aligned on the first real slide (A)
Visible: [ A | B | C | D ]
• Going right (next):
You reach index 11 (H).
Next click ➤ index 12 (A clone).
➤ On transitionend, it instantly resets back to index 4 (A real).
• Going left (prev):
You reach index 3 (H clone).
➤ On transitionend, it instantly resets back to index 11 (H real).
The user never sees the*jump* The illusion of infinity is preserved.

Final functionality

• Manual navigation with buttons,
• Auto-slide with customizable interval,
• Pause on hover,
• Invisible reset for infinite effect,
• Responsive (media queries + resize recalculation),
• Reusable (hook works with any type of content, not just images).

Conclusion❤️

Now you have a fully working infinite carousel in React, built from scratch, with no external libraries, and with full control over the behavior.🥰Of course, it can be enhanced with indicators (dots) for progress, animations, and other functionalities! I think building your own mini-libraries in React is worth it. You not only learn how things work under the hood, but you also get the freedom to extend and customize them however you like.

I hope this post helps you!🥰 For me, rewriting it was a great way to solidify my understanding. Let me know in the comments if you have questions or if this was useful for you.
Happy coding!

11 Months as a Self-Taught Developer – What Have I Learned?

Theodora Cristea — Sun, 03 Aug 2025 10:43:56 +0000

Hello everyone!🥰
I haven’t been in this community for long, so like any newcomer, I wasn’t sure exactly what to share in my first posts.
There’s so much to say, you never really know what topic to post about until you place your hands on the keyboard.
So today, I want to share with you what I’ve learned over these 11 months as a self-taught developer.

In the beginning...

• Let me start by saying it wasn’t easy. I didn’t just struggle with the programming languages themselves HTML, CSS, JS, but even my laptop wasn’t very friendly with me at the start. Everything was new. I started by writing my first lines of code in Notepad, manually typing every piece.

• Now I realize how much that helped me understand the syntax, where to place curly braces, quotation marks, commas... whereas in Visual Studio, some things are added automatically. It was chaotic, the way I wrote code, the number of lines just to trigger a simple button event...🙃

• Later on, I began learning Git commands. At first, they seemed overwhelming and meaningless, but I focused on the ones I used most often, and gradually I started recognizing more and more of them.
Even now, I still discover new ones or revisit old ones I’ve forgotten.😄
Not long ago, I also started learning React and TypeScript. I still have a lot to learn, but I feel comfortable with the basics and can build projects with them.

• Slowly, things started to make sense.🤗 I got used to the syntax, the logic of the languages, I began creating small games, giving life to my curiosity, despite the fear of the unknown. I knew it would be hard, that it would take time and effort, but I didn’t let that overwhelm me. I put my fears and inner voice aside and started planning my learning path.

On a personal note...

• Even though everything was new and it felt like this reading would never end, I realized I don’t have to be perfect. I don’t have to learn every little detail. If I had tried to do that, I’d probably still be studying just CSS...🙃

• You don’t need to know everything perfectly. These languages were designed over years by teams of people, not by just one brain.
You can’t possibly learn an entire language in just a few months and then say: Alright, time for the next one...! It’s like trying to learn several spoken languages at once and wanting to master them perfectly in no time, your brain will eventually crash.

• In the beginning, the basics matter most. As you progress, you can build on them with intermediate concepts but don’t let those overwhelm you too soon.
Why⁉️ Because you’ll feel discouraged. You’ll feel like you’re just learning to check things off a roadmap, but you won’t see real progress using the knowledge you already have. And your inner voice will start saying: There’s too much to learn, too much to process, too much to memorize... give me a break.

• That’s when I realized: You have to work with your brain, not against it.🤗 Take breaks, even a few days off. That’s not wrong. Relax. Give yourself time to process what you’ve learned. Don’t overload yourself with too many concepts at once.Use short, focused work sessions. It’s not about how many hours you sit in front of the computer, if you’re tired and unfocused, you’ve only truly studied for 2–3 of those hours. But if you’re well-rested and focused for just 2-3 hours a day, you’ll feel the difference in learning and progress.

• It’s not about how long you study, it’s about consistency. Doing a bit every day matters more than cramming once a week. Being present, showing up, continuing, that’s what builds progress.🤗

About that inner voice...

• My inner voice used to work against me. It doubted me. It told me I couldn’t do it. That it wasn’t for me. Why⁉️ Because I never proved it wrong. I let it speak. I listened. But then, I stopped listening and
started proving it wrong. I thought that way because I wasn’t practicing enough. I wasn’t building projects, just collecting knowledge in my head, unorganized.

• That made me feel overwhelmed, and gave that inner voice all the power. But when I started applying what I was learning, building projects, putting things in order, that’s when my confidence grew.

• We started to become friends.🙃 I realized that inner voice was rushing the learning process. It didn’t let me enjoy daily progress or celebrate each new concept. It wanted too much, too fast. It was turning me from a perfectionist into an imperfectionist. So I said STOP❗

• I’m on this path, and it won’t take a year, or even two. It’s a lifelong journey. A path where I’ll always have something to learn and where curiosity will always be alive. You have to be friends with your inner self and show yourself that you trust yourself. Celebrate your progress, however small.

What challenges have I faced?

1. The right way for learning...

I had set up a daily schedule: study at least 3 hours a day.But often I was afraid to even start. Afraid of running into something I didn’t know, afraid of bugs in my code... So I started small just 10 minutes working on something I already knew. That helped me silence that inner fear, and show myself that I do know things, that each day adds another piece to the puzzle. To prove I’m not incapable or powerless. To overcome the fear of failure, because we learn through mistakes and bugs.

2. Time management

• Time used to scare me❗I felt it slipping by, pressuring me. I wanted more, and I wanted it fast. I started thinking I was learning too slowly, doubting my schedule, thinking I was stuck. But that’s because I wasn’t looking back at my progress.

• At the small projects I had created. The more I learned, the more I wanted to build amazing websites, but I didn’t want to spend time building, just learning.And that was wrong. It’s like learning math formulas without applying them. Or learning a new language but never writing in it, only speaking.

3. Developers and online noise

• I started learning from video tutorials. But soon, it became a storm of videos, like a loop. I watched more and more, hoping to learn more and more...But my eyes were tired, and without reviewing or applying anything, taking notes was almost pointless.

• Then I stumbled upon all kinds of online ads:
“You can build anything using just CSS and HTML...”,
“Learn to code in 3 months...”,
“Get hired in just a few months if you follow this course...”
Those things started to discourage me. I felt like I was moving too slowly. I started doubting myself: “Maybe it’s not for me⁉️”

• But the truth is, that’s not how real learning works. You can’t become a real developer in one year and be perfect. Everyone learns at their own pace. You’re not a robot. You can’t absorb programming in a few weeks and suddenly be a developer❗

In conclusion❤️

• It wasn’t easy in the beginning. But I had to be consistent. I had to prove to myself that I can, step by step.🥰 To learn from mistakes. To stop giving power to that inner voice. To become whole, strong. To learn from failures and trust the process❗

Work with yourself, not against yourself.🥰
Learn to enjoy the journey, not just chase the destination.🤗
As always, feel free to share your thoughts, your feedback means a lot to me. Thank you for reading, see you around!🥰🤗

Challenge yourself with CSS, JS, or React — my quiz game awaits!🎮

Theodora Cristea — Fri, 25 Jul 2025 14:39:49 +0000

Hey everyone!👋
I know I haven’t posted in a while, I’ve been spending my time learning and building small projects. Today, I’m excited to share one of the little games I’ve created!
It’s nothing too fancy, but ever since I started coding, I told myself that I wanted to create a fun quiz game, with sounds, scoring, and colorful UI to make it engaging for players.
I’d love for you to check it out, play around with it, and let me know what you think. Your feedback means a lot to me, especially since I’ve only been on this coding journey for about 10 months. Knowing that someone appreciates my work would really make my day!❤️

What is this game?

This is an interactive quiz game designed to help you improve your knowledge of CSS, React, and JavaScript.
You can pick a category and try to answer as many questions correctly as you can.
The game is built for both beginners who want to learn and developers who want to quickly test their knowledge.

In short, this game is:
An educational quiz –> a quick test for your web development knowledge.
An interactive learning tool –> helping you spot where you need to improve.
A fun challenge –> see how many correct answers you can get!

Gallery

Dark mode screenshot	Light mode screenshot

Correct answer	Wrong answer

Demo

Live game: Play here!
Source code: GitHub Repository

What features does the game have?

• Technologies: Pure HTML, CSS, and JavaScript (no frameworks).
• Background sounds: Fun sound effects to make the experience more interactive.
• Light/Dark theme: Switches between light and dark modes.It even detects your OS theme automatically.
• Responsive design: Fully responsive, looking great on mobile, tablet, and desktop.
• Life system: You have 3 chances.
• Scoring system: Earn points for each correct answer and track your high score.

My Journey ❤️

Working on this project taught me so much more than just coding. I built everything from scratch with pure HTML, CSS, and JavaScript – no frameworks, no shortcuts. It challenged me to truly understand the fundamentals and to think creatively about solving problems.

One of the biggest lessons I learned is how important it is to create projects that make you happy, projects that spark your curiosity and keep you motivated. I’ve always wanted to build a fun quiz game, and working on something I genuinely enjoy made every step exciting, even when things got tricky.

Through this project I learned:
• How to build responsive and interactive UI/UX without relying on external libraries.
• The importance of small details: colors, transitions, sounds, and animations can make a big difference.
• That building something you love will always push you to go further and learn more.

This game isn’t just a coding exercise - it’s a reminder that programming can be fun and creative when you build something you care about.
Leave a comment if you liked it, it would mean a lot to me! 🤗

How I Got Started? Why We Shouldn't Give Up❗

Theodora Cristea — Mon, 14 Jul 2025 16:48:50 +0000

First of all, hello everyone, this is my first post in this community.
“Hello world!” I can’t wait to get to know you! Let me briefly introduce myself: my name is Theodora, I’m 23 years old, and I’ve decided to start a journey down a completely new and parellel path. Yes, you heard that right!🙃

I felt like my life needed a new direction, something more challenging, something that constantly feeds my curiosity and helps me grow, without boring me with repetitive goals, something that pushes me and makes me want to come back to work with joy.

Why Did I Choose Web Development?

Someone special to me encouraged me to dive into the world of web development. I called it a “parallel” world earlier because that’s exactly how it felt I had absolutely no idea what web development even was. It all seemed impossible at first! But I chose to do it because it felt like a real challenge.

I love that this world is open to anyone regardless of age, background, or degree. All you really need is curiosity, persistence, and the will to learn, to be a bit of a perfectionist, and to never give up.
As I got deeper into it, I realized that this is a space where ideas take shape, where code becomes the bridge between imagination and reality.It’s a universe where a few lines of HTML can turn a blank page into an experience, where CSS adds personality, and JavaScript breathes life into your vision.

Because web development is about building, failing, learning, and trying again and every time, I found myself growing through it. I wasn’t just learning how to build websites or apps, I was learning how to solve problems, how to think logically, and how to create something others could use, appreciate, and even be inspired by.

What Did I Feel When I Wrote My First Lines of Code?

Honestly, I was thrilled! My very first project was a small quiz game. Nothing huge but that’s not what matters. What matters is the joy of seeing your idea live in the browser. Of knowing that you built something from scratch, maybe with 100 lines of code and it actually works!
I swear, anyone who’s started coding knows the excitement of their first alert() or console.log()...🙃

Didn’t it feel like getting your favorite candy as a kid? 🙃

Let’s celebrate those little victories that made your journey so worth it leave a comment and share yours!

What Are My Plans?

Right now, my goal is to keep going and to enjoy every level I unlock along this path. I know it won’t always be easy and that’s okay. I’ll continue anyway.

Why?

Because I’ve become friends with web development. I crave challenges, knowledge, and creativity and that’s exactly what this field gives me. If I could give my past self (or you, reading this) a piece of advice, it would be this:

Do what makes you happy. Without regret, without hesitation, and without fear. Nobody is born knowing everything not in this field, not in any field.

And even if you’re starting from zero, that doesn’t mean you’re incapable or weak. We are made to grow, to absorb knowledge, and to expand. Believe in yourself in your goals and your choices.

Will I Ever Regret It?

I know that web development is not easy. No one is born perfect. We’re born to learn. We’re wired to seek, to explore, to stand in awe of the unknown. That deep hunger for knowledge never really fades and that’s what makes us extraordinary. Yes, we’ll make mistakes. But mistakes aren’t the enemy fear of trying is. Every wrong turn teaches us something. Every fall becomes a lesson. 🙃

Confidence isn’t something we’re born with it’s something we build, slowly, every time we choose to rise again and try once more.

True growth doesn’t mean never failing it means becoming better than we were yesterday.I understand that there are numerous concepts to master but I encourage you to be patient and persist in your efforts.

So, will I ever regret choosing this path? Is it really impossible⁉️
Absolutely not.❌ And neither will you.
Because we are strong, not because we never fall, but because we keep getting back up. Our strength lies in the courage to move forward, even when it’s hard. We don’t need to have all the answers we just need the will to keep looking.
That’s what makes us powerful: We don’t stop.
Keep going!👌

DEV Community: Theodora Cristea

Rappelo was launched: how we help solopreneurs and small businesses❗

Intro

Why did we build Rappelo❓

The Real Problem

More than just a notification

Rappelo is officially live!

The Developer's Safety Net - Introduction to TypeScript

1. What TypeScript actually is?

2. TypeScript or JavaScript!?

3. Should you learn TypeScript or JavaScript first!?

4. Why TypeScript is worth using?

5. What to watch out for when learning TypeScript?

Conclusion❤️

From localStorage to Database: Understanding the MongoDB Structure❗

Intro

1. Where we Started: The SQL World

2. The NoSQL story: Not Only SQL

Why 'Not Only SQL'❓

3. From localStorage to Database

Document:

Colection:

Flexibility by Nature:

The Essential Field: _id

4. Basic CRUD Operations:

1. Create: insertOne()/insertMany()

2. Read: find()/findOne()

3. Update: updateOne()/updateMany()

4.Delete: deleteOne()/deleteMany

Conclusion ❤️

Frontend to Backend: From Vite to Express❗

Intro

Routing: Frontent vs Backend

Frontend Routing (Vite, React Router)

Manual Routing in the Backend (Express.js)

From Source to Server

Static Files in Development:

From src to dist:

Enter express.static():

Development vs Production:

Development Mode (our workbench):

Production Mode (the live public server)

Security Risks:

Order Matters: Handling Critical Paths in Express

The Role of Middleware: app.use()

The React Router Trap:

Conclusion❤️

Node.js-Steps for building your first server❗

Introduction

1. Understanding the Event Loop

Definition

The logic is the following:

Imagine this as a simple analogy:

Simple code example:

2. HTTP Module & Create Server

Simple Analogy

Simple code example

3. Req vs Res Objects

The req (Request) Object Definition:

The res (Response) Object Definition:

Simple Analogy

Simple code:

4. Simple Routing

Definition

Simple Code

5. Loading Files

Definition

Simple Code

6. Building a Simple API

Definition

Simple Code

7. Middleware

Definition

Simple code

8. Cleanup (Middleware & Handlers):

The logic is the following:

Simple code

app.js file

routes/users.js file

9. Get Req Body For POST

The Essential Field: `_id`

1. Create: `insertOne()`/`insertMany()`

2. Read: `find()`/`findOne()`

Enter `express.static()`:

The `req` (Request) Object Definition: