DEV Community: Bernardo Costa Nascimento

The AI Craze

Bernardo Costa Nascimento — Sat, 28 Feb 2026 19:31:32 +0000

Lately I've been feeling really shitty about being a developer.

I've always enjoyed tech and, once I got to university, I discovered how much joy programing gave (and, sometimes, a bit of hate).

You could take some problem, think about it and create something, through your code, to resolve it. And, once you're were done, you felt great.

Then, came "AI". Everybody started talking about. Every company started using it(and forcing us to use it as well). You open Twitter - yes, Twitter - and all you see is "how model XYZ is the new hotness". And, honestly? I'm kinda done.

Don't get me wrong. I'm not writing this to tell you guys to "stop using AI". I use it most days. I think is a great tool to help you think about problems, do some boring tasks, provide boilerplate, etc... But I'm sick and tired of hearing people say that it is some kind of silver bullet and that all developers are cooked.

You hear all these crazy stories about "how I used AI to vibe code my app and win 100k in a week", which, honestly, feels like bullshit, but, if it is such an amazing tool, why don't you hear stories about it crushing it at some legacy app?

I don't use a lot of my time to read about AI stories, but, to this day, I've never seen a single story about an AI doing a good job on a legacy app.

Also, every single day there is a story on Twitter about some vibe coded application that got its database exposed because some AI bro vibe coded the next greatest application.

And, for me, this isn't even the worst part. As I said, I loved to think about and solve problems with code. And now? Am I supposed to love telling my AI agent(s) to spill some slop?

I don't know, man... I've been feeling pretty shitty about my career as a dev lately. And, with each day, thinking if I should try to do something else... Not because "I'm cooked", but because I've lost the passion to do it. All thanks to AI.

And you? What are your thoughts about the AI craze? Are you feeling hyped? down? Nothing changed? I'm curious...

An Introduction to Microservices pt. 6

Bernardo Costa Nascimento — Tue, 24 Aug 2021 17:44:45 +0000

What are we trying to solve?
The Solution: Messaging
Show Me the Code
Bibliography

On part 5, we talked about Messaging. On the last part of this series, we'll talk about how to handle situations when services try to collaborate in a synchronous way, but are not able to: Circuit Breaker.

What are we trying to solve?

As we said before, our application's services often need to collaborate. They can do this asynchronously, e.g. messaging, or they can do it synchronously. When they collaborate synchronously, the called service might be unavailable or with high latency. While the caller service waits for an answer, its resources, such as threads, will be blocked. This can lead to resource exhaustion, which would make the caller unavailable too. This can cascade on our entire application. So, how can we solve this?

The Solution: Circuit Breaker

We can introduce a Circuit Breaker on our services. Each service must implement a proxy, which will work similarly to an electrical circuit. If a call to an specific service fails too many times, the circuit breaker is activated and, for a period of time, all the following calls made to that service will fail automatically. After the period expires, the circuit breaker will allow some requests through. If none of them fail, the circuit breaker is deactivated. Otherwise, the timer will be reset.

By failing fast, we'll avoid that the caller service hangs and wastes precious resources from a call that will, most likely, fail!

Benefits

Services can fail fast, avoiding the wasting of resources.

Drawbacks

It's difficult to choose timeout values without creating false positives or adding excessive latency.

Show Me the Code

Just for the sake of simplicity, I'll show you how to implement the Circuit Breaker pattern only on our API Gateway. If you want to dive deeper on the pattern and implement it between two services, you can head over to the Polly project on Github. Polly is the same library Ocelot uses to implement their Circuit Breaker. Now, let's get to the code!

To implement the Circuit Breaker on our API Gateway, we first need to add a package to the project:

dotnet add package Ocelot.Provider.Polly

This will add the Polly provider to our Gateway. After the installation, open the 'ocelot.json' file. As was the case with our Load Balancer, we'll need to apply our Circuit Breaker in a route per route basis. To do this, add the following to any route you want:

{
    "Routes": [
        {
            // ...
            "QoSOptions": {
                "ExceptionsAllowedBeforeBreaking": 3,
                "DurationOfBreak": 10000,
                "TimeoutValue": 5000
            }
        },
        {
            // ...
        }
    ],
    // ...
}

Let me explain this code. "QoSOptions" stands for "Quality of Service Options", here will define our rules to activate the Circuit Breaker. The first property "ExceptionsAllowedBeforeBreaking" defines the number of times our calls can fail. The "DurationOfBreak" property defines how long the Circuit Breaker will remain active, in milliseconds. Finally, the "TimeoutValue" property defines how long a request can be left hanging without a response, also in milliseconds.

We need to do one more thing to complete the setup: edit our "Startup.cs" file. We need to insert the Polly service to our Gateway:

// Startp.cs
public void ConfigureServices(IServiceCollection services)
{
    // ...
    services.AddOcelot().AddConsul().AddPolly();
    // ...
}

That's it! We're finally done with our series. You now have a basic application that has an API Gateway with Load Balancing, uses a Service Registry with Health Checks to determine services' locations and availability dynamically, asynchronous communication with messaging, and can handle synchronous communication failure gracefully!

Let me know what you think about this series on the comments below and, if you'd like to learn more about microservices, head over to microservices.io!

Bibliography

Microservices Patterns: Examples with Java - Chris Richardson
Circuit Breaker pattern - https://microservices.io/patterns/reliability/circuit-breaker.html
Quality of Service - Ocelot -https://ocelot.readthedocs.io/en/latest/features/qualityofservice.html
Polly - https://github.com/App-vNext/Polly

An Introduction to Microservices pt. 5

Bernardo Costa Nascimento — Tue, 24 Aug 2021 17:44:37 +0000

What are we trying to solve?
The Solution: Messaging
Show Me the Code
Bibliography

On part 4, we discussed how to implement a load balance. Now, we'll talk about one way that services can collaborate between each other. We'll talk about messaging.

For this part of the series, I'll be using the code on my Github repository as a guide.

What are we trying to solve?

When using the microservices architecture, services need to collaborate with each other. They can do this both synchronously and asynchronously.

The synchronous communication is easy. We can, for example, call the REST API of another service. But how can we communicate asynchronously?

The Solution: Messaging

To communicate asynchronously, we need to use the messaging pattern. It implements asynchronous service communication, and can be done in a few ways:

Notifications - One service sends a message, but doesn't expect an answer and doesn't receive one;
Request/Asynchronous Response - One service sends a message and awaits for a response that will come eventually;
Publish/Subscribe - One service publishes a message to one or more services;
Publish/Asynchronous Response - One service sends a message to one or more services, and awaits for responses that will come eventually.

