No-nonsense gRPC guide for the C# developers, Bonus: Interoperability

source code Python interoperability One of the greatest gRPC features is its programming language-neutral nature. You can write gRPC services in C# and access them from other languages. The list includes pretty much everything used in software industry. Conversely, one can connect gRPC clients written in C# to service written in Java, Go, Ruby, you name it. We are going to demonstrate these capabilities using Python. Python is one of the programming languages I really enjoy working with. [Read More]
C#  gRPC  Python 

No-nonsense gRPC guide for the C# developers, Part Three: Streaming

source code Why sometimes we care about the streaming? Many, many micro-services are fundamentally designed as our Calculate service we were able to build in parts one and two. Of course the request and reply messages payload may wary widely, but the pattern is fundamentally the same: Client sends the request message, the service does something with the supplied parameters and sends the response back. But in some cases we have a case which requires a slightly adjusted point of view. [Read More]
C#  gRPC 

No-nonsense gRPC guide for the C# developers, Part Two: Secure service

source code In the previous part, we created a Calculator micro-service which happily performs uncomplicated integer arithmetic. We were able to call that service locally and, hopefully, from the remote computer. The problem though is that our network exchanges are completely unprotected so anyone, with appropriate knowledge and tools, can see what numbers we are trying to multiply. Moreover, the client even cannot be sure that it receives the responses from the valid service, not the one which might be controlled by hackers. [Read More]
C#  gRPC 

No-nonsense gRPC guide for the C# developers, Part One: Basic Service

source code What are we going to talk about? gRPC is a high performance program-to-program communication framework highly suitable to efficiently connect services and, as such, to serve as the foundation for the micro-service architecture. I will not to bore you with the marketing speech, go for the details to the official site A few disclaimers: gRPC, at the moment, does not have the best in-browser support so, if your app lives in the html/javascript universe, the traditional Rest/JSON web services might be a better choice. [Read More]
C#  gRPC 

Micro Django

What is this all about? The Python ecosystem has a few Web application frameworks, most prominent being Flask and Django. They both enjoy their popularity in the community; The general consensus is, Hey, use Flask for the small projects and Django for the large projects. It is true though that with Flask, after the project reaches certain size and complexity, it becomes harder and harder to manage and compose together all 3rd party extensions (which may or may not work) to achieve the desired functionality. [Read More]

Docker for the C# developers Crash Course

What are we going to learn? The goal is to help you achieve practical, working knowledge of Docker so you can build containerized micro-services in C# with relative ease. We are going to use .Net core as it is cross-platform and well supported on Linux-based Docker containers. Having said that, the Windows-based Docker containers exist too, but the haven’t got much traction. Source code The source code is available on github [Read More]
C#  Docker 

Pixies, part 12: Ship It!

Environment values in the browser So we want dynamically specify the api URL in the frontend application running in the container, preferably taken from the environment values. The thing is that the frontend application runs in the browser on the user’s machine. You wouldn’t want (and couldn’t) to hijack the user’s browser to set some environment value there, obviously. So what do we do? Remember, when we made our nginx to listen on the PORT specified with the environment variable - we essentially modified the nginx’s config in the boot. [Read More]

Pixies, part11: Connect the Frontend to the Backend

Where at are we now All right, at this point we have containerized the frontend, the backed and also, for the development purposes, we are using the Postgres container. Sadly, our frontend uses hardcoded data, not the data which the backend is happy to serve us. In this module we are going to fix that. But first, let’s makes sure we have our containers running. In the backend directory do: [Read More]

Pixies, part 10: Serving Static Files

collectstatic Django serves the static files only during the development, i.e. when you run python manage.py runserver. In the production, it is assumed that the static files are being served by something more suitable, like a regular Web server. Having said that, in interest of keeping our backend self-contained, there is a way to serve them by using the package called whitenoise Either way, the first step is to collect the static files from all Django apps we have (remember, our application is made of several Django apps, namely photos, admin and rest_framework). [Read More]

Pixies, part 9: Let's containerize the Backend

Remember when we create a neat compact Docker image for the frontend? Now we are going to do the same thing for the backend. Allowed Hosts Before we start working on the Dockerfile for the backend, we need to take care of one thing. Because we are not going to run the backend app in the Docker in the DEBUG mode, Django will require that the ALLOWED_HOSTS setting is set. This setting is a security measure which prevents certain types of the security attacks. [Read More]