DEV Community: Victor Basumatary

nil Inteface Values Gotcha

Victor Basumatary — Sun, 13 Jul 2025 17:32:12 +0000

Consider the following program. What do you think will be printed? true or false?

package main

type MyInterface interface {
    DoSomething()
}

type MyInterfaceImplementation struct{}

func (impl *MyInterfaceImplementation) DoSomething() {}

func getMyInterfaceImplementation() *MyInterfaceImplementation {
    return nil
}

func getMyInterface() MyInterface {
    return getMyInterfaceImplementation()
}

func main() {
    fmt.Println(getMyInterface() == nil)
}

If you said true you will be surprised to find out that it's actually false.

Let's print out what's returned by getMyInterface()

func main() {
    fmt.Printf("%v %t\n", getMyInterface(), getMyInterface() == nil)
}

$ <nil> false

That doesn't make any sense! We are getting a nil but the equality check with nil returns false. Why? Let's dig in a little deeper.

func main() {
    fmt.Printf("%#v %t\n", getMyInterface(), getMyInterface() == nil)
}

$ (*main.MyInterfaceImplementation)(nil) false

If you have a variable whose type is an interface that variable is actually storing an interface value, NOT the value that you set it to. The same applies when your function returns a value of an interface type.

In the Go runtime interface values are implemented as tuples, meaning it is made up of two things. The first is the concrete type of the interface (here it is *main.MyInterfaceImplementation) and the second is the concrete value (nil). This is how the Go runtime tracks which interface implementation is being referenced and where the value is in memory, or if it nil.

So getMyInterface() is not returning a nil but rather an interface value whose concrete value is nil. If we want our function to return a nil instead we need to make the following change.

func getMyInterface() MyInterface {
    impl := getMyInterfaceImplementation()

    if impl == nil {
        return nil
    }

    return impl
}

$ <nil> true

Controlled Components Make No Sense

Victor Basumatary — Tue, 10 Oct 2023 14:11:11 +0000

Before I learned what SPA meant and how to build SPAs I built websites using PHP, MySQL and Nginx. It was a simpler time for web development in general - just write some HTML and ship it to the user. Building frontends was simple - just slap together some HTML, CSS and JavaScript until the site looked like what the client asked for and behaved like it. All the hard parts were usually in the backend and even they weren't too hard because PHP comes with batteries included. If the end-user's browser didn't run the JavaScript you wrote it wasn't the end of the world; the website still worked most of the time. The most complex interactions were usually forms that looked really nice and these worked as long as you knew how to click the submit button and had an internet connection.

The first SPA framework I learned was AngularJS and I only learned it because the company I worked for at that time was using it. It took me some time to wrap my head around all the different concepts - controllers, modules, services, two-way data binding, etc. - but once I did it felt great building frontends. AngularJS made it feel trivial to build highly interactive UIs and clients liked the bling factor. It seemed like common sense that this is the way forward for the web development industry - highly interactive UIs made possible with megabytes of JavaScript.

After some time I heard about Angular. Much to everyone's confusion it seemed prudent to the Angular team that Angular 1.x should be called AngularJS and all future versions of Angular should be called Angular. To help simplify matters they made different domains for them - AngularJS is on angularjs.org and Angular is on angular.io. Angular was not backwards compatible with AngularJS which meant that if you wanted to use Angular in an existing project you had to rewrite it. Not nice. Much of the concepts were the same but you now had to use TypeScript. It did come with a nice CLI however.

Now at this point you must be thinking, "I thought this article is about controlled components not making sense. This guy is just talking about Angular and AngularJS." Yes. We're getting there.

One great feature/footgun that came with AngularJS was two-way data binding and very quickly people found out that this feature/footgun is generally a bad idea - you couldn't tell who was changing the data and why and where. What in fact was a good idea is one-way data binding. The classic demo for Angular(JS)'s data-binding was to have a text input and whenever you type something into it the text would appear elsewhere on the page, possibly transformed in some way. This is nothing spectacular in and of itself - anybody can do the same with an event listener or two. What was amazing however was how little code we had to write to achieve it. Everyone fell in love with this.