Benefits of Messaging

Loosely runtime coupling since the sending service doesn't need to block, while waiting for a response;
Better availability since the broker stores the messages in a buffer until a consumer is ready to process them;
Support to a variety of communication patterns.

Drawbacks of Messaging

The broker is yet another component to keep track of;
Since the communication is critical, the broker must have a high availability.

Before the Code

We need to quickly talk about two concepts: Aggregates and Domain Events. I won't go in much details about neither one, but these will be important for the messaging pattern and, specially, when deciding the set of services of your application.

Aggregates

Chris Richardson defines as "a cluster of domain objects within a boundary that can be treated as a unit." Now, take my example application. It has a "User" domain object, right? The "User" only has a name and an e-mail address. Imagine that we'd like to store the user's home address. We could create a separate class for it, "Address", which would be a part of our "User" domain object.

It doesn't make sense for us to work with the "Address" without its parent object, "User". So, we call our "Address" class a "Value Object". Our Aggregate, then, is composed of the domain object "User" and the value object "Address". We also can call the "User" class our Aggregate Root.

Working with Aggregates makes our domain model easier to understand, since it groups multiple classes as a single entity. It also makes load, update and delete operations clearer. Finally, it helps us enforce invariants.

Domain Events

Domain Events are very closely related to Aggregates. When something important happens to an Aggregate, e.g. a new Aggregate object is created, it might publish a Domain Event to anyone who might be interested.

Here are a few reasons as to why Domain Events can be useful:

Maintaining data consistency when using sagas (another microservices pattern);
Notifying a service that maintains a replica of the altered data (CQRS, another microservices pattern);
Notifying another application;
Sending user notifications;
Monitoring to check if the application is working as intended;
Analyzing events to model user behavior.

There are a few ways to identify domain events. They are usually defined by the application's requirements, but they can also be defined in a process called "event storming".

Show Me the Code

Now that we've talked about Aggregates and Domain Events, let's begin our implementation!

As I said on the beginning, I'll use my example application here. The code contains: an API Gateway, two simple Web API projects and a docker compose file. The first Web API is a simple CRUD for a "User", which has a name and an e-mail. The second Web API doesn't do anything other than receiving messages and logging what was supposed to happen.

Although the example on the repository is complete, I'll pretend as if it wasn't.

Ok, let's begin. We'll first code our consumer's code.

Consumer

On the "Notification.API" folder (on the "notifications-api" project), we'll create a folder called "Consumers". Next, we'll create an "AbstractConsumer" class, which will hold the basic functionality of our messenger consumers:

// AbstractConsumer.cs
public abstract class AbstractConsumer<T> : BackgroundService
{
  protected IServiceProvider _serviceProvider { get; set; }
  protected IConnection _connection { get; set; }
  protected string Queue { get; set; }
  protected IModel _channel { get; set; }
  protected string _exchange { get; set; }
  protected string _routingKey { get; set; }

  public AbstractConsumer(
    IServiceProvider serviceProvider,
    IConfiguration configuration
  )
  {
    _serviceProvider = serviceProvider;
  }

  protected void InitializeEventBus()
  {
    throw new NotImplementedException();
  }

  protected override Task ExecuteAsync(CancellationToken stoppingToken)
  {
    throw new NotImplementedException();
  }

  protected abstract void LogMessageReceived(T message);

  protected abstract Task SendEmail(T message);
}

The properties "_connection", "Queue", "_channel", "_exchange" and "_routingKey" are all related to our messaging pattern, and I'll explain them in a moment. First, let's quickly go over the "_serviceProvider" property.

We won't actually use it on our example, but if we were actually sending an e-mail to some user, we'd probably need an e-mail service. The "_serviceProvider" would be, then, used to retrieve an instance of our e-mail service to send that e-mail!

Back to our messenger properties. They're all pretty self explanatory: "_connection" will provide our connection to the RabbitMQ server, "Queue" will hold the consumer's queue name, "_channel" will hold our RabbitMQ communication channel, "_exchange" will hold the name of the messenger exchange and, finally, "_routingKey" will hold the routing key of that consumer.

The "InitializeEventBus" method will prepare our consumer to connect to the RabbitMQ server and, well, consume the messages that it's interested in.

// AbstractConsumer.cs
protected void InitializeEventBus()
{
    var connectionFactory = new ConnectionFactory
    {
        HostName = "localhost",
        Port = 5672,
        UserName = "your-user",
        Password = "your-password"
    };

    _connection = connectionFactory.CreateConnection(
        "notifications-service-consumer"
    );

    _channel = _connection.CreateModel();
    _channel.ExchangeDeclare(
        exchange: _exchange,
        type: ExchangeType.Topic,
        durable: false,
        autoDelete: false,
        arguments: null
    );
    _channel.QueueDeclare(
        queue: Queue,
        durable: false,
        exclusive: false,
        autoDelete: false,
        arguments: null
    );
    _channel.QueueBind(
        queue: Queue,
        exchange: _exchange,
        routingKey: _routingKey
    );
}

I'm not going to explain every argument of the called methods. If you want to better understand each of them, take the RabbitMQ tutorial. It's pretty simple and will give you all the information you need!

So, first we open a connection to our RabbitMQ server, then we open the communication channel. After that, we declare our exchange - if it doesn't exist already, it'll be created -, declare our queue - same effect as the exchange declaration - and, finally, we'll bind the queue to the exchange and define its routing key.

Our exchange will act as a router, right? We can make every message go through a specific exchange and use a routing key to determine which queues will receive which messages. That way, the exchange will forward each message to its queue.

Next, we need to actually consume the messages. We'll implement our "ExecuteAsync" method.

// AbstractConsumer.cs
protected override Task ExecuteAsync(CancellationToken stoppingToken)
{
    var consumer = new EventingBasicConsumer(_channel);
    consumer.Received += async (sender, eventArgs) =>
    {
        var contentArray = eventArgs.Body.ToArray();

        var contentString = Encoding.UTF8.GetString(contentArray);

        var message = JsonConvert
            .DeserializeObject<T>(
                contentString
            );

        await SendEmail(message);

        _channel.BasicAck(eventArgs.DeliveryTag, false);
    };

    _channel.BasicConsume(
        queue: Queue,
        autoAck: false,
        consumer: consumer
    );

    return Task.CompletedTask;
}

Our consumer's "ExecuteAsync" method will listen to our communication channel and define a callback function that will be executed when a new message is available. The callback will read the message as a byte array, which we'll use to deserialize it to our "T" object. With the message deserialized, we'll use its contents to send an e-mail and execute an ACK, so that the message can be deleted from the queue.

