DEV Community: Romans Pokrovskis

Turn Swagger Theme to the Dark Mode

Romans Pokrovskis — Fri, 25 Jun 2021 18:43:46 +0000

So you have Swagger integrated into your .NET Core Web API application. Maybe even using my previous guide. And now you want to customize it a bit.

I prefer my UI’s dark. So, when I am presented with a predominantly white screen from the Swagger default theme, I immediately want to change it. Luckily SwaggerUI supports CSS injection.

Here are the tweaks that we need to make:

Changes for `Startup.cs`

Enable support for static files in a `Configure()` method



app.UseStaticFiles();

Add folder structure with custom CSS



wwwroot/
   └──swagger-ui/
      └── SwaggerDark.css

Inject custom CSS

Now we can inject the custom CSS with InjectStylesheet()



app.UseSwaggerUI(c =>
{
    c.SwaggerEndpoint("/swagger/v1/swagger.json", "MyAPI");
    c.InjectStylesheet("/swagger-ui/SwaggerDark.css");
});

You’ve read till the end, so as a thank you here’s the link to the dark theme I just mentioned. It even comes with a dark scroll bar and custom drop-down arrows. https://github.com/Amoenus/SwaggerDark/

Thank you for reading. Consider subscribing and leaving a comment.

How to integrate Swagger UI in a .NET Core Web API application | Amoenus Dev

Romans Pokrovskis — Thu, 03 Sep 2020 15:35:28 +0000

Swagger tooling allows you to generate beautiful API documentation, including a UI to explore and test operations, directly from your routes, controllers and models.
Setting it up is simple but requires some code changes.
To enable swagger integration for your .NET Core Web API project you will need to:

Install Swashbuckle.AspNetCore package from NuGet
Change the Startup.cs class of your Net Core Web API application.
- Add using statement for OpenApiInfo
- Modify Configure(IApplicationBuilder app, IWebHostEnvironment env)
- Modify ConfigureServices(IServiceCollection services)

Changes for `Startup.cs`

Installing Swagger

From your project folder install the Swagger Nuget package (6.1.4 for this instance)

dotnet add package Swashbuckle.AspNetCore --version 6.1.4

Using statement

using Microsoft.OpenApi.Models;

Changes for `ConfigureServices()`

In the ConfigureServices() method you should add

services.AddMvc();
services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo
    {
        Title = "My Awesome API",
        Version = "v1"
    });
});

Changes for `Configure()`

In the Configure() method you should add

app.UseSwagger();
app.UseSwaggerUI(c =>
{
    c.SwaggerEndpoint("/swagger/v1/swagger.json", "My Awesome API V1");
});

I prefer to enable it only for development

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseSwagger();
    app.UseSwaggerUI(c =>
    {
        c.SwaggerEndpoint("/swagger/v1/swagger.json", "My Awesome API V1");
    });
}

Taking it for a spin

After all these changes, we are finally ready to test our new integration.

dotnet run

Navigate to localhost:4200/swagger to see the SwaggerUI

Note: your port may be different

Bonus: Customisation

Now that you have Swagger configured, you might want to change the default theme.
You can learn how to do this in this blog post

Did you have any questions or feedback? Please share them in the comments 🤗

There is no ‘wrong’ way to develop software | Amoenus Dev

Romans Pokrovskis — Fri, 21 Aug 2020 21:27:19 +0000

Today I would like to discuss a topic of 'wrong' code in software development.

I often find developers arguing. It can be about the use of languages, certain patterns or frameworks. Whichever topic it is, each of the arguers is adamant that the opposing approach is 'wrong'.

Those arguments between developers are fierce. People defend their right to develop software in their preferred style. So in situations when the preferred approach is criticized, people start to treat it as a personal attack. This leads to violent responses towards opposing viewpoints.

This often happens because people think that there is only one 'correct' way of doing things. That some people are not educated enough to follow 'the right way'. These personal biases often stem from education and experience.

In reality, there is no such thing as 'wrong' code or 'wrong' approach, even though that term is used a lot in the industry.

The word 'wrong' is completely meaningless when it comes to describing the way code is written. It won't sway either of arguing parties to change their opinion.

Think. Will the opinion of others hinder your ability to solve the problems in your day-to-day life?