Note that we've ALWAYS had one-way data binding - the browser keeps track of the state of form controls and we used them during onchange and/or onsubmit. We basically went back to where we came from.

Besides the conversation around Angular and AngularJS's (unfortunate) naming conventions there was another conversation going on - writing applications using Angular(JS) felt like writing applications in Java. Just so much of boilerplate! You had to have a module and a controller and a template and a bunch of other things before you could even print a 'hello, world!' message. Nobody liked that. This was fertile ground for a much more approachable framework. I mean library. Perhaps that's why they named it React - it was a React-ion to Angular(JS)'s boilerplate.

Well whatever the reason for calling it React, everyone did react. To JSX. It took some time for people to succumb to the Stockholm Syndrome but once they did everyone was talking about how great it was, since it brought the template and the behavior to the same place. And you could see all of it at the same time. Unless you're writing a dumb component and the smart component which actually has all the data(-fetching) logic is 5 levels up the component tree.

Since I was going into React from AngularJS it wasn't too hard. Most of the concepts were the same. What was new was the fact that React wrapped ALL the events the browser produced, the JSX produces React Elements and not HTML elements, and there was now a special way to do forms and form controls. Enter controlled components. At first glance you wouldn't think too much about it but after writing a few (dozen) onChange handlers you soon realize that the reason they exist is not because something is broken in HTML or browsers, it's because React has no other way to keep track of the form control's state. Yes you can use refs but that's a React anti-pattern afaik so people generally avoid it.

Forms are hard. Forms in React are painful. A lot of websites are simple forms that collect some data and do something with it. Even Google is essentially just a (small) form. An app I was writing for my previous company was just a very large form. Forms are everywhere and in my, humble, opinion I think that something as common as forms shouldn't be painful. And in my other, humble, opinion a sure fire way to make forms painful is to manage the form's state manually when the browser is already capable of doing it. Just think about that for a moment. Why are we manually managing form state when the browser can already do it, and in fact has been doing it for decades?

React/Modern web development has gone through many phases:

Class components are great.
Class components are terrible.
Shipping the entire React codebase for just that one interactive form in our website is fine.
Actually we should lazy load components and other dependencies.
Hooks are great.
onEffect is the bane of our React applications.
Let's render our React applications twice - once in the server and once in the browser - for that sweet, sweet first contentful paint.

Notice the last point. Doesn't that sound a lot like writing applications with PHP, MySQL and Nginx? Write some JSX, render it to HTML and ship the HTML to the user.

I think it's safe to say that just like how we went back to one-way data binding and how we're going back to the server just returning HTML, we should probably just go back to letting the browser handle form state for us.

You don't need React to build forms; you need HTML.

If you really must have interactivity in your website just use Alpine.

And if you hate page reloads just use HTMX.

You'll soon notice that your websites are still largely useable even if JavaScript is disabled.

Fun fact: Google, who made Angular, don't use it as much.

HTTP Server With Erlang & Cowboy

Victor Basumatary — Fri, 18 Aug 2023 02:27:03 +0000

I am learning Erlang and wanted to build an HTTP server. I read about the in-built inets application and the httpd service and upon using them I quickly realized that they weren't what I wanted.

I want to be able to handle requests myself. The httpd service is great if you want to simply respond to requests with static files but I wanted to respond dynamically. That's when I read about cowboy.

There are a lot of moving pieces and as a beginner I got stuck for a while but I finally was able to create an HTTP server using cowboy. Here's how I did it.

Getting started