Finally, we'll tell our channel what queue our consumer will be listening to and return the task as completed.

We can, now, create specific consumers for our messages. In my example application, I created two consumers: UserCreated and UserUpdated. Both classes inherit from our AbstractConsumer class and we only need to implement the "SendEmail" method, which can be different to each class. For example, they can use different templates, so we can create a specific implementation.

Producer

Moving on to our Producer, i.e. the "users-api", we'll begin by creating our connection to the RabbitMQ server. On the "Infra" project, we'll create a folder called "MessageBus" and "RabbitMQClient" class, which implements the "IMessageBusClient" that defines the "Publish" method:

// RabbitMQClient.cs
public class RabbitMQClient : IMessageBusClient
{
    private readonly IConnection _connection;

    public RabbitMQClient()
    {
        var connectionFactory = new ConnectionFactory {
            HostName = "localhost",
            UserName = "root",
            Password = "123456"
        };

        _connection = connectionFactory.CreateConnection(
            "users-service-producer"
        );
    }

    public void Publish(object message, string routingKey, string exchange)
    {
        var channel = _connection.CreateModel();

        var settings = new JsonSerializerSettings
        {
            NullValueHandling = NullValueHandling.Ignore,
            ContractResolver = new CamelCasePropertyNamesContractResolver()
        };

        var payload = JsonConvert.SerializeObject(message, settings);

        Console.WriteLine(payload);

        var body = Encoding.UTF8.GetBytes(payload);

        channel.ExchangeDeclare(
            exchange: exchange,
            type: ExchangeType.Topic,
            durable: false
        );

        Console.WriteLine($"{exchange}->{routingKey}");

        channel.BasicPublish(
            exchange: exchange,
            routingKey: routingKey,
            basicProperties: null,
            body: body
        );
    }
}

As you can see, this code is very similar to our Consumer's code. The basic difference is that we'll be taking a given object, serialize it, convert it to an array of bytes and publish it. We'll publish the message in a specified exchange, with a specific routing key.

Moving on, we'll now apply the Aggregates and Domain Events concepts. We'll begin by creating an "AggregateRoot" class on our "Domain" project, on the "Entities" folder:

// AggregateRoot.cs
public class AggregateRoot
{
    private readonly List<IDomainEvent> _events = new List<IDomainEvent>();
    public Guid Id { get; set; }
    public IEnumerable<IDomainEvent> Events => _events;

    protected void AddEvent(IDomainEvent @event)
    {
        _events.Add(@event);
    }
}

The "AggregateRoot" will contain an array of "IDomainEvents" (Domain/Events/Interfaces), which is an empty interface that creates a common contract for our events. Our "User" class will inherit from the "AggregateRoot".

// User.cs
public class User : AggregateRoot
{
  // ...
}

Now, we need to define a Domain Event:

// UserCreated.cs
public class UserCreated : IDomainEvent
{
    public Guid Id { get; private set; }
    public string FullName { get; private set; }
    public string Email { get; private set; }
    public DateTime CreatedAt { get; private set; }

    public UserCreated(Guid id, string fullName, string email)
    {
        Id = id;
        FullName = fullName;
        Email = email;
        CreatedAt = DateTime.Now;
    }
}

As you can see, the "UserCreated" domain event doesn't do much. It only stores the event information. So, how can we publish this? On our "UserService.cs" class, we'll inject our "RabbitMQClient". By doing this, we can access the publish method we created earlier.

Now, when we create a user, we'll need a method that creates and adds the event to the array we defined earlier. After we ensure that the user was created on the database, we'll iterate over the events array and publish our message!

// User.cs
public static User Create(string fullName, string email)
{
    var user = new User(Guid.NewGuid(), fullName, email);

    user.AddEvent(new UserCreated(user.Id, user.FullName, user.Email));

    return user;
}

// UserService.cs
public UsersService(
    // ...
    IMessageBusClient messageBus,
)
{
    // ...
    _messageBus = messageBus;
}

public Task<UserViewModel> CreateUser(UserInputModel model)
{
    // ...

    var user = User.Create(model.FullName, model.Email);

    user = await _usersRepository.CreateAsync(user);

    foreach(var @event in user.Events)
    {
        var routingKey = "user-created";

        _messageBus.Publish(
            message: @event,
            routingKey: routingKey,
            exchange: "user-service"
        );
    }

    // ...
}

And that's it! We've just created our "UserCreated" event and published it to our RabbitMQ server. If everything is right, we should be able to see on the RabbitMQ GUI that a message was, in fact, published and consumed. To make it even easier to see, you can add a "LogMessageReceived" method to your Consumer!

We are almost done with the series. Next - and last - time, we'll be covering the Circuit Breaker pattern. Until next time!

Bibliography

Microservices Patterns: Examples with Java - Chris Richardson
Messaging pattern - https://microservices.io/patterns/communication-style/messaging.html
RabbitMQ - Get Started - https://www.rabbitmq.com/getstarted.html

An Introduction to Microservices pt. 4

Bernardo Costa Nascimento — Tue, 24 Aug 2021 17:44:28 +0000

What are we trying to solve?
The Solution: Load Balancer
Show Me the Code
Bibliography

On part 3, we talked about Service Registry and Health Checks. Now, we're going to improve our Gateway and take advantage of the possibility of multiple instances given by the Service Registry.

What are we trying to solve?

So far, we've implemented an API Gateway that receives all the requests and routes them accordingly. Also, our services/instances are registered with our Service Registry and the Gateway checks the service's location with it. But how can we make so that our Gateway uses all available instances of a service and no instance becomes overloaded?

The Solution: Load Balancer

To insure that, we need to implement a Load Balancer. This pattern will leverage the requests between available instances of our services. Ocelot gives us a simple way to implement a Load Balancer. Also, it provides a few different algorithms of load balancing:

Round Robin - Imagine that you have three instances of a given service. The algorithm will make so that the first request is handled by instance #1, the second by instance #2, the third by instance #3, the fourth by #1 again, and so on;
Least Connections - Every new request is sent to the instance with the least amount of active connections;
Cookies Sticky Sessions - Uses a cookie to direct all request to a specific instance.

IMPORTANT: Keep in mind that other load balancing solutions might have different algorithms.

Show Me the Code

To implement our Load Balancer, Ocelot makes it very easy. All we need to do is add a new property to our 'ocelot.json' file. This property needs to be added on a route per route basis:

{
  "Routes": [
    {
      // ...
      "LoadBalancerOptions": {
        "Type": "RoundRobin"
      }
    },
    {
      // ...
    }
  ],
  // ..
}

That's it! Our API Gateway can now balance the load between all of our services instances!

