DEV Community: József Sallai

The Most Disappointing Software Development Competition

József Sallai — Wed, 06 Oct 2021 19:57:45 +0000

(Image translation: "Code Without Borders/Limits!")

This is a post that I've been wanting to write for a while to finally get it off my chest, mostly to bring awareness upon something I and two other friends of mine had to experience on a Hungarian software development competition.

First Things First - Who Am I?

Some of you might be interacting with me through this blog post for the first time, so allow me to briefly introduce myself. My name is József Sallai and I am a software engineer with many years of experience in the field of developing scalable, performant, and secure applications. I am also currently a university student at Sapientia Hungarian University of Transylvania where I'm majoring in Information and Computer Science.

This article isn't only about me. It's also about two friends of mine and a government-endorsed company that benefited from our work for practically no cost at all.

What Exactly Is This About?

In winter of 2020, a news article was posted on our university's website about a competition which would allow us to test our abilities in software development and win some very cool prizes. What prizes, you might ask?

Some very cool and expensive prizes, right? One would be a fool for not participating in a competition with prizes like that, especially since the organizers (NISZ, National Infocommunications Services from Hungary), being endorsed by the Hungarian government, seem to be trustworthy.

At least that's what we thought when Daniel, Lehel, and I have signed up for the competition.

What We Had To Do

On signup, we didn't know what we had to build, but judging by how much time we had to complete it and the value of the prizes, we were well aware that it's going to be a rather complex project. Which it turned out to be complex when we were notified about the nature of the app we were supposed to build.

Long story short, we were assigned to build a web application platform that would allow any two users of the app to create sale contracts between each other, fill out the information required by the contract template, digitally sign it, and download it as a PDF. This is merely scratching the surface though since there's many other details and features that we had to keep in mind, however, for the sake of the blog post, this is enough information.

When we signed up, we also had to agree to the terms of the competition, which also stated that the app we're building and its source code will be the property of NISZ, so despite being advertised as an "open-source software development competition", everything we did was proprietary and belonged to NISZ (yes, even if we didn't win anything). Additionally, we were not allowed to deploy the app to our own servers, as that would have immediately disqualified us. Instead, we had to use the web server they've provided to us.

The same document also had a paragraph about the prizes we would receive if we won the competition. Apart from the prizes mentioned earlier, the winning team would have also won a trip to the Hungarian Parliament, insights to how government-managed systems work, and a possibility for an internship at NISZ.

These are all very important things to keep in mind as we progress further in the article.

What We've Built

Our app is called Project Raccoon (which was originally just going to be a codename but it stuck with us). It was a Next.js app written in TypeScript which used TypeORM to communicate with a database of your choice. We've applied the best development practices that we were aware of in terms of designing and structuring the project's code. In total, we've written around 30000 lines of code for this project across multiple months.

I also think it's worth mentioning that during the weeks we've worked on the app, we also had other duties, especially since we are university students. At least half of our day was dedicated to university activities and in the meantime, some of us have also done freelance work to earn some money. Besides, at the time this happened, I was going to driving school to get my license. Despite all of these things keeping us busy, we've managed to push our limits and create the best application we could, even if that meant having to skip classes or working on the app while also being in an online class meeting. I also had to postpone some of the work I was doing for money to make enough time for the competition.

By now you should be able to tell that we've definitely put a lot of effort and dedication into this project. And we think it came out great. We don't often say this about the things we're making, but we were really proud of what we managed to pull off together as a team.

At some point before the competition's deadline, we were asked about the tools we needed to deploy our app. Since this was a Next.js app, you could easily deploy it to a serverless platform and use cloud services in tandem, but to keep things simple, all we asked for was a generic web server that has Node.js and a relational database. Nothing too complicated.

Fast-forward a few weeks and what we got was some sort of shared VPS that we had limited access to. Besides the limited access and the lack of a Node.js runtime in the beginning, the domain we were assigned to pointed to a PHP server.

The Deadline

The (initial) deadline for this project was April 23. The app was ready for the base specification, albeit I do have to admit that, at the time, we were lacking some of the features required by the competition's description. Coincidentally, April 23 was also a day when we had an exam, so we had to be very careful with how we managed our time. In the morning, we got access to the web server and after lots of emailing back and forth asking them to install and reconfigure things on the server, we've managed to get the app up and running on their server. Shortly after we got done, the exam started, so there was a lot of stress and pressure going on that day.

We found out that we were competing against 3 other teams, which, by the time of the deadline, were not ready with their projects. So their deployments were either non-existent or did not work at all. Which might have been one of the reasons the organizers of the competition decided to extend the deadline by a few days (April 27), to make sure the projects are getting completed and we have no issues with the deployment.

We were delighted to hear this, since we noticed a few bugs in the meantime that we were able to fix thanks to the extended deadline.

April 27 came, we have deployed the latest and greatest version of the app to the server provided by NISZ and we went on with our lives, patiently waiting for their feedback on it. In the meantime, some of the other teams were also able to get something deployed, even if it didn't have all the required functionality.

May

After the deadline was extended, there was a strange radio silence on behalf of NISZ. No feedback, nothing has really changed in the apps or their content... We were starting to worry that something isn't right.