Install rebar3 (if you haven't already done so) and create a new erlang application. Let's call it cowboy_hello_world.

rebar3 is a build tool and a package management tool for Erlang.

$ rebar3 new app cowboy_hello_world
$ cd cowboy_hello_world

You will see that there is a rebar.config file and three files under the src/ directory. We will attend to these now.

Before we can use cowboy we need to specify it as a dependency. Add it to your rebar.config file. It should look like this.

{erl_opts, [debug_info]}.
{deps, [
  {cowboy, "2.10.0"}
]}.

{shell, [
  % {config, "config/sys.config"},
    {apps, [cowboy_hello_world]}
]}.

Dependencies aren't automatically installed so you will need to run the following:

$ rebar3 compile

The command above also compiles and builds your code.

Defining the server

Now at this point we can use cowboy and make our own HTTP server. Let's open the src/cowboy_hello_world_app.erl file and start the HTTP server.

-module(cowboy_hello_world_app).

-behaviour(application).

-export([start/2, stop/1]).

start(_StartType, _StartArgs) ->
    Routes = [
        {"/", hello_world_h, []}
    ],

    ServerConfig = [
        {port, 8080}
    ],

    Dispatch = cowboy_router:compile([
        {'_', Routes}
    ]),

    {ok, _} = cowboy:start_clear(httpd, ServerConfig, #{
        env => #{dispatch => Dispatch}
    }),

    cowboy_hello_world_sup:start_link().

stop(_State) ->
    ok.

This is what we are doing:

Defining a list of routes in the Routes variable

a. We have created only one route here.

b. Whenever the user sends a request to "/" the hello_world_h module will be used to handle that request.
Compiling the routes.
Starting a cowboy HTTP server with some server configuration and the routes that we compiled.

a. We have configured our server to use port 8080.

b. Therefore the server will be listening at http://localhost:8080.

Since in the routes definition we have mentioned the hello_world_h module we need to create it. Create a new file src/hello_world_h and fill it up as such.

-module(hello_world_h).

-export([init/2]).

init(Request, Opts) ->
  StatusCode = 200,

  Headers = #{
    <<"content-type">> => <<"text/html">>
  },

  Body = <<"<h1>Hello from cowboy!</h1>">>,

  Response = cowboy_req:reply(StatusCode, Headers, Body, Request),

  {ok, Response, Opts}.

Cowboy will automatically call the init/2 function with the request and expect a response. Here's what we are doing.

Defining the HTTP status code to be 200.

a. A status code of 200 means that the request was processed successfully.
Setting the Content-Type HTTP header to text/html.

a. This is to tell the client that the body of the HTTP response will be an HTML document.
Creating the body of the HTTP response as a binary.
Creating a reply for the request.
Returning that reply.

Let's start our server!

Ok our application is ready! Let's run it.

$ rebar3 compile
$ rebar3 shell

At this point you should be greeted with a long error message. Quite disappointing.

{bad_return,
  {{cowboy_hello_world_app,start,[normal,[]]},
  {'EXIT',
    {noproc,
    {gen_server,call,
      [ranch_sup,
      {start_child,
        {{ranch_listener_sup,httpd},
        {ranch_listener_sup,start_link,      
          [httpd,ranch_tcp,
          #{socket_opts => [{port,8080}],
            connection_type => supervisor},
          cowboy_clear,
          #{env =>
              #{dispatch =>
                [{'_',[],[{[],[],hello_world_h,[]}]}]},
            connection_type => supervisor}]},
        permanent,infinity,supervisor,
        [ranch_listener_sup]}},
      infinity]}}}}}

What does this error message mean? Notice that towards the end of the error message it mentions a ranch_listener_sup. Cowboy depends on the ranch application and ranch must be started before cowboy. To do this we need to make a small change to our src/cowboy_hello_world.app.src file.

{application, cowboy_hello_world,
 [{description, "An OTP application"},
  {vsn, "0.1.0"},
  {registered, []},
  {mod, {cowboy_hello_world_app, []}},
  {applications,
   [kernel,
    stdlib,
    ranch
   ]},
  {env,[]},
  {modules, []},

  {licenses, ["Apache-2.0"]},
  {links, []}
 ]}.

Notice that we have added ranch as an application after kernel and stdlib.

Let's compile and run our application again.

