Flutter’s built in Dialog widgets (also known as popup or modal) such as the AlertDialog are pretty nice, but sometimes you want to build something custom to fit in with your app’s look and feel. In this blog post I will show you how!
What we will build Here’s how my custom dialog looks like (screenshot taken from my RPG app Sound Realms: Mace & Magic). You can see that it differs quite a bit from the standard dialog.
Sometimes you want to have your application running on HTTPS even when testing it out locally. One common approach is to use a self-signed certificate, but this method has some pitfalls - most notably that any browser will frown upon your certificate and start shouting that it is insecure. A more robust approach is to use a certificate generated by a Certificate Authority (CA). How? Enter mkcert, which lets you act as your own CA.
This blog post describes how to implement token-based authentication and authorization using .NET Core 6.0.
The way this works is that when the user is authenticated, a token containing various claims will be stored in the user’s browser. This cookie will be used in subsequent requests, and the claims can be checked on different endpoints in order to provide authorization.
Now let’s get coding!
Inside Startup.cs, add the following to the ConfigureServices(IServiceCollection services) method:
Frontman is a very light-weight NGINX reverse proxy that is deployed using Docker. Its purpose is to act as the entry point to your server. It will redirect incoming traffic to one out of many Docker-based applications running on the same server, based on the hostname in the incoming request.
The rationale behind this is that it enables you to host as many services as you want on the same server, while still only keeping ports 80 and 443 open to the outside world.
A limitation to all web development frameworks is that environment variables has to be injected during build time in order to made be available in the browser. If we have packaged our web application using Docker, that means that we would need to build a different container image for each different environment where we will want to host our application. This is a waste of resources and also introduces a risk of us ending up with a different codebase in our production environment than what we tried out in our QA or test environment.
In this blog post I will describe how you can deploy services on the same server. The server will be fronted by an NGINX instance acting as a reverse proxy responsible for forwarding incoming traffic to the right service.
I will use an EC2 instance on AWS since it has a low monthly cost and I don’t have to worry about hardware maintenance at all, but you can use the same approach for any kind of server.
A common requirement for most serious applications is to be able to produce audit logs: information about which user has accessed what information and when.
In the .NET Core 5.0 API we are building right now, we decided to implement this functionality as a middleware that will automatically be executed upon every request to the API.
We want to log the response actually sent back to the client, so it’s important that we put our new middleware first (or at least very early) in the HTTP request pipeline.
If you have ever run Java inside a lambda function on AWS, you will have noticed the quite significant cold start times that comes with spinning up the JVM environment. In this post, I will discuss some different tricks you can use to minimize these cold start times.
The problem with cold starts arises when there are no “warm” lambda available to handle an incoming request, which usually happens whenever an endpoint experiences a large and sudden spike in traffic.
When setting up a new DynamoDB table, an important decision is to decide what primary key to use. However, it’s not uncommon to not have the full picture up front and therefore it could be hard to make the right decision beforehand. While the official AWS documentation states that “you shouldn’t start designing your schema for DynamoDB until you know the questions it will need to answer”, you often need to experiment to be able to discover what those questions are.
Finding out how much traffic your site has and how your users interact with it is always crucial. Such information will enable you to scale your backend properly, fine-tune the user experience and weed out unused features. Some even go so far as claiming that data is the “gold of our time”. Regardless of the truth of that claim, few can dispute the usefulness of user analytics data.
The go-to solution for most developers is to use Google Analytics (in fact used by 55% of all websites) or some other third party framework.