On the next article, we'll talk about the Messaging pattern pattern. Until next time.

Bibliography

Ocelot: Load Balancer - https://ocelot.readthedocs.io/en/latest/features/loadbalancer.html#configuration

An Introduction to Microservices pt. 3

Bernardo Costa Nascimento — Tue, 24 Aug 2021 17:44:19 +0000

What are we trying to solve?
The solution: Service Registry & Health Checks
Show Me the Code
- Service Registry
- Health Checks
Bibliography

Last time we talked about API Gateways. Today, we'll talk about two patterns that are very closely related to Gateways and each other: Service Registry and Health Checks.

What are we trying to solve?

When we created our API Gateway, we had to manually define the location (host+port) of the service, right? But imagine the following scenario: a given service needs to be scaled in the X-Axis. The new instances will have different locations and they must be made dynamically available to the clients.

Also, if one of our service instances becomes unavailable at any point, the Gateway must be aware that it can't route requests to that instance while it is unavailable.

The Solution: Service Registry & Health Checks

To solve our problems, we'll be using a combination of two patterns. First, let's discuss the Service Registry pattern.

The Service Registry is, as the name suggests, another service on our ecosystem, that is responsible to register all the services/instances of our application, and keep track of their location. By doing that, our Gateway can, any time that a request arrives, check with the Registry and route the request accordingly. This makes it invisible to the client which instance will receive its request and, as the instances change, the Gateway can always know valid locations! This is known as Server-side discovery.

Figure 1. Server-side discovery

Also, since services must cooperate with each other, they, too, can access the Service Registry to find the location of another service instance. This is known as Client-side discovery.

Figure 2. Client-side discovery

Benefits of Service Registry

Makes it possible to the API Gateway to discover all services'/instances' locations dynamically

Drawbacks of Service Registry

Unless the Service Registry is part of the infrastructure, it's yet another component that must be installed, configured e maintained;
Since the Service Registry is a critical part of the application, it must have a high availability. If it becomes unavailable, the Gateway won't be able to router the requests.

But what if a registered instance becomes unavailable to receive requests? We shouldn't route anything to it, right? This is where our Health Checks pattern comes into play. As we register our services/instances, we'll also provide a way for the Service Registry to check if the registered instances are available to receive requests. If a instance is deemed 'unhealthy', our Gateway won't send any requests to it! That's awesome!

Benefits of Health Check

It creates a way to check the health of the service/instance periodically.

Drawbacks of Health Check

The check might not be comprehensive enough or the instance might fail between health checks, making so that requests are routed to an unavailable service/instance.

Show Me the Code

So, let's begin with the code needed to implement our Service Registry, service registration and health checks.

Service Registry

We'll begin by going the Consul.io website and downloading it. Consul will act as our Service Registry. Just for the purposes of this tutorial, we'll be running Consul in developer mode. After downloading Consul, you can add it to you system PATH, or run it from wherever directory you want it.

consul agent --dev

For our Service Registry, that's it. It's already running. You can check it by accessing https://localhost:8500/.

Now, let's move on to adjust our Gateway, so it'll check with our Registry for valid services/instances locations. We'll begin by editing our 'ocelot.json' file:

{
  "Routes": [
    "DownstreamPathTemplate": "/api/v1/{everything}",
    "DownstreamScheme": "https",
    "UpstreamPathTemplate": "/api/gateway/{everything}",
    "UpstreamHttpMethod": [ "GET", "POST", "PUT", "PATCH", "DELETE" ],
    "ServiceName": "YOUR-SERVICE-NAME"
  ],
  "GlobalConfiguration": {
    "ServiceDiscoveryProvider": {
      "Host": "localhost",
      "Port": 8500,
      "Type": "Consul"
    }
  }
}

As you can see, we've eliminated the "DownstreamHostAndPorts" property and added the "ServiceName" property to our route. Then, we add the "ServiceDiscoveryProvider" property and gave it the host, port and type of our Service Discovery. To complete this setup, we need to add another package to our project:

dotnet add package Ocelot.Provider.Consul

After it installs, just edit the "Startup.cs" file once again and add the following:

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
  // ...
  services.AddOcelot().AddConsul();
  // ...
}

That's it for our Gateway configuration. Now, we need to configure our services. They need to register with Consul, remember? That's what we'll do next.

For any service you'd like to register, you must add the Consul package to it.

dotnet add package Consul

After that, we need to do a couple of things. First, we need to add some needed configuration to our "appsettings.json" (we could put the information directly to the code, but this is better).

"ConsulConfig": {
  "Host": "http://localhost:8500",
  "ServiceName": "YOUR-SERVICE-NAME"
  "ServiceId": "AN-UNIQUE-ID-FOR-EACH-INSTANCE"
}

IMPORTANT: you must use the same "ServiceName" as you did on the routing in "ocelot.json" file. Also, the "ServiceId" is only needed if you plan to use multiple instances of the same service.

After that, we need to add Consul registration as a service on our Web API.

public static IServiceCollection AddConsulConfig(
    this IServiceCollection services,
    IConfiguration configuration
)
{
    services.AddSingleton<IConsulClient, ConsulClient>(
        p => new ConsulClient(
        consulConfig =>
        {
            var address = configuration.GetValue<string>(
                "ConsulConfig:Host"
            );
            consulConfig.Address = new Uri(address);
        }
        )
    );

    return services;
}

This will add the Consul client instance to our Web API. Now, we need to use the client instance to make our registration with Consul.

public static IApplicationBuilder UseConsul(
    this IApplicationBuilder app,
    IConfiguration configuration
)
{
    var consulClient = app.ApplicationServices
        .GetRequiredService<IConsulClient>();

    var logger = app.ApplicationServices
        .GetRequiredService<ILoggerFactory>()
        .CreateLogger("AppExtensions");

    var lifetime = app.ApplicationServices
        .GetRequiredService<IApplicationLifetime>();

    if (!(app.Properties["server.Features"] is FeatureCollection features))
    {
        return app;
    }

    var addresses = features.Get<IServerAddressesFeature>();
    var address = addresses.Addresses.First();

    Console.WriteLine($"address={address}");

    var serviceName = configuration.GetValue<string>(
        "ConsulConfig:ServiceName"
    );

    var serviceId = configuration.GetValue<string>(
        "ConsulConfig:ServiceId"
    );

    var uri = new Uri(address);

    var registration = new AgentServiceRegistration()
    {
        ID = serviceId,
        Name = serviceName,
        Address = $"{uri.Host}",
        Port = uri.Port
    };

    logger.LogInformation("Registering with Consul");

    consulClient.Agent
        .ServiceDeregister(registration.ID)
        .ConfigureAwait(true);

    consulClient.Agent
        .ServiceRegister(registration)
        .ConfigureAwait(true);

    lifetime.ApplicationStopping.Register(() =>
    {
        logger.LogInformation("Unregistering from Consul");
        consulClient.Agent.ServiceDeregister(registration.ID)
            .ConfigureAwait(true);
    });

    return app;
}