Fast-forward to May 6, when they finally replied, telling us that none of the applications had fulfilled all of the requirements of the competition, and as such, they are giving every team one more week to implement the missing features.

During our email exchange with NISZ, they've also congratulated us on our app, saying that they've noticed how much effort went into it and how well it functions and looks. These comments made us more confident that our app will come out victorious and that we will win the competition. They've also told us that if we were to implement the missing features in this extra week, we are guaranteed to win the first prize, however, they doubt we will be able to deliver them in time.

Briefly, the missing functionality was:

A property system, which would allow people to add their properties to a centralized database so they can easily generate a sale contract for them. *)
A digital signature system (we weren't sure if they meant PKCS 12 signatures for PDF or a frontend for signing documents using handwriting, so we did both).
An attestation system, which would ensure that the generated documents are authentic/legitimate.
Adding attachments to a contract.
High-level authentication (which we will talk about later). **)
Adding witnesses and lawyers to a contract.
At least one bonus feature.

Some of the requirements in their email seemed vague to us, so we emailed them and called them via phone to ask for more details. The ones that were vague to us were:

*) "Centralized inventory system", which we assumed meant each user would have their own "inventory" that they can use for generating contracts. We asked them about the way we've envisioned the implementation and all they said was "yes, that sounds good" (paraphrase).
**) "Emelt szintű azonosítás", which basically stands for "higher-level identification". We assumed this meant the authorization flow for citizens which would hit an internal API to verify if the provided personal details were authentic. Once again, we asked them if our logic was what they were referring to, and they replied with "do it the way you think it would work the best".

That may seem like a lot of work for one week, but that never stopped us. We worked hard until the last moment and delivered what we were asked to do...

... or did we?

May 12 came and we've submitted the final version of the application to NISZ' web server, thinking that we did everything that was required by the competition rules. As an added bonus, we've added some unique features to the app that weren't in the original specification:

A localization system, which would allow foreigners to do business in Hungary.
A light/dark mode switch for those who don't want to burn their eyes.
A specification and mock API for the authorization/identification API that the app was supposed to check user data against.
Signature frontend for those who want to add a handwritten signature.
... and probably a few more features that I had forgotten about

We were under the impression that not only did we complete the whole app as requested, but we've also overachieved in terms of user experience and even developer experience.

After we've submitted the app, its documentation, and its source code, it was radio silence again... until May 17, which is when they told us that

Despite the additional week that we gave you, still none of the teams were able to fully finish the application as described in the requirements. However, because we saw that your project was the most developed and required the most time and effort, we will give us a "special prize".

The way they worded it made us realize that the special prize they were referring to was a completely different mysteriously unmentioned prize and NOT any of the three prizes that were initially announced.

In the same email message they've sent on the 17th, they've also told us that we had to create some sort of pitch video for the project, which would describe the team, the app, and contain a brief demonstration of how the app works. The deadline was May 20. Yep, we had to write the script, film everything, record the demonstration, and edit the video in less than 3 days.

But despite the very tight deadline, we still managed to get it done. I wasted my entire birthday (May 19) working on the video, recording and editing everything together, just so we can finish it off and send it to them by midnight.

Once we've done that, they've thanked us for the video and told us that they will be back with more details soon.

The Prize?

A few weeks passed since we've submitted our pitch video. In further exchange, they have also told us that the missing functionality was

the centralized inventory system, the higher-level identification system, as well as better documentation

Two out of those features could have been easily implemented if there was better communication between NISZ and us and they weren't so vague about the requirements. By "centralized inventory system" they were referring to a way for site administrators to see everything that gets added to the website. The second one apparently refers to two-factor authentication... I also need to mention that I've NEVER seen any Hungarian application that would use the term "emelt szintű azonosítás" to refer to two-factor authentication. I've only ever seen "kétlépcsős hitelesítés" or "kétfaktoros hitelesítés".

In fact, if we were to get pedantic, Googling "emelt szintű azonosítás" will only give you results to government websites and nisz.hu. The very first result is from nisz.hu and it refers to a system that has the ability to ensure the authenticity of a user's personal information. So I am very certain that the confusion here is very justified.

Either way, in the grand scheme of things, that is pretty much 2% of the entire project, but for good measure I'll round it up to 5%.

So 95% of the app was complete and fully functional.

95%.

That 5% was the reason we did not win anything other than a special prize that was later revealed to be an e-learning kit worth thousands of Hungarian Forints. For them though, this was nothing but a simple UPDATE query in a database. I would also like to mention that the e-learning kit was actually the 3rd prize for the high school variant of the same competition.

A project that was 95% done to the specification, ~30000 lines of code, many days of work, skipping classes and other duties, skipping celebrating a birthday only to finish a pitch video... and not only is the license of the project currently in a questionable situation, but we also did not receive anything valuable in return.

Oh, and did I mention that the other teams got nothing at all? Even if their applications weren't fully done or didn't function well, I still feel like they deserved to get something for their work.

And of course, the project and its code, as we agreed to when submitting it to their server, belongs to NISZ. We cannot do anything with it (i.e. improve and monetize it) unless we get back our rights to the code. However, I also don't think it's fair that they can break the terms of their own contract at any point in time, so we still want to demand our rights to the code back.