Some argue that using specific language, framework or pattern will allow you to make fewer mistakes. This is misguided. It is with real complexity and a high volume of code where real problems arise. Difficulties come from the sheer amount of code and inter-connection within it. Regardless of the language or methodologies you use.

All these patterns, frameworks, etc. help you to bootstrap your project at the very start. They are very helpful when the amount of code is very small.

In contrast, you may have a codebase with the line count approaching 1 million. Even if those lines are written using the most ideal programming language, you still risk having problems. For example, you may have structured your code without proper separation. The code may also have some convoluted logic. The language choice or use of functional programming vs OOP will not save you from problems. When the complexity of the application raises, the significance of those choices approaches zero.

The bigger the project, the more important it becomes to have sensible architecture and separation of elements in your code.

After your code is separated arguing about 'wrong' code becomes a moot point. Each element can be written in a way and in a language that is the most practical for the problem at hand.

I would like to underline once again that views of others no matter how radical are just that - views. It is perfectly normal to not share those viewpoints. At the end of the day, it's irrelevant for the end-user in which language you write your code in. It's also unimportant whether you used the latest version of EF Core.

The application should solve the problem it was designed to solve. It should be delivered on time and have a pleasant and performant user experience. So, there is no point in arguing that the same thing could be achieved with 5 lines in Python.

If you can achieve the result to the satisfaction of the end-user with the technology stack you feel most comfortable with, go for it. Play to your strengths, there is no reason to torture yourself or obsess over which js framework to use.

As a software developer, the value you can bring to the project comes from your ability to strategically apply a slew of tools at your disposal. Your code does not automatically get better when you base it on the newest framework. Upgrade your code, not the framework it runs on.

Technologies evolve at a break-neck speed and what is considered 'new' is ever-changing. So you will find your self in a never-ending loop of constant re-writes.

There are software products that withstood the test of time. They are still popular not because they use a certain language or hot new framework. We use them because they solve a particular problem better than competitors.

So, develop the code in a way you think is appropriate. Approach software development from different viewpoints. Seek out the workflow the most comfortable for you. Stop seeking a silver bullet, the universal approach does not exist.

Did you ever defend a certain viewpoint or were told that the code you wrote was wrong? Share your thoughts in the comments 😤

No method too small

Romans Pokrovskis — Sat, 08 Aug 2020 22:24:33 +0000

This story starts with a call from the 1st line support that users were getting intermittent-production-only error in one of the key application my team were working on.

The problem was that the application was behind the hardened environment that we had no access to.

The only thing we could do is enable logging which in itself took a whole week to get approved. And the result the Developers favourite - NullReferenceException in one of the biggest methods, I've ever seen in my whole career. Needless to say, that was not very helpful and we were no closer to the solution.

What. A. Pain.

Frustrated with the issue and with business breathing down my neck I started slicing this Monster of a method into smaller and smaller chunks. Even if some action was just a one-liner that would not stop me to create a method. At one point I could no longer care for method names resorting to such classics like Method1, FooBar123 and DoStuff.

But. It. Worked.

After the next deployment logs were showing the same NullReferenceException but now the stack trace pointed me to some Method13.

The resulting stack trace finally allowed to pinpoint the issue. The fix then was just a simple null check.

While Dev team who did not appreciate my creative method naming it was obvious to everyone that even that was better than one big blob of code.

It might seem silly to separate the most obvious one-liners into their own methods and sometimes even whole classes but not living through that experience alone is worth it for me.

Did you ever found yourself in a situation where you wished your stack trace was just a little bit more in-depth? Tell me in the comments ^_^

So now go and look at your code and see if you can pepper it with smaller methods so that you stack traces can pave your way to your debugging success.

DEV Community: Romans Pokrovskis

Turn Swagger Theme to the Dark Mode

Changes for Startup.cs

Enable support for static files in a Configure() method

Add folder structure with custom CSS

Inject custom CSS

How to integrate Swagger UI in a .NET Core Web API application | Amoenus Dev

Changes for Startup.cs

Installing Swagger

Using statement

Changes for ConfigureServices()

Changes for Configure()

Taking it for a spin

Bonus: Customisation

There is no ‘wrong’ way to develop software | Amoenus Dev

No method too small

Changes for `Startup.cs`

Enable support for static files in a `Configure()` method

Changes for `Startup.cs`

Changes for `ConfigureServices()`

Changes for `Configure()`