The code above removes any previous instances registered with the same ID, registers our service/instance and, finally, tells our Web API that, when it shuts down, it should deregister our service/instance.

And we're done! Now our services are registering with Consul and made available to our API Gateway. Let's begin to implement our health check!

Health Checks

To add our health check, we first need to install the "AspNetCore.HealthChecks.System" package. This will add some basic health check features. If you need to check the connection to your database, you'll need another package. In my repository, I used PostgreSQL, so, in my case, I needed to add the "AspNetCore.HealthChecks.NpgSql" package.

dotnet add package AspNetCore.HealthChecks.System

dotnet add package AspNetCore.HealthChecks.NpgSql

After the installation, we'll add the following code to our "ConfigureServices" method:

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
  // ...
  var builder = services.AddHealthChecks();

  builder.AddProcessAllocatedMemoryHealthCheck(
      500 * 1024 * 1024,
      "Process Memory",
      tags: new[] { "self" }
  );

  builder.AddPrivateMemoryHealthCheck(
      500 * 1024 * 1024,
      "Private memory",
      tags: new[] { "self" }
  );

  builder.AddNpgSql(
      Configuration.GetConnectionString("DefaultConnection"),
      tags: new[] { "service" }
  );
  // ...
}

We've just added some checks for the amount of memory our Web API is consuming (the limit is 500MB for both "Process Memory" and "Private Memory"), and a check for our database connection.

Finally, we need to create some endpoints to access this information. So, we'll add the following to our "Configure" method:

// Startup.cs
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
  app.UseHealthChecks(
    "/health",
    new HealthCheckOptions()
    {
      AllowCachingResponses = false,
      Predicate = r => r.Tags.Contains("self"),
      ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
    }
  );

  app.UseHealthChecks(
    "/ready",
    new HealthCheckOptions()
    {
      AllowCachingResponses = false,
      Predicate = r => r.Tags.Contains("service"),
      ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
    }
  );
  // ...
}

We've just added the endpoints "/health" and "/ready" to our Web API. Now, we need to tell our Service Registry that it should perform checks on the endpoints we've just created.

Let's go back to our "UseConsul" method and add the following:

var registration = new AgentServiceRegistration()
{
    ID = serviceId,
    Name = serviceName,
    Address = $"{uri.Host}",
    Port = uri.Port,
    Checks = [
      new AgentServiceCheck()
      {
        Name = configuration.GetValue<string>("ConsulConfig:ServiceName"),
        HTTP = $"https://{uri.Host}:{uri.Port}/health",
        Interval = TimeSpan.FromSeconds(30),
      },
      new AgentServiceCheck()
      {
        Name = configuration.GetValue<string>("ConsulConfig:ServiceName"),
        HTTP = $"https://{uri.Host}:{uri.Port}/ready",
        Interval = TimeSpan.FromSeconds(30),
      },
    ],
};

That's it! Now our services can register and tell the Service Registry about their health checks. Consul will perform the checks every 30 seconds and, if the check fails, the service will be marked as 'unhealthy' and won't receive any requests until it resolve its problems.

IMPORTANT: if your Consul instance can't perform the checks, try changing the 'https' to 'http' and the port to the 'http' port!

The next topic of the series is Load Balancer. Until next time!

Bibliography

Microservices Patterns: Examples with Java - Chris Richardson
Service registry pattern - https://microservices.io/patterns/service-registry.html
Client-side service discovery pattern - https://microservices.io/patterns/client-side-discovery.html
Server-side service discovery pattern - https://microservices.io/patterns/server-side-discovery.html
Consul by HashiCorp - https://www.consul.io/
Health Check - https://microservices.io/patterns/observability/health-check-api.html
Health checks in ASP.NET Core - https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-5.0

An Introduction to Microservices pt. 2

Bernardo Costa Nascimento — Tue, 24 Aug 2021 17:44:08 +0000

Before we begin

Before we start to talk about our topics, let's take a minute to understand how this will work.

All articles will be divided into three parts:

What are we trying to solve? - I'll give you a bit of context on what sort of problem that particular topic is trying to solve;
The Solution: topic name - I'll talk about the topic and how it'll solve those problems; and
Show Me the Code - I'll go through a simple implementation of that topic and point you to some documentations, should you choose to dive deeper.

What are we trying to solve?
The solution: API Gateways
Show Me the Code
Bibliography

Last time we discussed what are microservices, but now it's time to apply some of its patterns. Today we'll learn about API Gateways!

What are we trying to solve?

Imagine this: you developed an online store that uses microservices. Now, you have a service that returns basic information about your products, another for product availability, another for reviews of products, and so on...
Your front-end wants to access all this information, but it must know ALL of the services addresses. For just a few services, it shouldn't be too hard, but imagine a scenario that your back-end has dozens or maybe hundreds of services. This would be a nightmare!

There's also a few more reasons as to why gateways are important:

The number of instances and their locations might change dynamically. The clients won't know the new address every time a new instance is started;
Instances partitioning might change (Z-Axis scaling) and it should be invisible to your clients;
Services might use a diverse set of protocols, and some of them might not be 'web friendly'.

So, our problem is: How clients of a microservices architecture can access individual services in a simple way? By using API Gateways!

The solution: API Gateways

Gateways act as a Single Point of Entry to you application. All requests will go through the API Gateway and will be routed accordingly.

Figure 1. API Gateway Pattern

Instead of having a single API that fits all your clients' needs, your Gateway can expose a different API to each type of client. Better yet, you can have multiple API Gateways, one for each type of client! That's a variation of the pattern called Back-Ends for Front-Ends.

Figure 2. API Gateway variation: Back-End for Front-Ends

As we'll see in the next article, the Gateway will also have dynamically access to all instances and their address once we implement our Service Registry, but let's not get ahead of ourselves.

Benefits

Let's list the benefits of using an API Gateway:

The client doesn't need to know how the application is partitioned between the services;
The client doesn't need to know about the location (host+port) of the instances of the services;
Provides the best API for each type of client;
A single request to an API Gateway can retrieve data from multiple services;
Simplifies the client by moving the logic of calling multiple services to the Gateway; and
Translates a web protocol to any internal protocols that might be used.

Drawbacks

There are also a couple of drawbacks:

Increases the complexity, since the Gateway becomes another application that must be developed, deployed and maintained; and
Increases the response time, as now all requests must make a new hop through the Gateway.

Show Me the Code

Now that we know what an API Gateway is, what it does, its benefits and drawbacks, let's implement a simple Gateway and see how it works.

Start by creating two projects: one for the API Gateway and another for you Web API. Your Web API can be anything, right? If you need an idea just for this tutorial, you can head over to my Github repository. There you'll also have access to a working example of this entire article series.

Ok, now that you created you Web API, it's time to work on your API Gateway. Start by adding the Ocelot package to your Gateway project:

dotnet add package Ocelot

After the installation is complete, create a new JSON file on the project's root called 'ocelot.json'. Next, add the following lines to it:

{
  "Routes": [
    "DownstreamPathTemplate": "/api/v1/{everything}",
    "DownstreamScheme": "https",
    "DownstreamHostAndPorts": [
      {
        "Host": "localhost",
        "Port": "YOUR-LOCAL-PORT"
      }
    ],
    "UpstreamPathTemplate": "/api/gateway/{everything}",
    "UpstreamHttpMethod": [ "GET", "POST", "PUT", "PATCH", "DELETE" ]
  ],
  "GlobalConfiguration": {}
}

Let's discuss the meaning of each line. Your Gateway, as said before, acts as a router for every request that comes through it. With that in mind, the "Routes" property is where we'll define every routing of our application.

The properties "DownstreamPathTemplate", "DownstreamScheme" and "DownstreamHostAndPorts" define the format of the service routes, the used protocol and the base address respectively. Ocelot also uses some placeholders, e.g. "{everything}", to make it simple to define which routes will be available for each routing option.

The properties "UpstreamPathTemplate" and "UpstreamHttpMethod" define the format of the address that will be available to the external world, and which HTTP methods your route will accept.

So, with this JSON file, everytime someone tries to make a request to "https://localhost:gateway_port/api/gateway/some-resource", Ocelot will route the request to "https://localhost:web_api_port/api/v1/some-resource". Cool, right?

But we're not done yet. We need to configure our Gateway project to read the JSON file and use it to route requests. So, open your "Program.cs" file and edit the "CreateHostBuilder" method:

// Program.cs
public static IWebHostBuilder CreateHostBuilder(
  string[] args) => WebHost.CreateDefaultBuilder(args)
    .ConfigureAppConfiguration(
      (host, config) =>
      {
        config.AddJsonFile("ocelot.json");
      }
    )
    .UseStartup<Startup>();

The line "config.AddJsonFile("ocelot.json")" loads our Ocelot JSON Configuration to our Gateway. We're almost done! We just need to add Ocelot to our services. To do this, we'll edit our "Startup.cs" file:

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
  // ...
  services.AddOcelot();
  // ...
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
  // ...
  app.UseOcelot().Wait();
  // ...
}

Now, we're done! You can start your Web API and your API Gateway and check the results!

I'll wait for you on our next topic: Service Registry.

Bibliography

Microservices Patterns: With examples in Java - Chris Richardson
API gateway pattern - https://microservices.io/patterns/apigateway.html Ocelot Documentation - https://ocelot.readthedocs.io/en/latest/index.html

An Introduction to Microservices pt. 1

Bernardo Costa Nascimento — Tue, 24 Aug 2021 17:43:53 +0000

Before we begin, I'd like to ask for a little bit of patience. I'm not a native English speaker, so, sorry for any errors in advance! I'll try my best s2.

So, I recently made a presentation for my current workplace back-end developers chapter. The subject of the presentation, you guessed it: microservices architecture.

As you can see from the diagram, microservices is a really big topic!

Figure 1. Microservices Patterns - microservices.io

So, my idea is to create a mini series of articles to talk about the following microservices architecture patters:

I'll be using ASP.NET Core to code the examples of these articles, but the ideas will remain the same no matter what language/framework you use, ok?

Now, to be honest, I'd love to talk about more topics, but the truth is: I've just began to study microservices. For now, that's all I feel comfortable to talk about. But, you know, if enough people enjoy this mini series, I'll write about more topics, since I'll continue to study the architecture!

What is the microservices architecture?

Before we dive into the topics, let's talk about what the microservices architecture actually is.

We've all learned about monolithic architectures, right? That's what we're used to. An application that uses a monolithic architecture generates a single executable (for languages like Java, C#, Go, etc...), or has a single directory hierarchy (for languages like Ruby, JavaScript, etc...).

Monolithic architecture aren't inherently bad, ok? It has some benefits, like:

Simple to develop -- IDEs and other tools are focused on building single applications;
Easier to apply radical changes -- You can change the code, the database scheme, build and deploy;
Simple to test -- Developers can write tests for the entire application (unit, integration, E2E...);
Simple to scale -- You can run multiple instances of an application behind a load balancer.

With all that said, why does development, testing, deploy and scaling start to become difficult as the monolithic application grows?

Monolithic Hell

As time goes by, applications get bigger and more complex. Because of this, a series of problems start to happen.

Complexity: as said before, the code base of monolithic applications will grow as more and more features get added to the application. As a result, the code base becomes extremely complex, and no developer will fully understand all the code. This will make adding new feature and/or correcting new bugs more difficult and time consuming. By the end, any architectural style that was initially chose, will become a "big ball of mud";
Slow Development: complexity aside, the size of the code base will also impact the IDE's responsiveness, build and startup times. This makes so that the edit-build-run-test loop takes a long time;
Commits to Deploy: with several developers making commits to the same code base, the build will often be on an improper release state.
If developers try to mitigate the problem by using a strategy like "feature/" branches, they will face a complicated merge process. Therefore, long periods of testing and stabilization will be necessary.
Also, the testing process will be very complex. Since the code base is large and the impact of new changes is never clear, developers must run all tests in the CI. Some tests might even be manual. It's also complicated to diagnose and correct the cause of a failing test;
Difficulty to Scale
In a big monolithic application, some modules might demand more memory, while others might demand more CPU power. Since all the modules belong in the same application, the server configuration might be compromised;
Reliability
It's very hard to fully test a big application. Therefore, bugs will find their way into production. To make things worse, it's difficult to isolate problems. For example, imagine a module has a memory leak, this could bring the entire application down;
Obsolete Stack
As time goes by, the chosen stack might become obsolete. In a monolithic application is very hard to adopt new frameworks and technologies. To make the adoption, the team will have to re-write the entire application, which is very complicated and costly.

Microservices Save the Day

With all the problems that surface with a big monolithic application, we need a solution. Enters: microservices architecture.