$ rebar3 compile
$ rebar3 shell

You shouldn't see any error messages anymore. Head over to http://localhost:8080 in your browser.

Congratulations! You have created your first HTTP server in Erlang using cowboy!

Why Do You Write Tests?

Victor Basumatary — Mon, 21 Dec 2020 12:24:59 +0000

Testing has pros and cons (what doesn't?) and it only makes sense to do things when their benefits outweigh the costs. Usually at least. I hope I am speaking for most people here.

Anyway why do I write tests? I write it because it makes a nice todolist. Yeah it gives you that confidence that your program works correctly (does it though?) and refactoring becomes a cinch (I totally remember what ThisClassIMade20DaysAgo does) but I do it for the todolist because I'm forgetful.

Usually before I'm writing the code I imagine writing the code and a lot of times while imagining all of this I come across these edge cases. I obviously don't want to forget them so I write the tests for them. Or at least make empty tests with a descriptive enough name and comments.

So why do you write tests?

Why Do Frameworks Suck?

Victor Basumatary — Wed, 16 Dec 2020 14:04:04 +0000

I believe the answer is bias.

Another way to frame the question would be: Why doesn't the framework feel half as elegant and easy-to-use in the real world compared to the quickstart tutorial and example projects?

We gotta take into account the framework developer(s)'s original intention when developing the framework. What problem were they trying to solve? All frameworks are built to solve a problem. A framework to solve a general class of problems? Now that's difficult. Very difficult. As difficult as making a class that's "general". Which is why people just make interfaces. I think.

I remember when I first tried PHP. I was a kid. It was magic. I didn't understand jack except that echo "Hello world"; gives me some output in the browser. And that's all that really mattered. Then I understood it a little better, and had also begun to think about abstract ideas like modularity. That muddied the water. It's been a long time since I felt that magic when I was a kid.

Yes modularity is good, I mean who here likes to go through hundreds of lines of copy-pasted code amirite? But it's bad if the modular code was never designed to solve your problem. Modularity in high level languages usually come in the form of files, classes, namespaces, etc. and they work great. You take it a step further and you get frameworks. The difference is the modularity is no longer general. Facebook was built with PHP. There are many PHP frameworks for building websites, like Laravel. It's not impossible but you'll feel lesser pain building Facebook without a framework than with one. Probably. Please leave comments. Thanks.

Frameworks have a place. They're amazing if every dev using one knows exactly what it was built for and why. Otherwise it's a lot of reading the docs, logs, stackoverflow, and cursing the screen. The beauty about the design of computer languages and their strictness is that they guide you in how to build a program. "NO YOU CAN'T PUT A STRING THERE please use a string type thanks." Frameworks try to emulate that, at a higher level, but imo usually fails spectacularly.

These are just my thoughts. I didn't think everything through. Woke up maybe 2h ago.

Today I Fixed...

Victor Basumatary — Sat, 12 Dec 2020 15:44:44 +0000

I have been working on a website using Laravel 7 for a while. This is the first time I'm building something with Laravel. We use Passport for authentication and of course, API calls are authenticated with it as well.

So the bug I encountered was I wasn't able to call my API. I am using the "auth:api" middleware on my controller to authenticate my API requests. Ideally my request gets through, required I was authenticated and authorized, but instead I was always redirected to the login page.

Initially I thought something was wrong with the middleware but quickly ruled it out. In another part of the website API requests made through just fine. Clearly the middleware was working. Besides it's the middleware's correct behavior to redirect you to the login page if you aren't authenticated.

The only real difference between these two pieces of code was that in one I used axios to make the API request and in the other I used fetch(). The fetch() call was failing.

After a little digging and attentive reading of the docs (this was the hardest part of the whole process for me) I finally figured it out.

Recall that I am using Passport for authentication. It handles API authentication too out of the box. The way it does it is:

When you login an api token is made for you. This is sent back as a cookie (laravel-token by default).
Another cookie called xsrf-token is also sent back.
When making an API request the xsrf-token must be decoded using decodeURIComponent() and sent back as the x-xsrf-token header

axios would do step 3 automatically, I don't know how or why. When you use fetch() you need to do step 3 manually.

Cache Everything

Victor Basumatary — Wed, 09 Sep 2020 17:13:45 +0000

Static websites are great. Here are some of the great things about them:

They're fast
Can be updated and maybe maintained by a web dev beginner
Can be cached
Won't cost you an arm and leg to refactor or redesign

Ok maybe the last point is the result of how well you write and design your codebase and not so much it being a static website.

A lot of people don't seem to like the idea of building static websites. I was once that person because building static websites meant writing the entire website by hand (and I did that a few times). The reason(s) could be different for different people however.

What do we mean by a dynamic website anyway? A lot of times it means having a database and the website/web page being generated using the data in the database. We'll go with that definition.

Let's take a news website for example. What's dynamic in the website? The landing page? Yep. The advertisements section on each page? Yep. The news article itself? Most of the time, no. Anything else? Most probably not. No.

How about an e-commerce website. Landing page? Definitely dynamic. Ads section(s)? Yep. The product details in the product page? Usually no. The reviews section in the product page? Yep.

And I could go on and on. If you still don't get my point, it's this - most content on most websites is static.

How often does the data in the database change? It depends. A news website is probably churning out anywhere between 10s and 100s of articles every day. A really successful news website may be churning out thousands.

A general e-commerce website will probably be adding thousands of new products and reviews to the store by the hour.

A blog may be updated with a new post maybe only once a week.

It depends.

At a glance it does seem like data is changing pretty often but that observation is incorrect. Once a news article is published, it can be updated but how often does that happen? Once a product is added to an e-commerce site, the product details can be updated but how often does that happen? Once a post is written in a blog, it can be updated but how often does it happen?

Do you see it now? Most content is static. At least until it is updated. Which means we can cache most content indefinitely. At least until it is updated.

Why is this observation important? Because money. And performance.

It takes far less resources - mainly CPU cycles and memory - to serve static content than to generate that content. Lesser resource usage spent responding to requests means more resources spent doing actually useful things like generating content that wasn't previously cached. Better resource utilization means your money is being spent efficiently. It may also have the side effect of your web servers being able to serve more requests more quickly.

How can we take advantage of this? I propose this workflow:

Serve cached response for request
If cached response doesn't exist make it, serve it and cache it
Purge cache every time you deploy
Automatically purge cached content when content is updated

Let's use the news website as an example again.

"I want to read XYZ news article". I have a copy of it lying over here. Take it.
"I want to read XYZ news article". I have a co... Actually no I don't. Let me get that news article for you real quick and keep a copy in case you or someone else might want it again.
Oh it seems like the news website is updated. Let's get rid of all our copies of news articles because we don't know if we changed styling or something.
"Oops I've made a typo in this article. Edited." Ok got it thanks. Oh it seems there was a copy of this article lying around. Let's get rid of that.

So essentially what we really want to do most of the time is build a dynamically updated static website rather than a dynamic website.

Victor this is all fine but content lives within HTML documents and all these examples you used have dynamic sections within those documents! News article pages will have ads and maybe comments. Product pages on an e-commerce website will have personalized recommendations and reviews and again, ads. Blogs will display related articles. We can't cache those.

Static content lives within HTML documents that may house dynamic content. Correct.

We cannot cache the HTML document because there are dynamic content sections. Incorrect.

HTML by nature isn't dynamic. But we want dynamism and so we have JavaScript. Any time you see the need for dynamism in your web page, JavaScript is probably the right answer. Probably.

Will the JavaScript that fetches and displays dynamic content on your web page change often? Probably not. So you can cache it, along with the HTML.

Well Ok. But my website is served worldwide and the content differs depending on locale and other variables.

Use HTTP headers like Vary and Accept-Encoding to cache and serve cached content. CDNs are really smart you know.

Victor this requires a lot of effort. All we want to do is make a website and get it done with.

Who doesn't? But I suppose you would like to charge your customers lesser to give yourself that competitive edge and also have a lower running cost, no?

Laravel Relationship Gotcha

Victor Basumatary — Wed, 02 Sep 2020 17:33:43 +0000

Laravel is nice. It lets you define relationships painlessly.

// app/MultipleChoiceQuestion.php
class MultipleChoiceQuestion extends Model
{
    public function answers()
    {
        return $this->hasMany(\App\Answer::class);
    }
}

We can even make relationships in the other direction.

// app/Answer.php
class Answer extends Model
{
    public function question()
    {
        return $this->belongsTo(\App\MultipleChoiceQuestion::class);
    }
}

If we know we're often going to query for the answers to our questions when we query for the questions, it makes sense to eager load them by default.

// app/MultipleChoiceQuestion.php
class MultipleChoiceQuestion extends Model
{
    protected $with = ['answers'];

    public function answers()
    {
        return $this->hasMany(\App\Answer::class);
    }
}

But what happens when we eager load the question on the answer as well?

// app/Answer.php
class Answer extends Model
{
    protected $with = ['question'];

    public function question()
    {
        return $this->belongsTo(\App\MultipleChoiceQuestion::class);
    }
}

Chaos. When you query the question you query for its answers as well which in turn queries for the question they belongs to and...

Your relationships must terminate somewhere.

Laravel Route Parameters & Controller Actions

Victor Basumatary — Wed, 02 Sep 2020 07:13:23 +0000

Laravel is nice. It'll automatically inject the models you need into your controller actions.

// app/Http/Controllers/FilmReviewController.php
class FilmReviewController extends Controller {
    public function edit(Request $request, FilmReview $filmReview)
    {
        //
    }
}

What isn't nice though is that your controller action's parameter names must match the route parameter names. This might catch some of you by surprise. It sure did me.

Let's suppose I defined the following resource route:

// routes/web.php
Route::resource('reviews', 'FilmReviewController');

This will create the following route for the edit action:

PUT /reviews/{review}

I must now update my controller like so:

// Notice I changed $filmReview to $review
public function edit(Request $request, FilmReview $review)
{
    //
}

If the route parameter name and the parameter name of your controller action don't match, the model won't be fetched from your db. So calls like $review->id will always return null.

A Web Developer's Calling.

Victor Basumatary — Fri, 19 Jun 2020 04:33:48 +0000

The WWW came into existence in the early '90s and in less than five years there were 1000s if not 100s of 1000s of web servers already. People were connecting with each other and exchanging information, and learning how to develop with and use this new emerging technology. Everybody knew what a web server was, what HTML and HTTP are. Everybody knew how to build web applications end-to-end. How did we go from that to the modern day roles of frontend, backend, and fullstack devs? I don't know and that's not the point of this article.

I believe that if I call myself a web developer I should be able to build web applications end-to-end. I like to draw a line between web applications and websites. We all know what a website is - HTML, CSS, and JS running in a browser - but what do I mean by web application? Here's how I define it - a web application is a computer program that you may or may not be able to access (directly) over the internet. I suppose many people will find this definition very restrictive as the term is often used to refer to applications built with JavaScript designed to run within a browser as well. I don't like that idea very much so I'll stick with my definition.

So why do I believe that someone who calls themselves a web developer should be able to manage everything? And I do mean everything - making the website, making the web application, managing servers, managing security, managing the database, managing the scaling, etc. If you really think about it your computer programs are only useful if people can use it. People write commands, or click buttons, or fill a form, and your computer program does something useful with that. Input in, output out.

Your web application could be anything - a search engine, a social network, a URL shortener, a blog, anything - but what's the point if people can't use it? That's where websites come in. But you gotta know how to make one, and preferably how to make one well. So what's the point of knowing how to build web applications if you can't build an interface for it?

Following that same train of thought, what's the point of knowing how to build web applications if you don't know how to deploy them and manage them and secure them? You built it so somebody could use it right?

I will not deny that it is quite the task to be familiar, let alone proficient, with any one of these but that should be the goal. I am a web developer, right?

Do You Really Need To Build A Web Server?

Victor Basumatary — Wed, 29 Apr 2020 16:03:37 +0000

Let's begin with a simple definition of a web server:

A web server is a computer program that listens for HTTP requests and responds with corresponding HTTP responses.

When I first started to learn about web development I learned about HTML, CSS, and our good friend JavaScript. Once I was comfortable with those I began reading about PHP and what I could do with it. It seemed interesting. I installed XAMPP on my Windows machine and started learning. All I really knew was I had Apache HTTP Server and somehow this ran my PHP which produced my HTML.

Fast forward a few years and I am often building web applications using Node.js.

$ npm init -y
$ npm install express --save

A lot of people like to use Express.js because it's easy to understand and get started with. I was building web servers day in and day out. I don't intend to bash Express.js or Node.js but when I look back I think I've wasted quite a bit of time.

History

It's the early 1990s and Sir Tim Berners-Lee debuted the World Wide Web. Genius contraption. You have a web browser on the client, a web server somewhere in the network, and these two speak with each other using HTTP over TCP/IP. Back then websites were really simple in that they were all static - hand written HTML and CSS.

In maybe two years after the WWW was debuted hundreds, if not thousands, of web servers were out in the wild - mostly universities. With increased usage came some new requirements. One such requirement was the ability to display data in existing systems as HTML documents. Many people wrote their own web servers to solve this - a request would come in and the web server would compile the information from their systems to produce an HTML document and return it. These solutions worked but they weren't portable.

Soon enough we had a lot of web servers that did their own thing to produce dynamic output. It became apparent that you needed a standard for this and so CGI was born. CGI is short for Common Gateway Interface. Here's how it works:

Web server receives HTTP request.
If response needs to be generated dynamically then run CGI script as a new process. Forward HTTP request and other information to script as environment variables.
CGI script generates the HTTP response, headers and body, and writes it to standard output.
Web server picks up the response from standard output of the CGI script and forwards it.

CGI is simply a protocol. The CGI script can be anything really - a shell script, a C program, a PHP script, anything. The CGI specification used C as an example. This was a game changer because we now had a way to generate dynamic content and how we did it did not depend on the web server. Soon enough web servers like the Apache HTTP Server were born. This was around the mid '90s.

CGI was and is a great idea. It very cleanly decouples the handling of an HTTP request from generating a dynamic HTTP response, and it is also very simple to use. There is one drawback though - it isn't scalable. Whenever you make a request that runs a CGI script, the web server will spawn a new process to run the CGI script. So if you make a 100 requests you are spawning a 100 processes for those requests. More often than not, the overhead of creating processes outweighs the cost of generating the response. Because the lifetime of a process is the lifetime of the request itself, applications built as CGI scripts can't reuse resources like database connections when new requests come in. This makes applications slow as well.

The solution to this problem is rather obvious: instead of making a new process to handle every request, make one process that handles all requests. But how do you do it in this post-CGI world? FastCGI. Here's how FastCGI works:

Web server receives HTTP request.
If response needs to be generated dynamically then forward HTTP request to FastCGI server via Unix domain sockets/named pipes/TCP connection.
FastCGI server generates the HTTP response, headers and body, and sends it back via Unix domain sockets/named pipes/TCP connection.
Web server forwards the HTTP response.

The FastCGI server is your application. Just like in the case of CGI, the web server forwards the HTTP request and other information to your application but it does this over a Unix domain socket, or a named pipe, or a TCP connection instead. This allows your application to stay running even after a request has been served. And again just like in the case of CGI, it doesn't matter how you implement a FastCGI server because FastCGI is just a protocol. FastCGI allowed people to write more efficient applications and have more efficient web servers in general.

CGI and FastCGI are milestones in the development of web technologies. There are other protocols and solutions besides these two but they hold a special status being one of the first solutions for these problems.

Today

The history of the WWW is just around 30 years as of April 2020. Most of the things I talked about in the previous section is recent memory and the ideas discussed are still very relevant. In fact a lot of applications and businesses are still running just fine with them.

Web servers are a little more than the simple definition I use in the beginning of this article. They parse different media types, compress responses, handle auth, do redirects, etc. Web servers like Apache HTTP Server and Nginx are general purpose. They will almost always meet all your requirements, including your performance requirements. They'll serve your static content and if you need to send back dynamic content, you can hook up these web servers to your application using protocols like CGI and FastCGI. So then, do you really need to build your own web server? Do I?

I cannot answer that question because all this while I've been building my own web server using Node.js for every single web application I've made. But I think the answer is no - no, I do not need to build my own web server for the vast majority of applications that I will build in my lifetime.

What do you think? Leave your thoughts as a comment.

Do You Really Need JavaScript?

Victor Basumatary — Tue, 21 Apr 2020 13:46:54 +0000

There's a new JavaScript library/framework released everyday and your node_modules/ directory is only becoming more denser than a black hole, but do you really need that JavaScript running in your website? Do you need JavaScript at all?

The examples that I am going to show you in this article were valid as of 21 April 2020 (Indian Standard Time).

1. swiggy.com and google.com

Swiggy is a food delivery company and application here in India. Here's how the application works with JavaScript enabled.

There's a giant textbox where you enter your location. You are then presented with a list of locations that Swiggy delivers to near you. After selecting an appropriate location you are redirected to a page with a list of restaurants that service the selected location.

Here's what happens when JavaScript is disabled.

You still get the same page as we did with JavaScript enabled but this time Swiggy cannot provide you with a list of suggested delivery locations. Furthermore, you cannot progress further in the app. I'm left hungry if I have JavaScript disabled.

Let's now take a look at how we use Google with JavaScript enabled.

We've all used Google right? Now let's see how Google behaves with JavaScript disabled.

We can still get search results with JavaScript disabled. You may have noticed that Google could not provide you with autocomplete suggestions.

Observations

Google used JavaScript to enhance the experience of searching, with autocomplete suggestions and a better UI, among other things. The core feature of Google - searching - does not depend on whether we have JavaScript enabled or not.

Swiggy relies on JavaScript for its core feature - searching for restaurants around you - and so fails to work when JavaScript is disabled. Does Swiggy really need JavaScript to provide that feature to you? In my opinion, no. On the home page you need to enter a delivery location. This delivery location can be sent to the backend application which can use this along with other information like the IP address to find a list of areas that the customer might be in. The application selects the best choice and presents restaurants around that area along with the other possible locations in case the customer is elsewhere and the application made a mistake.

2. angular.io and reactjs.org

Both Angular and React are used to build Single Page Applications and if you're like me, you keep their documentation open at all times when using them. Here's Angular's and React's websites with JavaScript enabled.

And here they are with JavaScript disabled.

Angular's website only says "This website requires JavaScript" when JavaScript is disabled.

Observations.

Do you really need JavaScript to read some documentation? No. angular.io is completely unusable when JavaScript is disabled.

reactjs.org will do a full page reload when you have JavaScript disabled, otherwise it won't. I'm pretty sure there are other features missing in the website with JavaScript disabled but this is the most glaring one to me. Again, JavaScript was used to only enhance the experience of the user.

Final Words

You don't need JavaScript, for a majority of the applications out there, to deliver the core feature(s) of your application/website. Websites should be built with the assumption that JavaScript is unavailable. If JavaScript is used, it should be used to enhance the user's experience. The experience should not depend on JavaScript being available.

Why Should I Care

Your user may not be able to run JavaScript for a variety of reasons:

The user agent may fail to download the JavaScript after downloading the HTML
The user may have disabled JavaScript
The user agent may not support JavaScript
The user agent may not support the version of JavaScript you used
And a host of other things