DEV Community: ozkeisar

Give Juniors a Chance

ozkeisar — Mon, 15 Sep 2025 20:14:17 +0000

It's no secret that it's hard right now for juniors to find a job in tech. The market has shifted dramatically, and entry-level positions are becoming increasingly rare. Companies are looking for senior developers who can hit the ground running, and the traditional junior developer role seems to be disappearing.

The rise of AI has fundamentally changed the equation. Tasks that used to be perfect for junior developers - writing boilerplate code, fixing simple bugs, implementing basic features - can now be handled by AI assistants. Why would a company hire a junior developer when a senior developer with AI tools can be 10x more productive? This creates a vicious cycle: juniors can't get experience because there are no junior positions, and there are no junior positions because companies want experienced developers.

But here's the thing - we still need fresh talent in tech. We need new perspectives, diverse backgrounds, and hungry minds eager to learn. The question is: how do we evaluate junior candidates when they haven't had the chance to prove themselves in a professional setting?

A Better Way Forward

I believe there's a solution that benefits everyone: companies should leverage their official sponsored open source projects as a proving ground for junior developers. Not by creating artificial test projects or contrived coding challenges, but by opening up real contributions to real projects that matter.

Here's how it would work: instead of the traditional resume-interview-rejection cycle, companies could point candidates to their sponsored open source projects. These could be projects they maintain, contribute to regularly, or financially support. The candidates would tackle real issues - the same ones that need solving anyway. No made-up problems, no take-home tests that get thrown away, but actual contributions that benefit the community.

With today's tools and AI assistance, contributing to open source isn't as daunting as it once was. AI can help juniors understand codebases faster, write better documentation, and even assist with debugging. It levels the playing field in many ways. What it can't do is replace the problem-solving skills, the persistence, and the ability to collaborate that makes a good developer.

Real Signal, Not Noise

This approach gives companies something invaluable: the ability to see how a candidate actually works. How do they communicate in pull request reviews? Do they ask good questions? Can they take feedback? Do they persist when things get difficult? These are the qualities that actually matter, and they're impossible to gauge in a traditional interview.

For juniors, it's a chance to build a real portfolio. Even if they don't get hired by that specific company, they've contributed to open source, learned from code reviews, and have something concrete to show the next potential employer. They're gaining real experience, not just spinning their wheels on another rejected application.

Companies don't need to create special evaluation repositories or manufacture issues just for candidates. The beauty of this approach is using what already exists - real problems that need real solutions. By sponsoring or collaborating with existing open source projects, they're also giving back to the community that their businesses are built on.

Making It Work

This isn't about free labor or exploiting desperate juniors. It's about creating a more transparent, merit-based path into the industry. The traditional hiring process is broken for juniors - it rewards those who can afford unpaid internships or have connections, not necessarily those with the most potential.

We keep talking about the "talent shortage" in tech while simultaneously making it nearly impossible for new talent to enter the field. Maybe it's time we tried something different.

Your Thoughts?

What do you think? Have you seen companies successfully use open source as a hiring pipeline? If you're a junior developer, would this approach appeal to you? If you're involved in hiring, what barriers would prevent you from trying this? I'd love to hear your thoughts and experiences.

test

ozkeisar — Thu, 06 Mar 2025 15:37:11 +0000

test

check out this!

ozkeisar — Mon, 13 Jan 2025 16:59:27 +0000

Okay, Seriously, Mockingbird + Git is a Game Changer (and I Made a Video About It!) 🚀

ozkeisar ・ Jan 13

#webdev #programming #tutorial #opensource

Okay, Seriously, Mockingbird + Git is a Game Changer (and I Made a Video About It!) 🚀

ozkeisar — Mon, 13 Jan 2025 16:57:09 +0000

Hey! So, I finally finished that video I was working on, and I gotta say, I'm kinda hyped about it. It's all about using Mockingbird with Git, If you've ever felt like managing mock data is just a huge pain, or like your team is always stepping on each other's mocks, then you might actually dig this.

Basically, this combo is way more useful than it sounds. It means less time messing with mock setups, and more time actually building stuff. In the video, I just walk through everything, from getting a project going to sharing it with your team super easily.

What You'll Actually Learn:

Hook Up Mockingbird to Git: I'll show you how to connect your Mockingbird stuff to Git, so everything gets version-controlled. Even your mock data.
Share Mocks Like It's Nothing: You'll see how to push and pull your mock data, making it easy for everyone on your team to stay on the same page.
Branching for Mocks? Yep, Weird but Cool: Use Git branches to keep your mocks organized, which is actually kind of awesome.
Clone Stuff Fast: Set up your mocks quick for the whole team by cloning your project. It's a total lifesaver.
Git Right in Mockingbird: I'll even show you how to use Git commands directly from the app - pretty handy.
Save Some Money (Maybe): Using Git for mocks means you don't need extra servers, which might save you a buck or two.

Why You Should Bother:

Look, I know, we're all busy. But this is one of those things that can just make your life a little bit easier. Mockingbird is cool, but add Git, and you've got:

Teamwork that Doesn't Suck: Sharing mocks without any drama, that's the goal here.
Version Control For Your Mocks: Track changes, go back if you mess up, and keep different versions.
Less Mess: Skip the extra server setup; Git does all the hard work.
Use What You Already Know: It's Git, so you probably already know how it works anyway.
Do Stuff Faster: Streamline stuff so you can get back to the code.

Alright, Enough of Me Blabbing, Watch the Video!

If this sounds up your alley, then click on the link and let me know what you think.

Sneak Peek Inside the Video:

Set Up a Project (It's Not Scary): Start a Mockingbird project and add a couple routes.
Connect to Git: Link your project to GitHub, GitLab, whatever you use.
Push Your Mocks: Save your data to Git, so your team can see it.
Clone & Branch: Make copies of your project and use branches to keep things organized.
Pull & Merge: Bring updates to your project.
Built In Git: Showing the built in terminal.
Recap Just going over all of the major things we went over.

Last Thing:

Leave a comment on the video if you have thoughts or questions.
Subscribe to my channel for more of these, I guess.
Share this with your team if you think they would find it useful!

I'm actually really curious to see what you think about it, so check it out and let me know.

Thanks, and yeah, happy mocking! 😄

🎥 New Video Tutorial: Getting Started with Mockingbird 🚀

ozkeisar — Tue, 31 Dec 2024 07:44:35 +0000

Hi everyone! 👋

I’m excited to share that I’ve just released a brand-new video tutorial about Mockingbird, an open-source tool I built to help developers and QA teams create mock environments quickly and efficiently. Whether you’re just starting out with Mockingbird or looking to dive deeper into its features, this tutorial is for you!

What You'll Learn in the Tutorial:

How to download and install Mockingbird on your machine (Mac, Windows, and Docker).
Creating your first project: Set up mock servers with REST or GraphQL routes.
Managing responses: Learn to create multiple responses for each route and simulate various scenarios.
Advanced features: Explore Git integration, proxy capabilities, and monitoring API calls.

🔗 Watch Video

Why Mockingbird?

Mockingbird simplifies API testing and development workflows by providing:

Open-source flexibility and transparency.
Support for REST and GraphQL APIs.
Built-in Git integration for secure data management.
A proxy feature to quickly create mocks from real API calls.
Monitoring tools for all API activity in your project.

🔥 Next Steps:

After watching the tutorial, you’ll be ready to:

Create your first mock server with Mockingbird.
Add custom responses and routes to simulate different API scenarios.
Explore how Mockingbird can streamline your development and testing workflows.

💬 Feedback and Questions:

Your feedback is invaluable! Feel free to drop a comment here or on the video. If you encounter any issues or have feature suggestions, join the discussion on GitHub: Mockingbird GitHub Repository.

🙌 What's Next?

This is just the beginning! I’m working on more tutorials, including:

Setting up Docker with Mockingbird.
Using Mockingbird for GraphQL servers.
Advanced scenarios like testing with Git integration.
Using Mockingbird Presets for integration tests, and scenario switching using Mockingbird API

Stay tuned for more updates, and don’t forget to follow me on DEV.to!

Thanks for your support, and I hope this tutorial helps you get started with Mockingbird! 🎉

My First Mockingbird Tutorial Video Is Going Live

ozkeisar — Sun, 29 Dec 2024 21:22:03 +0000

Hey everyone,

I’m stepping out of my comfort zone to share something I’ve been working on—my first tutorial video for Mockingbird is going live soon on YouTube!

In this video, I’ll walk through:

How to download and install Mockingbird

Setting up your first project

Exploring the basic features of Mockingbird like multiple responses and more

Mockingbird was created to solve real challenges I faced in API development, and I hope it can help you too.

If you’re interested, I’d love for you to register for the video premiere and join me live:
👉

If you’d like to learn more about Mockingbird in the meantime, feel free to check out my first article:
👉 Mockingbird: New Tool for Your Mock Environments

Your support, feedback, and thoughts mean the world to me as I take this big step.

Thank you for being part of this journey—it’s your encouragement that keeps me going!

Dockerize Your Mockingbird Setup: A Quickstart Guide

ozkeisar — Wed, 21 Aug 2024 12:58:02 +0000

Mockingbird is a powerful tool for creating and managing mock API environments. This guide will help you get started with the Docker version of Mockingbird, focusing on creating, cloning projects, and managing mock servers via the API.

If you are new to Mockingbird we recommend you to start by using Mockingbird app and reading the first guide

Prerequisites

Ensure that you have Docker installed.

Step 1: Pull the Mockingbird Docker Image

Start by pulling the Mockingbird Docker image from Docker Hub:

docker pull ozkeisar/mockingbird:latest

Step 2: Run the Docker Container

Run the Docker container using the following command:

docker run -d -p 1511:1511 --name mockingbird ozkeisar/mockingbird

This command will:

Start the Mockingbird container in detached mode (-d).
Map port 1512 of your local machine to port 1512 of the container (-p 1512:1512).
Name the container "mockingbird" (--name mockingbird).

Step 3: Access the API Documentation

You can access the Swagger documentation to explore the API at:

http://localhost:1511/api-docs

Step 4: Create and Clone Projects Using the API

4.1. Create a Project

To create a new project, use the /project/create endpoint. Send a POST request with the following JSON body:

{
  "projectName": "your_project_name"
}

4.2. Clone a Project via SSH

To clone a project using SSH, use the /project/clone/ssh endpoint. Send a POST request with the following JSON body:

{
  "projectName": "your_project_name",
  "sshUrl": "git@github.com:user/repository.git"
}

4.3. Clone a Project via HTTPS

To clone a project using HTTPS, use the /project/clone/https endpoint. Send a POST request with the following JSON body:

{
  "projectName": "your_project_name",
  "httpsUrl": "https://github.com/user/repository.git",
  "username": "your_username",
  "password": "your_password"
}

4.4. Open an Existing Project

To open an existing project, use the /project/open endpoint. Send a POST request with the following JSON body:

{
  "projectName": "your_project_name",
  "directoryPath": "/path/to/your/project"
}

Step 5: Start and Close the Mock Server

5.1. Start the Mock Server

To start the mock server for a specific project, use the /servers/start endpoint. Send a POST request with the following JSON body:

{
  "projectName": "your_project_name"
}

Note: Exposing Mock Server Ports

When starting mock servers, ensure that you expose the ports used by these servers so they can be accessed externally. You can do this by adding additional -p flags when running the Docker container. For example, if your mock server runs on port 4000, include -p 4000:4000 in your Docker run command.

5.2. Close the Mock Server

To close the running mock server, use the /servers/close endpoint. Send a POST request without any body:

Step 6: Stopping and Removing the Container

To stop the running Mockingbird container, use:

docker stop mockingbird

To remove the container entirely, run:

docker rm mockingbird

Follow us on social media

I built a new way of mocking GraphQL server

ozkeisar — Mon, 12 Aug 2024 12:41:46 +0000

Introduction

Welcome! This guide will take you through the steps to create a GraphQL server using Mockingbird. Whether you’re a developer or a tester, this guide will help you set up a mock GraphQL server, create queries and mutations, and test everything out. By the end, you'll have a robust mock server that makes your development process smoother and faster.

In previous guides, we covered the basics of mocking with Mockingbird [1][2][3], These guides provided a solid foundation for using Mockingbird in various scenarios. Building on that knowledge, this guide focuses specifically on leveraging Mockingbird to mock GraphQL servers. If you’ve found our previous guides helpful, you’ll find this one equally valuable as it dives into the specifics of handling GraphQL with Mockingbird.

Let’s dive in and see how Mockingbird can simplify your GraphQL server setup and testing.

Step 1: Download and Install Mockingbird

Head over to the Mockingbird GitHub releases page.
Download the latest version.
Once the download is complete, open Mockingbird.

Step 2: Create a New Project or Clone an Existing One

When you open Mockingbird, you'll see a "Create Project" screen with three options:
- Create New Project: Start a new project from scratch by entering a project name.
- Clone Existing Project: Clone a project by entering the repository URL and any needed authentication details.
- Open Existing Project: Open a project that’s already saved on your computer.

Step 3: Create a Server

After setting up your project, you’ll need to create a server.
Give your server a name.
Specify the port number it will run on.

Step 4: Create a Parent

Next, you need to create a parent for your server.
Choose the option to create a GraphQL parent.
Enter a name for the GraphQL parent.
Set the REST path for the GraphQL endpoint, usually /graphql.
Decide if the parent will be a query parent or a mutation parent using the drop-down menu.
If needed, specify a schema path for nested queries using dot notation (e.g., user.address).
Save the parent once everything is filled out.

Step 5: Create Queries or Mutations

In the Parent Details page, click "Add Query" or "Add Mutation" based on your parent type.
Enter a name for the query or mutation. This name will be the schema signature and should include parameters if necessary. For example, a query called users that takes an ID would be users(id: String).
For complex parameters like custom objects, use Any as the type. For example, users(param: Any).
Optionally, add a description.
Save your query or mutation.

Step 6: Add Multiple Responses to the Query or Mutation

Go to the Query or Mutation Details page.
Click "Add Response."
In the window that opens, enter your response. You have three options:
- JSON: For JSON responses, you can automatically generate types. Click "Generate" to create the response type in the editor.
- Function: For function responses, you need to manually insert the response type. Alternatively, start with a JSON response to generate the type, then switch to a function.
- Proxy: For proxy responses, manually insert the response type, or use a JSON response to generate the type first, then switch to proxy.
Also, fill in the "Response Type Name" field with the main type name of the response.
Save the response.

Step 7: Enable Proxy Mode (Optional)

Mockingbird can act as a proxy server for GraphQL. If a query or mutation isn’t found locally, it forwards the request to the target server.
Once you get a response from the target server, you can add both the query and its response to Mockingbird from the console.

Step 8: Start the Server and Test

Start the server to apply your configurations.
After the server is running, you’ll get a link to the GraphQL playground.
Use this link to open the playground.
There will also be a button to copy a sample query for your setup.
Paste the sample query into the playground to verify you’re getting the desired response from the GraphQL server.

Epilogue

Mockingbird makes the complex task of mocking a GraphQL server much easier. This tool is perfect for developers and testers, allowing them to simulate various scenarios without waiting for the actual server to be built. With features like multiple response creation, type generation, and easy switching between setups, Mockingbird streamlines your development and testing processes.

Proxy Mode

One of Mockingbird’s standout features is its ability to act as a proxy server, even for GraphQL. This feature is incredibly useful when you have queries or mutations that are not defined locally in Mockingbird. Here’s how it works:

Forwarding Requests: When a query or mutation isn’t found in your local Mockingbird setup, Mockingbird forwards the request to the target server. This ensures that you always get a response, even if it’s not yet mocked locally.
Capturing Responses: Once Mockingbird receives the response from the target server, it allows you to add both the query and its response to your local Mockingbird setup. This means you can quickly build out your mock server using real data without manually defining every response upfront.
Simplifying Setup: This proxy feature makes setting up a mock server with real data quick and hassle-free. Instead of having to manually enter every possible query and response, you can let Mockingbird capture and store them for you as they come in.

This feature is perfect for quickly setting up realistic mock environments, especially in dynamic development and testing scenarios. It saves you time and effort, ensuring that your mock server is as accurate and comprehensive as possible with minimal manual intervention.

Whether you’re developing new features, running automated tests, or setting up complex integrations, Mockingbird’s proxy capabilities save you time and reduce errors. Its flexibility and ease of use make it a crucial tool for modern software development and testing environments.

By using Mockingbird, you can focus on building and refining your application, knowing your mock environment is reliable and efficient.

Join the Community

If this guide has helped you why not give it a try? You can download Mockingbird and start building your own mock servers today. If you like what you see, a star on GitHub would mean a lot—it’s a small way to show support for the project. And if you’re interested in contributing, we’d love to have you onboard. Your feedback and contributions are what make Mockingbird better with each update.

How Can We Improve Mockingbird for Better Developer Experience?

ozkeisar — Tue, 25 Jun 2024 12:16:49 +0000

Hello DEV community!

I’ve been working on Mockingbird, a tool designed to enhance API development workflows by providing features like multiple responses for each route, presets for easy scenario switching, Git integration, and more. My goal is to make Mockingbird a seamless and powerful tool for developers.

I’d love to hear from you all:

What features would you like to see in Mockingbird that would make it more useful for your projects?
Are there any pain points you currently experience with mock servers that Mockingbird could address?
How important is the support for WebSocket and gRPC in your workflow, and what specific functionalities would you need?

Your feedback and suggestions will be incredibly valuable in guiding the future development of Mockingbird. Thank you!

Creating and Managing Multiple Projects and Servers with Mockingbird

ozkeisar — Sun, 16 Jun 2024 09:45:00 +0000

In the fast-paced world of software development, efficiency and productivity are paramount. Mockingbird, a powerful tool designed for creating and managing mock environments, offers developers a streamlined solution to enhance their workflows. This blog post will guide you through the process of creating and managing multiple projects and servers using Mockingbird, ensuring you can maximize your development and testing capabilities.

Why Use Mockingbird?

Mockingbird is designed to address common challenges faced by developers, such as waiting for server development to be completed, which often leads to project delays. By providing a robust mock environment, Mockingbird allows developers to test APIs without the need for additional servers, significantly reducing integration times and boosting productivity.

Getting Started with Mockingbird

Before diving into managing multiple projects and servers, let's start with the basics of setting up Mockingbird.

Download and Installation:
- Download the latest version of Mockingbird from the Releases page on GitHub.
- Run the installer and follow the instructions to complete the installation.
Initializing Your Project:
- Launch Mockingbird and start a new project by entering a unique project name in the 'project name' input field.
- Open or create or clone repository, to start your project in Mockingbird.

Managing Multiple Projects

Mockingbird allows you to manage multiple projects seamlessly, making it an ideal tool for teams working on various applications simultaneously.

Creating another Project:
- In the Mockingbird top bar, open the projects dropdown and then click on the + new project button.
- Open or create or clone repository, to start your project in Mockingbird.
Switching Between Projects:
- Use the project dropdown menu to switch between different projects.
- Each project maintains its own set of routes, responses, and server configurations, ensuring a clean and organized workspace.

Setting Up and Managing Multiple Servers

Mockingbird's ability to handle multiple servers within a single project is one of its standout features. This capability is particularly useful for complex applications that interact with various backend services.

Initiating a New Server:
- Click on the + new server button in the side bar.
- A dialogue box will appear; insert your server name and hit SAVE.
Configuring Your Server:
- After creating your server instance, click on the server name to open its details.
- Enter your real server's base URL in the Target URL field to let Mockingbird act as a proxy when necessary and hit save.
- Click Start Server to activate your mock server and access the server's IP by clicking on the Servers IP button.
Creating Local Routes:
- Add a parent to hold routes by selecting New Parent and specifying the path and filename.
- Define the HTTP method and path for each route, then add the route.
- Choose between function, JSON, or proxy responses, set response details, and save.

Monitoring and Debugging

Mockingbird provides a console to view all API requests and how they are handled, offering valuable insights for debugging and optimization.

Using the Console:
- Open the Mockingbird console to monitor incoming API requests.
- Analyze the requests and responses to identify and resolve issues promptly.
Add routes from proxy requests.

Conclusion

Mockingbird is a versatile tool that simplifies the process of creating and managing multiple projects and servers. By leveraging its intuitive interface, powerful presets, and comprehensive monitoring capabilities, developers can significantly enhance their productivity and streamline their development workflows. Whether you're working on a single application or managing multiple projects, Mockingbird provides the tools you need to achieve seamless and efficient development experiences.

Upcoming in This Series

Setting up a GraphQL Mock Server with Mockingbird.
Dynamically Updating Mockingbird Responses from Automated Tests.

Engage With Us

Follow me on Twitter, also you can join the discussion or share your experiences on our subreddit or directly in the comments below. Your feedback helps us improve and guides our future developments.

Happy mocking, fellow developers!

Mockingbird Presets: Optimizing API Development Workflows

ozkeisar — Wed, 12 Jun 2024 09:45:00 +0000

In our previous articles, we explored the fundamentals of Mockingbird and how to set up your mock server. In this third installment of our Mockingbird series, we delve into one of its most powerful features: Presets. Presets significantly enhance productivity and efficiency when testing and debugging APIs, making them an essential tool for developers and QA teams.

What are Presets?

Presets in Mockingbird are collections of routes with predefined responses. They allow you to quickly switch between different test scenarios by applying a preset, which updates the active responses on all routes within that preset to their specified values.

Benefits of Using Presets

Efficient Testing and Debugging: Presets enable you to rapidly switch between different test scenarios without manually changing each route's response. This streamlines the testing and debugging process, saving valuable time and effort.
QA Automation and Manual Testing: Presets are particularly useful for QA automation and manual testing. By applying a preset, you can quickly set up the desired test environment, ensuring consistent and reliable testing across different scenarios.
Developer Productivity: Developers can leverage presets to efficiently debug specific scenarios without the need to manually modify each route's response. This enhances productivity and allows for quicker issue resolution.
Consistent Demos: Presets are invaluable for demonstrating your application's features. By setting up various test scenarios in advance, you can seamlessly switch between them during a demo, providing a polished and professional presentation.
Training and Onboarding: Presets can be used to create specific scenarios for training new team members. This ensures that new developers or testers can easily understand and interact with the system without setting up their own test cases.
Simulating Edge Cases: Presets allow you to quickly simulate edge cases or rare scenarios that are hard to reproduce in a live environment. This ensures comprehensive testing and robustness of your application.
Collaboration Across Teams: Presets can be shared across different teams, ensuring that everyone is testing and developing against the same scenarios. This improves collaboration and reduces discrepancies between environments.

Using Presets in Mockingbird

To use presets in Mockingbird, follow these steps:

Create a Preset: In the Mockingbird interface, navigate to the "Presets" tab

Click on New folder, fill the folder name and filename and then click save.

Then click "Add Preset".

Give your preset a descriptive name and save.

Click on Add route and then dialog will open and let you select the desired route.

In the dialog select the server parent and the desired route, then you will have a list of all the responses on this route and you will be able to select the desired response, select the response and hit save.

In the preset details you will see the server block and inside it the route parent and under the parent the selected route, on the route row you will see the selected response name.

Repeat this process with all the routes that you want to add to the preset.

Apply a Preset: Once you have created one or more presets, you can apply them to your mock server. Simply select the desired preset from the list, and Mockingbird will update the active responses on all routes within that preset to their specified values.
Test and Debug: With the preset applied, you can now test your application against the configured responses, simulating different scenarios without modifying your codebase or waiting for backend changes.
Switch Between Presets: To test a different scenario, simply apply another preset. Mockingbird will seamlessly update the active responses, allowing you to quickly switch between test environments.

By leveraging the power of presets in Mockingbird, you can significantly streamline your API testing and debugging workflows, enabling faster iterations, improved collaboration, and ultimately, more efficient development cycles.

Upcoming in This Series

Setting up a GraphQL Mock Server with Mockingbird.
Managing Multiple Projects and Servers in Mockingbird.
Dynamically Updating Mockingbird Responses from Automated Tests.

Engage With Us

Follow me on Twitter, also you can join the discussion or share your experiences on our subreddit or directly in the comments below. Your feedback helps us improve and guides our future developments.

Setting Up Your Mock Server with Mockingbird

ozkeisar — Thu, 16 May 2024 21:45:01 +0000

Introduction

Welcome to another article of our Mockingbird series! Today, we'll demonstrate how to set up a mock server quickly and effectively using Mockingbird - a tool designed to streamline your application development and testing processes. If you missed the introductory article, I recommend starting there to get a foundational understanding (Read the first article here). Let's dive into how you can configure your mock server in minutes.

Why Use a Mock Server?

Before we begin, let's understand why a mock server is beneficial. Mock servers simulate API responses without having to set up a complete backend, allowing developers to test the front end independently, troubleshoot more efficiently, and improve team collaboration on projects. Now, let's set up your mock environment with Mockingbird.

Configuring Your Mock Server

Set Up Your Server

After creating your server instance in Mockingbird, click on the server name to open its details.
Find the Target URL field and enter your real server's base URL. This action will let mockingbird act as a proxy when necessary

This feature allows you to start working with Mockingbird even if you don't have all the API calls registered locally.

Redirect Your Application

Click Start Server to activate your mock server, and then access the server's IP by clicking on the Servers IP button.
With the IP address revealed, go to your application's code base and swap out the live server base URL with the Mockingbird server URL.

Monitoring API Calls

Navigate to the Mockingbird console by clicking on the console button on the top bar. Here, you'll observe all API requests that your application makes. The console not only captures incoming requests but also displays how each is handled, whether locally or forwarded to the real server.

Creating Local Routes

If Mockingbird detects an API call that isn't set up locally, you'll have the option to create it right from the console:

Add Parent: let you define the parent path for your API.
Add Route: Once the parent is established, you can add specific routes.
Add Response: Finally, define the responses for your routes.

This will let you harvest the calls that exist on your real server and create a mock server in a few minutes!

Conclusion

Mockingbird offers a straightforward and powerful way to develop and test against a mock server, managing API calls efficiently without complex configurations. By following these steps, you can set up your mock server and start testing your application in no time.

Spread Your Wings and Fly with Mockingbird!

You can download Mockingbird from GitHub releases page.
Even if you don't plan on using it right away, consider supporting our project by starring and endorsing it on GitHub.

Upcoming in This Series

Setting up a GraphQL Mock Server with Mockingbird.
Exploring the Power of Presets in Mockingbird.
Managing Multiple Projects and Servers in Mockingbird.
Dynamically Updating Mockingbird Responses from Automated Tests.

Feel free to ask questions, leave comments, or raise an issue on the GitHub issues page. We're excited to see how you use Mockingbird to enhance your development workflow!

Engage With Us

Join the discussion or share your experiences on our subreddit or directly in the comments below. Your feedback helps us improve and guides our future developments.

DEV Community: ozkeisar

Give Juniors a Chance

A Better Way Forward

Real Signal, Not Noise

Making It Work

Your Thoughts?

test

check out this!

Okay, Seriously, Mockingbird + Git is a Game Changer (and I Made a Video About It!) 🚀

ozkeisar ・ Jan 13

Okay, Seriously, Mockingbird + Git is a Game Changer (and I Made a Video About It!) 🚀

🎥 New Video Tutorial: Getting Started with Mockingbird 🚀

What You'll Learn in the Tutorial:

🔗 Watch Video

Why Mockingbird?

🔥 Next Steps:

💬 Feedback and Questions:

🙌 What's Next?

My First Mockingbird Tutorial Video Is Going Live

Dockerize Your Mockingbird Setup: A Quickstart Guide

Prerequisites

Step 1: Pull the Mockingbird Docker Image

Step 2: Run the Docker Container

Step 3: Access the API Documentation

Step 4: Create and Clone Projects Using the API

4.1. Create a Project

4.2. Clone a Project via SSH

4.3. Clone a Project via HTTPS

4.4. Open an Existing Project

Step 5: Start and Close the Mock Server

5.1. Start the Mock Server

Note: Exposing Mock Server Ports

5.2. Close the Mock Server

Step 6: Stopping and Removing the Container

Follow us on social media

I built a new way of mocking GraphQL server

Introduction

Step 1: Download and Install Mockingbird

Step 2: Create a New Project or Clone an Existing One

Step 3: Create a Server

Step 4: Create a Parent

Step 5: Create Queries or Mutations

Step 6: Add Multiple Responses to the Query or Mutation

Step 7: Enable Proxy Mode (Optional)

Step 8: Start the Server and Test

Epilogue

Proxy Mode

Join the Community

How Can We Improve Mockingbird for Better Developer Experience?

Creating and Managing Multiple Projects and Servers with Mockingbird

Why Use Mockingbird?

Getting Started with Mockingbird

Managing Multiple Projects

Setting Up and Managing Multiple Servers

Monitoring and Debugging

Conclusion

Upcoming in This Series

Engage With Us

Mockingbird Presets: Optimizing API Development Workflows

What are Presets?

Benefits of Using Presets

Using Presets in Mockingbird

Upcoming in This Series

Engage With Us

Setting Up Your Mock Server with Mockingbird

Introduction

Why Use a Mock Server?

Configuring Your Mock Server

Redirect Your Application

Monitoring API Calls

Creating Local Routes

Conclusion

Spread Your Wings and Fly with Mockingbird!

Upcoming in This Series

Engage With Us