The microservices architecture will impact on non-functional requirements, like: maintainability, testability, reliability...

But what are microservices? Let's define it using Martin Abbot's and Michael Fisher's Scale Cube:

Fig 2. The Scale Cube

As you can see, we can scale an application in three axis:

X-Axis: that's when we create new instances of an application, and put them behind a load balancer to handle the increasing load;
Z-Axis: that's when we partition the load between instances of an application. For example, instance #1 will handle usernames from A through H, instance #2 from I through P and instance #3 from R through Z;
Y-Axis: this is the axis that defines microservices. Here, we'll use a process called 'functional decomposition' to break our monolithic application into services. Theses services can also be scaled in the X and Z-axis.

I'm not going to explain the 'functional decomposition' process for two reasons. First, as of yet, I don't know how the process works. I believe that the process is based on the Domain Driven Design (DDD), as you create sub-domain models for you application that define your services. And second, this article is just a simple introduction to microservices.

So, a high-level definition for microservices is:

"An architectural style that functionally decomposes an application into a set of services"
-- Chris Richardson, Microservices Patterns.

Benefits

The benefits of using a microservices architecture include:

Enables continuous delivery and deployment of big and complex applications;
- Since the service is relatively small, automated tests are easier to write and faster to execute;
- Each service can be deployed independently of other services (if changes are local to the service). Therefore, it's easier to deploy new changes to production;
- Allows for teams to be autonomous and loosely coupled, as each team will be responsible, at most, for a few services. This makes development faster.
Services are "small" and easy to maintain;
- With a smaller code base, the IDE's responsiveness is improved, the developers fully understand the service, and each service builds and starts faster, improving productivity;
Services scale independently;
- As said before, each service can be scaled in the X and Z-axis as needed, and the servers can be better suited to each service's needs;
Easy experimentation and adoption of new technologies;
- As developers begin to code a new service, they are free to choose any technology/framework (to a certain degree, it will depend on the company's policy);
- Since the services are relatively small, re-write them using better solutions becomes more practical. If the new technology fails, you can just throw it away without risking the entire project;
Problem isolation
- If a service has a problem - e.g. memory leak - and it goes down, it won't bring down the entire application. Therefore, the impact is much smaller.

Drawbacks

Ok, microservices have a lot of benefits, but what about the drawbacks? Nothing is perfect, right? Right! Microservices have some drawbacks too. Here a few:

It's difficult to determine the correct set of services;
- There isn't a formula to determine the set of services. They must be carefully thought, otherwise you'll end up with a distributed monolith, which has the drawbacks of both microservices and monolithic architecture;
Distributed systems are more complex;
- They need to communicate through some inter process communication mechanism, which are more complicated than simple method calls. They also need to deal with partial failures and high latency;
- Each service has it's own database, that makes it difficult to implement transactions and queries that might cover multiple services. They need to implement sagas to maintain data consistency. Also, they can't recover data using simple queries, they need to implement API Composition or CQRS;
- It introduces the need for a high automation level;
Features that cover multiple services must be carefully deployed;
It's tough to decide when to adopt;
- Consider, for example, a startup. They need to get their product to market ASAP, but microservices architecture is much more complex than building a simple monolithic application.

Conclusion

As we saw, microservices have a lot of benefits and a few drawbacks - as anything does in tech. When you decide to adopt it, you must be very careful to implement it. But for complex applications, it's often the right tool for it.

Now that we've talked about what microservices architecture is, we can begin talking about some of its patterns. On part two, we'll talk about API Gateways. Until next time!

Bibliography

What are microservices? - https://microservices.io/;
Microservices Patterns: With examples in Java - Chris Richardson;

Stoplight/Prism-CLI - Acelerando o desenvolvimento e aumentando a integração

Bernardo Costa Nascimento — Thu, 25 Feb 2021 19:29:22 +0000

Ao desenvolver novas APIs, muitas vezes os desenvolvedores (devs) front-end precisam mockar dados para criar e demonstrar os layouts que estão desenvolvendo. É uma atividade que demanda tempo e, eventualmente, o código será jogado fora. No back-end, as features podem demorar algum tempo para estarem disponíveis e, em caso de mudanças, o dev terá de alterar o código, atualizar os testes, realizar uma nova build e um novo deploy, atividades que demandam tempo. Como podemos otimizar as tarefas do back-end e front-end para que não haja código mockado e novo ciclo de dev-build-deploy? Podemos utilizar a ferramenta Stoplight/Prism-CLI.

Prism permite que devs criem mocks da API com uma base mínima de código no back-end, fazendo com que não seja necessária a criação de mocks – que serão, eventualmente, descartados – no front-end. Ainda, torna possível testar o contrato da API, por meio de um proxy, auxiliando na diminuição de erros após mudanças no código. Por fim, como a ferramenta usa o OpenAPI como base para criação dos mocks e proxies, sua utilização auxilia na criação de documentações mais robustas para as APIs desenvolvidas. Este artigo abordará como utilizar a ferramenta em seus dois modos – mock e proxy – para auxiliar, acelerar e integrar o desenvolvimento front-end e back-end.

Sumário

Instalação do @stoplight/prism-cli
Código back-end & OpenAPI Documentation
Prism Mock Server
Prism Proxy Server
Conclusão

Instalação do @stoplight/prism-cli

Antes de mais nada, precisamos instalar a ferramenta Prism em nosso ambiente de desenvolvimento. A documentação prevê três formas de instalação, mas por motivos de simplicidade, abordaremos apenas o primeiro, que utiliza o NPM para realizar a instalação. Dessa forma, instale a ferramenta utilizando o comando:

# Usando NPM
npm i -g @stoplight/prism-cli

# Usando Yarn
yarn add global @stoplight/prism-cli

Código back-end & OpenAPI Documentation

Com o Prism instalado, podemos iniciar o código back-end. O template de APIs da Wiz já traz um exemplo básico de arquitetura de desenvolvimento de uma API e possui o OpenAPI instalado por default.

As rotas do template possuem algumas tags XML e Annotations, que formarão o JSON responsável por gerar a documentação da API. Na Figura 1, a rota apresenta uma descrição (summary), três códigos de resposta (response) e três schemas para os códigos de respostas gerados (ProducesResponseType).

Figura 1 - Tags XML e Annotations para uma rota da API.

Figura 2 - Documentação gerada pelas tags XML e Annotations no código back-end.

Se pararmos aqui, os exemplos de requisição e resposta, gerados pelo OpenAPI, serão genéricos, como visto na Figura 3.

Figura 3 - Exemplo de resposta genérica gerada pelo OpenAPI.

O Prism é capaz de gerar informações aleatórias para compor as respostas, no entanto como veremos mais adiante, é possível ter maior controle sobre o conteúdo das respostas e, por consequência, definir exemplos que documentarão melhor a API em desenvolvimento.

Para isso, adicionaremos tags XML e Annotations nas ViewModels da API e, caso não existam ViewModels específicas para erros, criaremos classes de exemplo para compor a documentação. A Figura 4 demonstra algumas das tags e Annotations utilizadas para melhor documentar a API. É importante ressaltar que, no caso da Annotation JsonSchemaExtensionData, é necessária a instalação do pacote NjsonSchema.Annotations, que permite adicionar informações que não seriam identificadas pelo OpenAPI.

Ao analisar a Figura 4, as tags example e minimum provavelmente são familiares, pois estão previstas na especificação do OpenAPI. Mas e a tag x-faker?

Prism Mock Server

Como dito anteriormente, o Prism é capaz de gerar mocks de respostas para as requisições feitas ao servidor gerado a partir da descrição do OpenAPI. Essas respostas podem ser estáticas ou dinâmicas. Vamos começar pelas respostas estáticas.

Figura 4 - Exemplos de tags para documentação no OpenAPI.

As respostas estáticas são produzidas a partir dos exemplos informados nas ViewModels da API e serão o default ao iniciar o servidor por meio do comando:

prism mock http://localhost:5001/swagger/v1/swagger.json

## Ou

prism mock path/to/descriptor.json

Ao iniciar o mock server dessa maneira, todas as repostas serão baseadas nos exemplos fornecidos. Caso não haja um exemplo, o Prism gera respostas aleatórias com base nos tipos esperados.

No entanto, a utilização das respostas estáticas pode gerar um viés no front-end, uma vez que as respostas, em um cenário real, são variadas. Então, como podemos gerar respostas aleatórias, mas com algum controle sobre seu conteúdo? É aqui que a tag x-faker vai nos ajudar.

Por baixo dos panos, o Prism utiliza a biblioteca Faker.js para gerar os dados de forma aleatória e, acessando a documentação da biblioteca, vemos que existem dezenas de métodos capazes de gerar respostas aleatórias para diversos contextos. Assim, podemos utilizar a tag x-faker, combinada com os métodos disponibilizados pela API, para imprimir contexto nas respostas. Na Figura 4, por exemplo, o “CEP” é gerado com base no método address.zipCode e, portanto, toda resposta não estática vai gerar um zip code aleatório.

Mas ainda fica uma dúvida: caso exista um exemplo, como o mock server pode gerar respostas dinâmicas? Para isso, basta iniciar o mock server com a flag “-d” ou “--dynamic”:

prism mock -d http://localhost:5001/swagger/v1/swagger.json

Ainda, é possível determinar que apenas uma rota específica gere respostas estáticas ou dinâmicas. Para isso, basta passar a utilizar o header “Prefer dynamic=true/false” em suas requisições. O mesmo header pode ser utilizado mais de uma vez e pode ajudar a controlar, também, o código da resposta gerada. Por exemplo, caso o front-end queira testar um cenário de erro na resposta da API, ele pode criar uma requisição com contrato inválido (faltando um campo obrigatório, por exemplo) ou pode utilizar o header “Prefer code=400” para gerar uma resposta com código 400 (Bad Request) por parte do mock server. Para mais exemplos sobre o header, utilize a documentação do Prism.

Prism Proxy Server

Utilizando o mock server, os devs front-end podem ir desenvolvendo os sites sem a necessidade de um back-end funcional, sendo necessário trocar apenas o endereço base das requisições pelo endereço da API funcional, uma vez que esta esteja disponível (i.e. trocar http://localhost:4010/api/vX/ por https://<projeto>-hml-api.azurewebsites.net/api/vX).

Apesar disso, pequenas mudanças ou erros podem ter ocorrido – tanto no front, quanto no back – e as requisições ou os contratos não estarem de acordo com o esperado. Para testar os contratos, o Prism dispõe de um proxy server.

O proxy server utiliza um descritor do OpenAPI e o endereço da API para validar os contratos de requisição e resposta. Dessa maneira, o usuário pode realizar chamadas à API e verificar se todas as requisições feitas e as respostas geradas batem com o que está definido no descritor, garantido que, uma vez que a API vá para produção, front e back não possuam erros de contrato. O proxy server pode ser iniciado pelo comando:

prism proxy path/to/descriptor.json https://<projeto>-hml-api.azurewebsites.net

Para mais informações sobre o proxy server, acesse a documentação do Prism.

Conclusão

A ferramenta Prism server para auxiliar a abordagem “design-first” para o desenvolvimento de APIs por meio do mock e, uma vez que todas as informações e preparativos estejam nas mãos do time de back-end, o proxy permite testar os contratos criados entre front e back.
Sendo assim, o Prism pode auxiliar na integração entre devs front e back, que terão de chegar a um consenso sobre os contratos, permite que o front desenvolva sem a necessidade de uma API e auxilia o back em uma melhor documentação da API em desenvolvimento.

DEV Community: Bernardo Costa Nascimento

The AI Craze

An Introduction to Microservices pt. 6

Table of Contents

What are we trying to solve?

The Solution: Circuit Breaker

Benefits

Drawbacks

Show Me the Code

Bibliography

An Introduction to Microservices pt. 5

Table of Contents

What are we trying to solve?

The Solution: Messaging

Benefits of Messaging

Drawbacks of Messaging

Before the Code

Aggregates

Domain Events

Show Me the Code

Consumer

Producer

Bibliography

An Introduction to Microservices pt. 4

Table of Contents

What are we trying to solve?

The Solution: Load Balancer

Show Me the Code

Bibliography

An Introduction to Microservices pt. 3

Table of Contents

What are we trying to solve?

The Solution: Service Registry & Health Checks

Benefits of Service Registry

Drawbacks of Service Registry

Benefits of Health Check

Drawbacks of Health Check

Show Me the Code

Service Registry

Health Checks

Bibliography

An Introduction to Microservices pt. 2

Before we begin

Table of Contents

What are we trying to solve?

The solution: API Gateways

Benefits

Drawbacks

Show Me the Code

Bibliography

An Introduction to Microservices pt. 1

What is the microservices architecture?

Monolithic Hell

Microservices Save the Day

Benefits

Drawbacks

Conclusion

Bibliography

Stoplight/Prism-CLI - Acelerando o desenvolvimento e aumentando a integração

Sumário

Instalação do @stoplight/prism-cli

Código back-end & OpenAPI Documentation

Prism Mock Server

Prism Proxy Server

Conclusão