The Small Gift

After a few weeks of being confused about the prize we got, on June 10, NISZ emailed us saying

We want to give you a small gift via post, to express our gratitude for joining the competition.

They never specified what the physical gift they wanted to mail to us was, but since they specifically mentioned that it's a small gift, we assumed it would be t-shirts or mugs, and perhaps a participation diploma.

We've sent them our mailing addresses. They've confirmed that they've received the addresses and that they will mail the gifts to us as soon as possible.

Obviously, we've never received anything via post, nor did they say anything ever since June 10. Color me surprised.

Conclusion

We were, by all intents and purposes, massively screwed over by NISZ, which we assumed to be a trustworthy government-endorsed company. They are about to announce the competition again for 2021, but this time I want to urge everyone to avoid NISZ and this competition as much as possible. If you really want to risk not receiving anything unless you do everything 100% as described in the spec (whatever that means, since they are always very vague about everything), then more power to you, but this should serve as a fair warning for what you're getting yourself into. 99.9% won't do, it has to be 100%.

If anything, this was a learning experience to us. It doesn't matter if a company is endorsed by the government, it doesn't make it any more trustable than a random no-name company that announced a competition. Be careful with who you're collaborating with.

This article was originally posted on my blog.

Managing MongoDB Servers From The Browser Using WebMongo

József Sallai — Sun, 03 May 2020 13:43:13 +0000

MongoDB is an awesome database system and I've always had so much fun working with it, especially paired with ODMs such as Mongoose. Some of my friends that I've introduced to MongoDB, coming from a MySQL background, thought they had finally found Heaven, and while I don't necessarily agree with that hyperbole, I can see why they'd think it's so great. It's fast, easy to learn, very flexible and scalable, and just overall fun to work with.

Another great thing about the MongoDB ecosystem is the existence of MongoDB Atlas, an official Database-as-a-Service solution which is pretty affordable and easy to maintain. I think a good introduction to the serverless architecture is Atlas + Next.js + Vercel (I actually use this stack for some of my own apps too).

However, every now and then, you might want to access your MongoDB server directly. Maybe to inspect some data or to change some stuff, but at some point you just can't fully rely on your app and let it do all the work.

MongoDB Clients

If you can SSH into your server you can easily just run mongo in the terminal and do everything you must do. But sometimes a GUI can be nice because you can better visualize the things you're working with. This is why GUI clients exist. These tools allow you to manage everything on your MongoDB server using a friendly graphical interface. The official desktop app - Compass - is very good for this task, for example.

However, there's a small issue... and that is portability. MongoDB Compass is only available for the desktop, so if you want to have a GUI client on your phone, you have to use third-party apps. Furthermore, if you're moving to a different workstation (for example, your school computer), you'd have to download and install Compass on it, which isn't very effective and might not even work at all (since schools and workplaces usually won't allow you to install new software).

This can be an annoying task especially if you manage multiple servers, since you'd have to find the right connection string for each server and set it up accordingly.

What If...

What if you could easily access, modify, and manage your MongoDB servers directly from your web browser? It would be perfect, since there is pretty much no computer, tablet, or smartphone that doesn't have a web browser*. You could just enter a web address and you'd instantly have access to all your servers.

But doesn't that imply that you'd have to store the admin credentials of your servers on someone's server? What if the web interface you're using has a security breach and someone will gain full access over everyone's connection strings?

As soon as a website has a database with sensitive data and it also has a way to authenticate users, it can become a target for hackers. So, is it really a good idea to use a web service for this after all?

In this sense of things, it's probably not a good idea, especially if you're very security-conscious.

*) don't actually quote me on that

How I Tried To Solve This

The web is a powerful invention that only gets more and more powerful. We can solve a lot of things more easily than we have imagined. This is why one night I was wondering - what if we didn't store anything at all? If we don't store credentials, there's nothing that hackers could break into.

This might sound pretty weird at first. You might be wondering how that would even work. And the answer to that is... well... just save it to the user's device, duh! localStorage is an amazing tool if you handle it correctly and this is what I took advantage of when creating WebMongo - a fast and secure web-based GUI for managing MongoDB servers.

About WebMongo

This is a small passion project of mine with the goal of making a solid web interface for MongoDB without giving up on things like security. It started as an experiment, mainly for me to see if something like this was indeed possible. And sure enough, it is! Even though it's still in beta and could definitely use some more improvements, the web app is in a fairly stable condition right now.

WebMongo takes a different approach on storing and syncing data. Instead of saving your data to a centralized database, it saves it to your browser's local storage. This is convenient because you don't have to worry about someone stealing your credentials, unless someone steals one of your physical devices (in which case your other credentials would probably be at risk too). For syncing, there's an Import/Export feature. The exported file is AES-encrypted with a passphrase that you provide, which means you can save it in a cloud provider of your choice. That way you can access your servers anywhere, anytime.

Here's a list of what WebMongo is capable of doing at this moment:

Add and remove MongoDB servers (or connection strings, rather)
View databases
View, add, modify, and drop collections
View, add, modify, and delete documents
Export the list of your MongoDB servers as a passphrase-protected encrypted file
Lock your session using a passphrase (encrypts the data that's saved in your browser)
One-click "Delete All Data" button to completely get rid of all data (useful if you needed it temporarily, for example, on a shared computer)
PWA for easy installation and quick access
Due to its open-source nature, you can deploy your own instance of WebMongo, making it 100% decentralized

Tech

I won't go in-detail into describing how I made WebMongo, but give you an overview of the stack that I used for it.

Frontend: Sapper (Svelte). A tiny web framework that has always helped me develop stuff quickly.
Backend: Express.js. Express is only used to communicate with your MongoDB server and process your queries. Nothing else. It uses the value of the Connection-String header to figure out how to connect to a server.
Deployment: Vercel. I love serverless architecture and Vercel makes it accessible for everyone. With their nearly unlimited plans and super easy deployment strategy, I can automate a lot of stuff and worry less about everything else. The app deploys automatically every time I push something to the master branch on GitHub.

Open-Source And Self-Hostable

Still don't like the idea of using a MongoDB manager that's hosted on someone else's server? Don't worry! I won't get offended by that and I can totally understand you! WebMongo is completely open-source, which is why you can easily deploy it yourself anywhere you want.

See the repo here: https://github.com/jozsefsallai/webmongo

TL;DR

MongoDB is awesome, but we need a way to make it very easy to access our servers from anywhere.
Storing MongoDB credentials on a remote server is dangerous because it can become a target for hackers.
WebMongo is an open-source, fast, and secure web UI for MongoDB that uses a different approach for this by saving all data on the user's computer and using encrypted exporting/importing as a sync method.

Conclusion

This project is something I'm really proud of and I'm looking forward to making it as great as I can. What are your thoughts, suggestions, questions, or bug reports? WebMongo is currently still in beta, so everyone's input would be greatly helpful! :)

You can access the production app here: https://webmongo.now.sh.

Creating Fast APIs In Go Using Fiber

József Sallai — Tue, 07 Apr 2020 16:41:46 +0000

During my career as a software engineer, I've made several APIs in different languages and frameworks. I've used Flask, Falcon, and Django (Python), Laravel (PHP), Rails (Ruby), but my all time favorite web framework is Express (Node.js). It's performant, flexible, and very fun to use. I also really like Koa, which is a successor to Express, made by the guys behind Express. I think it's safe to say that Express became the de facto standard web framework among Node.js developers.

However, there's another programming language I absolutely love, and that is Go. It's a performant, cross-platform, and fun language that I keep recommending to everyone who wants to learn a C-like language but doesn't feel ready for the complexity of C/C++ and the like. Go is mature enough to be used in production environments, which is why many companies - large and small - use it to develop their infrastructure.

Just like in the case of most modern programming languages, Go also has lots of community-maintained web frameworks (such as Gin, Buffalo, or Fasthttp). However, the framework I've discovered recently and really like ever since is Fiber.

Fiber is a web framework that is very similar to Express, which makes it a perfect choice for any Node.js developer that decides to delve into the land of gophers. The framework is a well-designed wrapper around another framework - Fasthttp - which is considered to be one of the fastest web frameworks written in Go. Overall, these are the main advantages of Fiber:

Express-like syntax
Highly performant, thanks to the underlying Fasthttp framework
Zero memory allocation
Easy to learn, especially if you've used Express or Koa before
Easy to write unit tests for, thanks to the built-in Test method

In this article, we're gonna build the API for a todo app using Fiber and MongoDB.

Prerequisites

The very first thing we need to make sure of is that we have all our dependencies ready. We're of course going to need to have Go (1.11 or later) installed on our machine. We'll also need a MongoDB server running on our machine (or you could use MongoDB Atlas). Make sure to create a database called todos. I'm not going to go into how to install and configure these, since it's pretty straightforward, so we can focus on the Go stuff!

Once we have our stuff ready, we're ready to Go! Let's first create a directory for our project and initialize a Go module:

mkdir tasks-api
cd tasks-api
go mod init github.com/yourusername/tasks-api

Once the module is ready, we need to install our project's Go dependencies. Since we've created a module, Go will add these dependencies to the go.mod file.

go get github.com/gofiber/fiber
go get github.com/Kamva/mgm/v2
go get go.mongodb.org/mongo-driver

The first dependency is obviously the Fiber web framework, the second one is a MongoDB ODM for Go, and the third one is the official MongoDB driver for Go. Once these steps are done, we can start writing some code!

The Directory Structure

Our todo API will have the following directory structure:

.
├── controllers
│   └── TodoController.go
├── go.mod
├── go.sum
├── models
│   └── Todo.go
└── server.go

2 directories, 5 files

The controllers directory will contain the controllers for each route or middleware that we're going to define in our Fiber app. For the sake of organization, it's recommended that you separate your controllers based on the model you're working with. This doesn't really make sense now, since we only have one model - the Todo model, but our application might scale in the future and include things like users and sessions.

The models directory contains the definitions of our models. As I said in the previous paragraph, our application currently only has one model, but if our app also had authentication/users, that would require a separate model.

server.go is the main entry point of our application. This is where we define our routes, middlewares, initialize our MongoDB connection, and start the server. In larger applications, I'd split these steps in separate files, again, for the sake of organization, but I feel like that's not necessary for such a small application right now.

The Todo Model

MGM is a MongoDB object-document mapper, which means it contains object definitions and methods that make it easy to read and mutate data in our MongoDB database.

Our Todo model should be straightforward: it should contain the title of the todo, a description, and a boolean that specifies whether the todo is done or still pending.

In our models folder, create a file called Todo.go. Since this file is inside of the models folder, it means that the name of the Go package it belongs to will be models. Let's start by defining our package and importing the MGM dependency:

package models

import (
    "github.com/Kamva/mgm/v2"
)

Now, we can specify and export the Todo model by defining it as a struct-like type. Remember that in Go, a variable, type definition, or function will only be exported if it starts with a capital letter, so make sure to write Todo and not todo when defining your model!

// Todo is the model that defines a todo entry
type Todo struct {
    mgm.DefaultModel `bson:",inline"`
    Title            string `json:"title" bson:"title"`
    Description      string `json:"description" bson:"description"`
    Done             bool   `json:"done" bson:"done"`
}

At the beginning of the model's definition, we "inherit" from MGM's DefaultModel interface, which allows us to use the methods and properties that apply to any MongoDB model (such as the _id, created_at, and updated_at fields). Once that is done, we can define our fields.

To make things a bit cleaner, we can write a wrapper function that creates a new Todo object for us. We can use something like this:

// CreateTodo is a wrapper that creates a new todo entry
func CreateTodo(title, description string) *Todo {
    return &Todo{
        Title:       title,
        Description: description,
        Done:        false,
    }
}

This function takes a title and a description as parameters, and returns a pointer to a Todo struct that contains the specified data. You can go very creative and customize these wrappers as your application scales.

The Controllers

This is where we define functions that we can use as fallbacks in the Fiber route and middleware definitions. Our app doesn't have any middlewares, so here's a list of all the routes that we'll need:

GET /api/todos - lists all todos in the database
GET /api/todos/:id - retrieves a todo based on its ID
POST /api/todos - creates a Todo object and adds it to the database
PATCH /api/todos/:id - changes the Done property of a todo based on its ID
DELETE /api/todos/:id - deletes a todo based on its ID

Let's create a file called TodoController.go inside of the controllers directory and define the package as well as its imports:

package controllers

import (
    "github.com/Kamva/mgm/v2"
    "github.com/gofiber/fiber"
    "github.com/yourusername/tasks-api/models"
    "go.mongodb.org/mongo-driver/bson"
)

Don't forget to replace github.com/yourusername/tasks-api with the name of your module (that you provided when you ran go mod init).

Now that we have that out of the way, we can start defining the controllers for our routes. Let's start with the GET /api/todos route.

GET all todos

Since every controller will be a callback function that we'll pass as a second parameter to our route definitions, we need to make sure our function works like what Fiber expects in a route definition. Our function accepts one parameter (the request context) and should not return anything:

// GetAllTodos - GET /api/todos
func GetAllTodos(ctx *fiber.Ctx) {
    // TODO: implement
}

(note: the comment above the function's name doesn't have to look like that, I just think it makes it easier to instantly know what controller does what)

First we need to access our todos collection. We can do using mgm.Coll():

collection := mgm.Coll(&models.Todo{})

Then we need to initialize an empty array of type models.Todo to store our todos in:

todos := []models.Todo{}

Now we can use collection.SimpleFind() to fetch all entries in the database. The function takes two parameters: the first parameter is the memory address of the variable in which the result should be stored and the second is a filter. If the filter is empty, it will return all entries.

err := collection.SimpleFind(&todos, bson.D{})
if err != nil {
    ctx.Status(500).JSON(fiber.Map{
        "ok":    false,
        "error": err.Error(),
    })
    return // necessary, or else the controller will continue
}

You'll notice that we've done some error checking. If for some reason, the MongoDB driver can't access the collection's items (i.e. connection issues, non-existing database), it will set the HTTP status of the response to 500 (Internal Server Error) and will return a JSON object that contains the error message returned by the driver. Notice how we used fiber.Map to send a JSON response. This is very handy! Here's how the error handler would look like in Express:

return res.status(500).json({
    ok: false,
    error: err.message
});

You can see how similar they are!

Once the results have been stored, we can return it as JSON to the client:

ctx.JSON(fiber.Map{
    "ok":    true,
    "todos": todos,
})

So our controller looks like this:

// GetAllTodos - GET /api/todos
func GetAllTodos(ctx *fiber.Ctx) {
    collection := mgm.Coll(&models.Todo{})
    todos := []models.Todo{}

    err := collection.SimpleFind(&todos, bson.D{})
    if err != nil {
        ctx.Status(500).JSON(fiber.Map{
            "ok":    false,
            "error": err.Error(),
        })
        return
    }

    ctx.JSON(fiber.Map{
        "ok":    true,
        "todos": todos,
    })
}

GET todo by ID

Each MongoDB document has an automatically assigned, unique ID which we can use to fetch a specific document. Our route looks like this: /api/todos/:id, and thanks to Fiber, we can easily implement a controller for it:

// GetTodoByID - GET /api/todos/:id
func GetTodoByID(ctx *fiber.Ctx) {
    id := ctx.Params("id")

    todo := &models.Todo{}
    collection := mgm.Coll(todo)

    err := collection.FindByID(id, todo)
    if err != nil {
        ctx.Status(404).JSON(fiber.Map{
            "ok":    false,
            "error": "Todo not found.",
        })
        return
    }

    ctx.JSON(fiber.Map{
        "ok":   true,
        "todo": todo,
    })
}

It uses the ctx.Params() method to find the value of the :id parameter and searches in the collection using that ID. If it fails (i.e. doesn't find a document with that ID), it will return a JSON response telling you so, with a 404 HTTP status code.

POST todo to server

When POSTing stuff, there's one question that often crosses the mind of a web developer. How should I accept the incoming data? Using a form? A urlencoded body? JSON? Perhaps, raw text? Well, since we're talking about a REST API, the convention is to accept and send JSON data. Fiber makes it very easy to handle any kind of data however, depending on the Content-Type header:

application/json - parses the body as a JSON object
application/xml - parses an XML document
application/x-www-form-urlencoded - parses a urlencoded string in the body
multipart/form-data - parses a good old form

We want to create a new struct that contains the parameters we need to extract from the request's body. We only need the title and the description of the todo:

params := new(struct {
    Title       string
    Description string
})

This will be empty at first, so it will contain two empty strings. We can then use Fiber's ctx.BodyParser() method to parse the request's body and bind it to our params variable:

ctx.BodyParser(&params)

We can then check if both parameters were provided, and if any of them is missing, we can return an error with an HTTP status code of 400 (Bad Request):

if len(params.Title) == 0 || len(params.Description) == 0 {
    ctx.Status(400).JSON(fiber.Map{
        "ok":    false,
        "error": "Title or description not specified.",
    })
    return
}

Once that's done, we can create our todo using our helper function and then return it to the client:

todo := models.CreateTodo(params.Title, params.Description)
err := mgm.Coll(todo).Create(todo)
if err != nil {
    ctx.Status(500).JSON(fiber.Map{
        "ok":    false,
        "error": err.Error(),
    })
    return
}

ctx.JSON(fiber.Map{
    "ok":   true,
    "todo": todo,
})

Here's the controller in its entirety:

// CreateTodo - POST /api/todos
func CreateTodo(ctx *fiber.Ctx) {
    params := new(struct {
        Title       string
        Description string
    })

    ctx.BodyParser(&params)

    if len(params.Title) == 0 || len(params.Description) == 0 {
        ctx.Status(400).JSON(fiber.Map{
            "ok":    false,
            "error": "Title or description not specified.",
        })
        return
    }

    todo := models.CreateTodo(params.Title, params.Description)
    err := mgm.Coll(todo).Create(todo)
    if err != nil {
        ctx.Status(500).JSON(fiber.Map{
            "ok":    false,
            "error": err.Error(),
        })
        return
    }

    ctx.JSON(fiber.Map{
        "ok":   true,
        "todo": todo,
    })
}

PATCH a todo to change its status

The general idea behind the PATCH /api/todos/:id route is to get the todo by ID, change the value of the Done property to the opposite of the current value, save the document, and then return the modified document to the user.

You can pretty much copy and paste the contents of the GetTodoByID() controller and add this before the last step:

todo.Done = !todo.Done

err = collection.Update(todo)
if err != nil {
    ctx.Status(500).JSON(fiber.Map{
        "ok":    false,
        "error": err.Error(),
    })
    return
}

Here's the final controller:

// ToggleTodoStatus - PATCH /api/todos/:id
func ToggleTodoStatus(ctx *fiber.Ctx) {
    id := ctx.Params("id")

    todo := &models.Todo{}
    collection := mgm.Coll(todo)

    err := collection.FindByID(id, todo)
    if err != nil {
        ctx.Status(404).JSON(fiber.Map{
            "ok":    false,
            "error": "Todo not found.",
        })
        return
    }

    todo.Done = !todo.Done

    err = collection.Update(todo)
    if err != nil {
        ctx.Status(500).JSON(fiber.Map{
            "ok":    false,
            "error": err.Error(),
        })
        return
    }

    ctx.JSON(fiber.Map{
        "ok":   true,
        "todo": todo,
    })
}

DELETE a todo

The DELETE /api/todos/:id controller is also very similar, I don't think it needs any special explanation:

// DeleteTodo - DELETE /api/todos/:id
func DeleteTodo(ctx *fiber.Ctx) {
    id := ctx.Params("id")

    todo := &models.Todo{}
    collection := mgm.Coll(todo)

    err := collection.FindByID(id, todo)
    if err != nil {
        ctx.Status(404).JSON(fiber.Map{
            "ok":    false,
            "error": "Todo not found.",
        })
        return
    }

    err = collection.Delete(todo)
    if err != nil {
        ctx.Status(500).JSON(fiber.Map{
            "ok":    false,
            "error": err.Error(),
        })
        return
    }

    ctx.JSON(fiber.Map{
        "ok":   true,
        "todo": todo,
    })
}

And so, our controllers are done! We can move forward to the final step.

The Server

Like I said earlier, server.go will initialize the MongoDB driver and the MGM ODM, define the routes of the app, and start the server. First, let's define the package and its imports:

package main

import (
    "log"
    "os"

    "github.com/Kamva/mgm/v2"
    "github.com/gofiber/fiber"
    "github.com/jozsefsallai/fiber-todo-demo/controllers"
    "go.mongodb.org/mongo-driver/mongo/options"
)

Now we need to define an init() function in which we configure the MongoDB driver. This function will ever only be called once and will run before main(), so we can have all our stuff ready here.

func init() {
    connectionString := os.Getenv("MONGODB_CONNECTION_STRING")
    if len(connectionString) == 0 {
        connectionString = "mongodb://localhost:27017"
    }

    err := mgm.SetDefaultConfig(nil, "todos", options.Client().ApplyURI(connectionString))
    if err != nil {
        log.Fatal(err)
    }
}

We are going to use the MONGODB_CONNECTION_STRING environment variable to specify the connection string used to connect to the MongoDB server and database. If there is no such environment variable, it will default to the local instance of MongoDB.

Since we've already imported all of our controllers, we can just refer to them when defining our routes in the main() function:

func main() {
    app := fiber.New()

    app.Get("/api/todos", controllers.GetAllTodos)
    app.Get("/api/todos/:id", controllers.GetTodoByID)
    app.Post("/api/todos", controllers.CreateTodo)
    app.Patch("/api/todos/:id", controllers.ToggleTodoStatus)
    app.Delete("/api/todos/:id", controllers.DeleteTodo)

    app.Listen(3000)
}

Easy as that! As you can see from this example as well, Fiber really does look like Express, which is a nice touch! By now you should be ready to start your application. Run the following command:

go run server.go

And your server should be listening on port 3000.

Trying Out Your API

You can use a tool such as Insomnia to test your API. First, let's test our POST /api/todos endpoint:

Now that we have data, we can test the other endpoints as well. Here's what the output for GET /api/todos looks like. You can see that it contains an array of all todos:

We can also look for that specific ID and return its data:

And we can try changing its status:

...or maybe even getting rid of it :(

Conclusion

You can see how easy it is to create a REST API in Fiber, so why not go ahead and make something awesome? Or maybe even rewrite one of your existing projects to make use of Go's awesome speed and features? 👀

You can find the app we made in this article on GitHub.

This post was originally published on my blog.

How I've Set Up My Windows Machine As A Development Environment (Without WSL)

József Sallai — Tue, 14 Jan 2020 22:23:20 +0000

(Edit: while this tutorial is still very usable, I no longer use this setup. I've switched to using WSL2 exclusively and it works so much better than WSL1. I recommend you do the same 😊.)

Microsoft's operating system was an important part of my childhood. I grew up using Windows XP, which I really loved to hack to death. At the time, I didn't really know a whole lot about software development and I barely had any resources to learn anything about it since I didn't have internet. I used to have a book on Delphi which is what initially got me interested into writing programs.

This... was a long time ago. After a while, I got more interested into web development and started making static HTML and CSS sites in Notepad++ on my Windows 7 machine. Back in the days, I was scared of Linux. I thought it would be too advanced of an operating system for me. Which might bring the question...

Why Not Just Use Linux?

I love Linux. It's an amazing operating system with a lot of great potential. I used to dual-boot Debian and Windows at some point, so no, I don't use Windows because I don't like Linux or don't know how to use it. I just have a lot more set of tools on Windows now compared to Linux, especially since I work in other domains too, which require me to have apps that don't exist on Linux (such as Adobe products, Ableton, etc.). I also really enjoy gaming and while I do think playing games on Linux is not that bad, I still feel like it's a little more convenient to do it on Windows.

So why do I just not dual boot? I just... don't really feel the need of dual-booting right now. I have all the tools I need on my Windows machine and if I happen to need something that doesn't exist on Windows, I can just use WSL. It's good enough. Dual-booting is tedious and, for someone who needs a lot of disk space for audio and video stuff, it's just space in excess.

Today's Windows Isn't The Past's Windows

Windows had been known among developers to be a very developer-unfriendly operating system for anything that doesn't involve developing for Windows specifically. Today, however, Windows 10 has made a lot of advancements regarding developer experience. I think we can safely say that today's Windows -- heck, even today's Microsoft -- is developer-friendly.

Love them or hate them, I feel like I'm not the only one who thinks that Microsoft has finally started to embrace the developer community, which is a good change in my opinion.

Why Not Use WSL?

WSL is an awesome addition to Windows and I'm glad that Windows ships with a full-fledged Linux kernel now. It's definitely a good step forward. But why do I not use WSL?

It might be just me and the types of tasks I perform, but WSL hangs quite often, especially during Webpack frontend builds. I would love to use WSL more often, but this constant hanging just doesn't really do it for me. (If anyone has suggestions on how to fix this, do let me know though!)

Edit: this is no longer the case in WSL2. It works amazingly and never hanged for me so far. Though some people might not like the idea of running what's basically a stripped-down Linux virtual machine.

So, What's My Developer Environment Setup Look Like?

Programming Languages and Frameworks

Luckily for me, the languages and frameworks I mostly use run great on every platform, including Windows. So all you really have to do is download the Windows release of these tools. I do most of my work with Node.js and in about 96% of the cases I had no trouble working with it under Windows (and when something doesn't work, I check what's wrong and try to fix it myself). Same goes for Go and Dart.

I sometimes face issues when I use Python libraries that depend on a library that can only be found on UNIX-like operating systems. But this is not a big issue for me because most of the Python stuff I do works out of the box on Windows too.

I know I'll probably get a lot of hate for this but when it comes to C++, I use my MinGW setup from ages ago that I've installed for school work. It works well, so I have no reason to complain.

PHP on the other hand, is a little complicated. As you may know, PHP requires that you have a web server backing it. Luckily I don't use PHP much, but for times when I have to use PHP, I have a custom nginx + MariaDB + PHP + Redis setup that I made and will talk about in a bit.

Tools

Here are the developer tools I have installed on my computer:

Git for Windows - allows me to use git and a lot of useful Linux commands such as ssh, ssh-keygen, ls, etc., and most importantly, bash
Visual Studio Code - an excellent code editor made by Microsoft which has never failed me and I consider one of my best friends. For smaller edits, I use nano or vim that comes with Git for Windows
Cmder Mini - this is still my favorite terminal emulator for Windows. It has many awesome and useful features, it's fast, and it looks good. Here's my Cmder setup: https://gist.github.com/jozsefsallai/acd53ea9f4990a1d9c39479fbe6dec6e
Insomnia - slick, fast, and feature-rich alternative to Postman
scoop - a package manager for Windows, mainly geared towards developer tools
nginx (with some custom scripts) - fast web server that I mainly use for PHP projects or as a reverse proxy
MariaDB - community-maintained fork of MySQL. In my experience it works very well on Windows.
Memurai - Windows alternative to Redis. There used to be a Redis client for Windows at some point but I couldn't find a version that's up to date. Memurai works pretty well.

Have Your PATH Sorted Out Well

Windows 10 offers an intuitive way to edit your PATH environment variable. Just go to Search, type "environment variables", and select one of the options that pop up to easily edit all your variables, including PATH.

Once you have the right binaries in your PATH, you are unstoppable... mostly.

This is what my system-level PATH looks like:

...and this is my user-level PATH:

About That PHP Thing...

I said it's complicated but if you have your PATH sorted out well, it's really not that bad. First I make sure that MariaDB and PHP are accessible from the PATH. Then, after downloading the Windows release of nginx, I create a folder called windows-bin. Inside this folder, I place two files:

Warning: I am bad at batch and VB scripts!

File 1 - nginx.bat:

@echo off

set currentDirectory=%cd%

cd C:\dev\nginx
nginx %1 %2

cd %currentDirectory%

Where C:\dev\nginx is the path to your nginx directory. The reason I have to do this is that adding nginx to the PATH is NOT GOOD as nginx.exe will literally only work if you run it from nginx's folder. It's so weird, but this is a workaround.

File 2 - nginx-utils.bat:

@echo off

set currentDirectory=%cd%

if [%~1] == [] (
  echo nginx-utils: Please provide a parameter.
  goto :EOF
)

cd "C:\dev\nginx"

if [%1] == [start] (
  wscript "autostart.vbs"
) else (
  wscript "autostart.vbs" "%1"
)

cd %currentDirectory%

Now, the other file is just some extra commands that I wrote to make it easier to work with nginx and PHP. Again, make sure to change C:\dev\nginx to your nginx directory.

Inside the nginx directory, I also have an autostart.vbs file that I have added to my Startup folder so that nginx and PHP can start when I turn my computer on. It also allows me to run nginx in the background without having to keep an extra console window open. This is the contents of the file:

Set TaskRunner = WScript.CreateObject("WScript.Shell")
NGINXDIR = "C:\dev\nginx"
PHPDIR = "C:\dev\php"

if WScript.Arguments.Count = 0 then
  TaskRunner.CurrentDirectory = NGINXDIR
  TaskRunner.Run "nginx.exe", 0, False
  TaskRunner.CurrentDirectory = PHPDIR
  TaskRunner.Run "php-cgi -b 127.0.0.1:9000 -c php.ini", 0, False
else
  if WScript.Arguments(0) = "stop" then
    TaskRunner.Run "taskkill /F /IM nginx.exe", 0, False
    TaskRunner.Run "taskkill /F /IM php-cgi.exe", 0, False
  elseif WScript.Arguments(0) = "reload-php" then
    TaskRunner.Run "taskkill /F /IM php-cgi.exe", 0, False
    WScript.Sleep 2000
    TaskRunner.CurrentDirectory = PHPDIR
    TaskRunner.Run "php-cgi -b 127.0.0.1:9000 -c php.ini", 0, False
  else
    MsgBox "Invalid parameter: " & WScript.Arguments(0) & " Accepted parameters: stop, reload-php", 0, "Invalid Parameter"
  end if
end if

Why don't you just use XAMPP?
I don't like it :) that, and I can manage my projects better if I have a custom setup.

Conclusion

Development on Windows is really not as bad as it once used to be and I feel like people who don't want to have an extra OS on their computer should try it out. Check if you can work with your tools and frameworks on Windows and make a decision afterwards. But don't forget - Linux (or Mac) will always be a better choice for development! So if you don't have to use programs that are not available on Linux or if you don't play many video games, you should probably stick to Linux (or Mac)!

This post was originally published on my blog.