• Web security essentials - Password storage 🔑

    Passwords are a nightmare. If you can offload password storage to a third party provider, you should totally do that. This is not possible a lot of the time (especially if you want to keep your users data to yourself), and in cases like this, you would have to bite the bullet and manage passwords yourself.

    This post will explain password storage in baby steps, so that we can understand why passwords are stored the way they are, and why it’s not as straightforward as it seems.


  • Web security essentials - CORS (Cross origin resource sharing) 🔑

    CORS, or cross origin resource sharing, is one of the most misunderstood concepts of web security. Many know what it is, some know why we need it, and only a few know its limitations.

    This post will go through some of the key concepts of CORS, and emphasize why we need it for the modern web.


  • Web security essentials - SQL Injection 🔑

    So you thought your database was completely safe? Well, for the most part, it actually is. Modern databases have lots of security features to prevent them from being compromised by an attacker. However, even with the most secure database, there is still a way in which a backdoor can be created to compromise it right from the browser!

    This post will explain why SQL injection occurs and how you can prevent it.


  • Web security essentials - XSS 🔑

    XSS(Cross site scripting) attacks are one one of the easiest attacks to perform, and are often the starting point for many attackers looking to compromise your website. Fortunately, they are also one of the easiest to avoid.


  • Building a (very) lightweight web server in docker with busybox and Go 🐻

    One of the things that has always irked me about docker was the size of its images. To give you an example, take a look at my current set of images :

    REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
    golang              onbuild             c2ce4aa3b0ae        13 days ago         672.4 MB
    nginx               latest              4efb2fcdb1ab        3 months ago        183.4 MB
    mongo               latest              282fd552add6        5 months ago        336.1 MB
    node                6.2.2               9121f2a78909        5 months ago        659.4 MB
    node                latest              9121f2a78909        5 months ago        659.4 MB
    hello-world         latest              693bce725149        5 months ago        967 B
    ubuntu              latest              2fa927b5cdd3        5 months ago        122 MB
    mysql               5.5                 2f94d2a2ac89        6 months ago        255.9 MB
    busybox             latest              47bcc53f74dc        8 months ago        1.113 MB

    This is nuts! Most of the base images are upwards of 100MB in size, with many being as large as 600MB! This is aggravated by the fact that any image built on top of these images takes even more space.

    While this is ok with modern systems with many gigabytes of RAM and near unlimited storage space, there might be a crunch if you want to deploy a container on a smaller device (think raspberry pi).

    This post will take you through how to build a fully functioning web server and have the resulting image have a size of lesser than 10MB.


  • React is a framework

    One of the more common phrases you hear anytime you talk about ReactJs is :

    React is not a framework, its a library


    React is just the “V” in “MVC”

    This would have made sense when the React ecosystem was still in its early stages, but it doesn’t hold true anymore. To clarify, nothing about React has fundamentally changed since it first released. What has changed, however, is what people think when they think of React.

    When someone says “We have used React to build our web application”, they almost never mean that React is all they use (contrary to other frameworks like angular or ember). In fact, it’s actually impossible to make a website only with React. This is because the only thing React (and I mean the actual React library) does, is provide a way to represent and update HTML as functions. To actually call and render those functions on a browser, you would need ReactDOM as well.

    The term “React” is now used more to refer to an entire stack of libraries and frameworks rather than the React library alone. The obvious problem with this is, that different people have a different perception of what an ideal React stack is. For me personally, I have sometimes (wrongly) assumed that any website using React is obviously using redux for state management as well.

    Like it or not, the term “React” has now become synonymous with a framework consisting of isolated libraries that have come to support the functionality required in a full fledged framework. This is both a pain in backside, and a blessing in disguise.

    On one hand, if you do not like a certain part of a framework, you normally have to go to great lengths and “go against the grain” to make it work your way. This is totally different in the case of the React “framework” :

    • Don’t like the JSX style routing in react-router ? Just use something else!
    • Don’t like the amount of boilerplate redux comes with? Use something like jumpsuit instead!
    • Don’t like webpack to bundle your modules? Try rollup for a change. Or if you don’t want to use bundles at all, you can still use react with plain old script tags.

    The multitude of choices we have can give us a sense of relief… a sense of security that there are so many libraries out there that there has to be atleast one that does what I want it to do. On the flip side, it can also make you feel like this – and that’s precisely the problem. The amount of libraries out there creates a sort of paradox of choice, because of which we always feel that we could have chosen a better set of libraries to compose our framework. In fact, there are so many choices of libraries out there, that there exists a tool to help you search for the perfect boilerplate to suit your needs. We can even consider each boilerplate project to be its own framework because of the vastly different choices of libraries and convention seen between any two.

    This kind of mental load of choosing the right boilerplate is rarely, if ever, present in other fully featured frameworks… but for some reason, I have always found myself complaining about atleast some part of any of these that I use (After all, no one’s perfect).

    In the end, this post is not a rant about the current state of the React ecosystem, nor one about the lack of choice in other frameworks. It is simply a reflection on the direction the current React ecosystem is headed. React has not only changed the way we think about our code, but has also brought a whole ecosystem along with it, and that is always something to appreciate.


  • Using nightwatch.js to test and take screenshots of your app 🐣

    End to end testing is an often overlooked area of front-end web development. Yet, it is quintessential to making sure your application works the way it should. In this post, we will go through how to seamlessly set up and execute E2E tests using an awesome library called nightwatch.js, and in the process, automate screen capturing your application with each test run.



  • Make your node server faster by caching responses with redis ⏰

    NodeJs is known for its speed with respect to async tasks, but there’s still a lot of potential to make responses from your server even faster, sometimes by orders of magnitude.

    In this post, we are going to go through a brief introduction to the concept of caching, along with a tutorial on how to implement it using redis and an express server.



subscribe via RSS