PaaS (Platform as a Service) solutions are everywhere these days, but one that really grabbed my attention recently is  **Dokploy** . It has a Vercel-like user interface but is self-hosted, which is exactly what I was looking for.

Coming from Dokku , having a GUI to manage my apps feels like a huge improvement (I don't hate the CLI, but a GUI is just easier). I liked it so much I decided to switch this very website, Devmystify, from Dokku to Dokploy.

This guide will walk you through setting up Dokploy and deploying an application using Docker Compose.

Before we jump in, I'll assume you already have:

• Your own Droplet: a DigitalOcean VPS works great (that’s what I personally use, you can get one here with $200 in credit ), but a VPS from another provider will be fine as well.
• A domain name: I’ve been using Namecheap for all my domain name needs for years ( click here to get one ).

Now, let’s get started!

Step 1: Install Dokploy on Your Droplet

Installing Dokploy on your VPS is incredibly simple. First, make sure you are logged in as the root user or have sudoprivileges. Then, you can either SSH into your Droplet or use the online terminal from DigitalOcean and run this single command:

curl -sSL <https://dokploy.com/install.sh> | sh

After the command finishes, the installation will prompt you with the link to your Dokploy dashboard:

Congratulations, Dokploy is installed!
Wait 15 seconds for the server to start
Please go to http://<your-ip-from-your-vps>:3000

And just like that, you've successfully installed Dokploy on your Droplet! Pretty easy, right?

Step 2: Initial Dokploy Configuration

Navigate to the link from Step 1, and you'll be taken to the initial setup page. Simply fill out the form to create your Dokploy owner account. Once your account is ready, log in to your new dashboard.

The UI looks really clean. Now, we need to set up a domain and HTTPS for our Dokploy dashboard.

Before you proceed, make sure you've created an A record in your domain's DNS settings that points to your Droplet's IP address. For example, if your domain is example.com, you'll want to point dokploy.example.com to the Droplet's IP.

Go to the Web Server menu on the left side, and you will see the following form👇:

Fill out the form with your domain name and select the HTTPS with Let's Encrypt option. Click Save. Dokploy will handle the rest, but note that it can take a few minutes for the DNS to propagate and the SSL certificate to be issued.

With that done, you now have a secure link to your dashboard.

Step 3: Deploying the app

Now for the fun part! Dokploy offers several ways to deploy services. Let's quickly go over each option:

• Applications: You can use your repository, select a branch and a build path, and then deploy your application.
• Databases: Deploy a single database (Postgres, MySQL, MariaDB, MongoDB, and Redis) of your choice.
• Compose: This is similar to Applications, but you select a docker-compose.yml file instead of a build path.
• Template: Choose and deploy an open-source application from Dokploy's templates, such as n8n or Supabase.

Before we get to the deployment, it's important to understand how Dokploy handles networking. Imagine Dokploy is a big office building. When you deploy each service—like your application or a database—separately through the UI, it's like putting each one on its own private floor. Each floor has its own secure network system, so an app on one floor can't connect to a database on a different floor.

This is why we can't connect a separately deployed database to our app using a simple internal connection string. But if we use a docker-compose.yml file, it's like we're using a single blueprint to place both services on the same floor. The external: true setting is the key that lets your new services use the existing building network, so they can talk to each other and with Dokploy's core services, all within the same secure environment.

Thanks to the Dokploy team for this clear visual explanation!

Here's the docker-compose.yml file we'll use for both our app and database:

services:
  db:
    image: postgres:15
    restart: always
    environment:
      POSTGRES_USER: tutorial-user
      POSTGRES_PASSWORD: tutorial-password
      POSTGRES_DB: tutorial-db
    volumes:
      - tutorial-db:/var/lib/postgresql/data
    networks:
      - dokploy-network

  tutorial-app:
    build:
      context: .
      dockerfile: Dockerfile
    env_file:
      - ./.env
    restart: always
    depends_on:
      - db
    networks:
      - dokploy-network

volumes:
  tutorial-db:

networks:
  dokploy-network:
    external: true

With this setup, your application can connect to the database using the internal connection string:

postgresql://tutorial-user:tutorial-password@db:5432/tutorial-db

With everything prepared, the rest is easy. Simply select your linked GitHub account, choose the repository and branch, and specify the path to your docker-compose.yml file. Then, click Save and Deploy 🚀.

Step 4: Exposing the app

Now that your application is up and running, there's just one step left: making it accessible to the world.

Navigate to the Domains tab. Select the service you want to link to a domain (in our case, the service name is tutorial-app). If you don't have any special configurations, just fill out the form: enter your domain name in the Host field, activate HTTPS with Let's Encrypt, and click Save.

And just like that, you have a live application!

Wrap up

This wasn't a long tutorial because Dokploy makes deploying applications incredibly simple. You get a clean, modern GUI, easy-to-access logs, automatic redeployment on every code push (CI/CD), and many more features out of the box. And since it's self-hosted, it's completely free!

If you want to support the Dokploy team, they also offer a managed service called Dokploy Cloud . It's worth checking out if you're interested. I hope this tutorial demonstrates how easy it is to host your application with Dokploy. If you have any suggestions or questions, feel free to leave a comment below!

This year, it officially received a new set of features: ES2025.

Here are 8 of them, with examples, so you can discover what’s new and maybe bring them into your projects (or not… but hey, it’s always fun to learn something new & shiny).

#1. Promise.try()

Promise.try() is a great new way to deal with inconsistent functions, sometimes found in older or legacy code that you don’t necessarily have control over. By inconsistent, I mean that they sometimes return a value immediately (synchronously), and other times, they return a promise (asynchronously).

This problem forces you to write messy and defensive code like this:

// Imagine a messy, inconsistent function you have no control over
function getProfile(userId) {
	if (userId === 'sync-error') {
		throw new Error('No userId provided.')
	}

	if (userId === 'sync-user') {
		return {name: 'John', id: userId },
	}

	return new Promise((resolve, reject) => {
		setTimeout(() => {
			if (userId === 'async-error') {
			reject(new Error('Server failed to fetch user data'));
			} else {
			resolve({ name: 'Jane', id: userId });
			}
		}, 100);
	});
}

// Here's how you might deal with that function
try {
	const profile = getProfile('sync-user');
	if (profile instanceof Promise) {
		profile.then(data => {
	      console.log('Async success:', data);
	    }).catch(error => {
	      console.error('Async error:', error.message);
	    });
	} else {
		console.log('Sync success:', profile);
	}
} catch (error) {
	console.error('Sync error:', error.message);
}

That’s kind of confusing and hard to maintain. With the new Promise.try(), you can refactor it to this:

// That new helper can handle all the errors the messy 
// function could throw at you.
Promise.try(() => getProfile('async-error'))
  .then(profile => console.log('Success:', profile))
  .catch(error => console.error('Error with async-error:', error.message));

With this new feature, you now have one consistent way to handle a function that could either be synchronous or asynchronous, while allowing for the code to be way more readable and maintainable.

#2. `Set` Methods

Before these new Set methods were introduced, performing set operations in JavaScript was quite tedious, very manual, and overly verbose.

Take a look at this example:

const cookingClub = new Set(['Adam', 'Eve', 'Reggie', 'Jane']);
const volunteers = new Set(['Reggie', 'Jane', 'John', 'Bob']);

// Now we want to find out who is in both lists
const commonMembers = [];
cookingClub.forEach(member => {
	if (volunteers.has(member)) {
		commonMembers.push(member);
	}
});

console.log(commonMembers); // ['Reggie', 'Jane']

It works — but that’s a lot of code for something so simple.

With the new methods, it becomes much cleaner and more semantic:

const commonMembers = cookingClub.intersection(volunteers);
console.log(commonMembers); // Set(2) { 'Reggie', 'Jane' }

// or we can find who is in the cooking club but not a volunteer
const differenceMembers = cookingClub.difference(volunteers);
console.log(differenceMembers) // Set(2) { 'Adam', 'Eve' }

No more manual loops. Just one-liners that read exactly like what you’re trying to do.

Other new methods, like union and symmetricDifference, will give you even more power. If the terms bring back memories of math class, don’t worry — the MDN docs have a great visual guide that makes them click.

If you ever need to compare sets or arrays, these methods will make your code shorter, clearer, and a lot easier to maintain.

#3. Iterator Helpers

Alright, I’m sure you’re familiar with iterators in JavaScript, but if you’re not, here’s a quick reminder: an iterator is simply an object that has a next() method, which returns a value in the form of { value: foo, done: false } .

Now, what about generators? To keep it simple, a generator is a function defined with an asterisk after the function keyword (function*) that uses the yield keyword to return values, one at a time:

function* numberGenerator() {
  yield 1;
  yield 2;
  yield 3;
}

const gen = numberGenerator();

console.log(gen.next()); // { value: 1, done: false }
console.log(gen.next()); // { value: 2, done: false }
console.log(gen.next()); // { value: 3, done: false }
console.log(gen.next()); // { value: undefined, done: true }

Now that we’re on the same page, what exactly are “iterator helpers”?

They’re basically the good old array methods we know and love (.map(), .filter(), .reduce(), etc.), but available directly on iterators.

One practical use case I can think of is reading a huge CSV file.

Here’s how you may do it, the old fashioned way:

// A simple CSV reader
function* csvReader(csvString) {
  const lines = csvString.split('\\n');
  for (const line of lines) {
    if (line) yield line.split(',');
  }
}

// Simulate millions of lines
const csvData = `id,product,category,price\\n1,apple,fruit,1.00\\n
2,banana,fruit,0.50\\n
3,tomato,vegetable,0.75\\n...millions of lines...`;

// Loads the entire dataset into memory - not a good 
// idea, but this is for science!
const allRecords = [...csvReader(csvData)];

let totalPrice = 0;
for (const record of allRecords) {
  const [id, product, category, price] = record;
  if (category === 'fruit') {
    totalPrice += parseFloat(price);
  }
}

console.log('Total fruit price:', totalPrice);

Sure, this is a practice example, but scale it up to millions of lines and you’ll quickly run into trouble. Not only do we run into memory issues, but the readability isn’t great either. The new ES2025 iterator helpers give us a much nicer way to solve this:

// A simple CSV reader
function* csvReader(csvString) {
  const lines = csvString.split('\\n');
  for (const line of lines) {
    if (line) yield line.split(',');
  }
}

// Simulate millions of lines
const csvData = `id,product,category,price\\n1,apple,fruit,1.00\\n
2,banana,fruit,0.50\\n
3,tomato,vegetable,0.75\\n...millions of lines...`;

const records = csvReader(csvData);

// Use a chainable, lazy pipeline to process the data
const fruitPrices = records
  .drop(1) // Drop the header row
  .filter(record => record[2] === 'fruit') // Filter for 'fruit' category
  .map(record => parseFloat(record[3]));   // Convert price to number

// Consume the iterator to calculate the total
let totalPrice = 0;
for (const price of fruitPrices) {
  totalPrice += price;
}

console.log('Total fruit price:', totalPrice);

Why this is better

• We don’t put all records into a single array; instead, we keep them as an iterator. That means nothing is processed ahead of time—map and filter only run on one record at a time as we iterate.
• From a readability standpoint, this approach is much clearer: it shows the step-by-step process in a declarative style.

I won’t go through every helper method here — there are a lot — but hopefully this gives you a good idea of how to use them in a real-world scenario.

#4. Float16Array

To keep it short: it’s a new typed array that stores 16-bit floating-point numbers. That’s it.

You can almost skip to the next part, because that’s really the whole story. Before this, JavaScript only had Float32Array, and now it has a smaller version of floating-point numbers.

I can’t imagine myself using this feature often, but if you’re working with low-level coding, machine learning, or you want to squeeze every bit of performance out of your code, this new typed array might serve you well.

In summary: the use case is memory efficiency—using the smallest data type for the right job.

But I can do you one better by visualizing it:

// Create a Float32Array to store 100,000 numbers
const float32Array = new Float32Array(100000);

// Each number takes 4 bytes (32 bits), so the total size is:
const float32Size = float32Array.byteLength;
console.log(`Float32Array size: ${float32Size} bytes`); // Output: 400000 bytes

// Time for the new type!
// Create a Float16Array to store the same number of elements
const float16Array = new Float16Array(100000);

// Each number takes 2 bytes (16 bits), so the total size is:
const float16Size = float16Array.byteLength;
console.log(`Float16Array size: ${float16Size} bytes`); // Output: 200000 bytes

So yeah, same number of elements, but half the memory.

#5. Import Attributes & JSON Modules

These two features are related, so I think we can bundle them together.

You might have come across syntax like this in a TypeScript file:

import data from "./data.json" assert { type: "json" };

The assert syntax was intended to provide hints to the runtime, telling it to treat the file as JSON data rather than executable code.

But in ES2025, this syntax is deprecated in favor of a new feature: the with keyword.

import data from "./data.json" with { type: "json" };

It does the same thing, but with is now the standard.

Use case:

The primary use case is to load non-JS modules, such as JSON modules and CSS modules.

• *MDN Web Docs*

I think this feature offers a lot: better clarity in the code and improved security, since you explicitly tell the runtime what type of file you’re importing instead of letting it assume anything.

Hands-On Example

<!DOCTYPE html>
<html>
<head>
    <title>Playground</title>
</head>
<body>
    <div class="playground">
    </div>
    <script type="module" src="app.js"></script>
</body>
</html>

.playground {
  padding: 1rem;
  border: 1px solid #ccc;
  border-radius: 4px;
  background-color: red;
}

{
  "name": "Playground"
}

import styles from './foo-style.css' with { type: 'css' };
import data from './data.json' with { type: 'json' };

document.adoptedStyleSheets.push(styles);
document.querySelector('.playground').textContent = data.name;

So we have 4 files:

• index.html → displays the result
• CSS and JSON files → test the new import features
• JavaScript file → the heart of this simple web app

And this is the result:

This might not be a huge change, but it does make imports clearer and helps standardize the process.

⚠️ Disclaimer: The import attribute code above works in Chrome, but I’m not sure how many browsers support it yet. Safari, for example, doesn’t support it at the time of writing.

#6. RegExp.escape()

When users type search terms, they almost always expect a literal match.

For example, if a user enters:

cat*

Most users mean the full word cat*, not the regex version, i.e. “cat followed by 0 or more t".

The same goes for something like:

cat.

A user expects to find "cat.", not “cat followed by any single character”.

So what’s the problem?

In regular expressions, many characters have special meaning instead of being a normal character.

Mentioned examples:

• * → repeat he previous character 0 or more times
• . → match any single character (except newline)

So if we directly use the user’s input without escaping, we end up with:

const text = 'cat, cot, cut, cat* cat.';

// Example 1: user types 'cat*'
const regex1 = new RegExp('cat*', 'g'); // add 'g' flag so we see all matches
console.log(text.match(regex1)); 
// 👉 ['cat', 'cat', 'cat']
// ✅ Matches: 'cat', 'cat*', 'cat.'
// Note: the '*' applies to the preceding 't', so the match is just "cat".
// (* repeats 't')

// Example 2: user types 'cat.'
const regex2 = new RegExp('cat.', 'g');
console.log(text.match(regex2)); 
// 👉 ['cat,', 'cat*', 'cat.']
// ✅ Matches: 'cat,', 'cat*', 'cat.'
// (. matches any single character)

That left us with 2 options.

1. Escaping manually

// Escape regex special characters
const escapeRegex = (str) => str.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');

const text = 'cat, cot, cut, cat* cat.';

// User types 'cat*'
const escapedRegex1 = new RegExp(escapeRegex('cat*'));
console.log(text.match(escapedRegex1)); 
// 👉 Matches only: 'cat*'

// User types 'cat.'
const escapedRegex2 = new RegExp(escapeRegex('cat.'));
console.log(text.match(escapedRegex2)); 
// 👉 Matches only: 'cat.'

It works, but it’s boilerplate and easy to get wrong.

2. The new ES2025 RegExp.escape()

const text = 'cat, cot, cut, cat* cat.';

// User types 'cat*'
const safeRegex1 = new RegExp(RegExp.escape('cat*'));
console.log(text.match(safeRegex1)); 
// 👉 Matches only: 'cat*'

// User types 'cat.'
const safeRegex2 = new RegExp(RegExp.escape('cat.'));
console.log(text.match(safeRegex2)); 
// 👉 Matches only: 'cat.'

No more writing your own escape logic — the engine does it for you.

I’d say this addition is a good one. It removes the need for manual escaping and ensures that user input is always treated as a literal string.

#7. RegExp Pattern Modifiers (Inline Flags)

Another RegExp QoL update from ES2025. This feature lets you apply a flag to a specific part of a regular expression. It’s really useful when you want different parts of your pattern to behave in different ways, instead of relying on a global modifier.

Let’s start with the syntax below:

• (?i:...) → turn on case-insensitive matching just for this group
• (?-i:...) → turn off case-insensitive matching just for this group

This also works for other flags like i, m, and s.

// (?i:...) - Activates case-insensitivity
const regex1 = /(?i:hello)/;
regex1.test("Hello"); // true

// (?-i:...) - Deactivates case-insensitivity
const regex2 = /^(?-i:hello)$/i; // The global 'i' is active, but is turned off for 'hello'
regex2.test("hello"); // true
regex2.test("HELLO"); // false

Quick note: Other modifiers are not supported, since they would either make your regex overly complicated or simply wouldn’t make sense when applied locally instead of globally.

Let’s understand it better with an example.

Imagine you need to match a file path that starts with a case-sensitive drive letter (C:), followed by a case-insensitive directory name (Users), and then a specific case-sensitive filename (MyFile.txt).

Old way

// This regex makes the entire expression case-insensitive.
const regex = /C:\\Users\\MyFile\.txt/i;

console.log(regex.test("c:\\users\\myfile.txt")); 
// Output: true (too broad - it should fail!)

See the problem? This regex matches both c: and C:, which might not be the behavior we want. And just thinking about building a complicated regex to cover all these cases is enough to make me want to take a coffee break.

New way

// The (?i:...) applies the case-insensitive flag only to "users"
const regex = /C:\\(?i:Users)\\MyFile\.txt/;

console.log(regex.test("C:\\users\\MyFile.txt")); // Output: true (correct)
console.log(regex.test("C:\\Users\\MyFile.txt")); // Output: true (correct)
console.log(regex.test("c:\\users\\MyFile.txt")); // Output: false (correct)
console.log(regex.test("C:\\users\\myfile.txt")); // Output: false (correct)

This addition is pretty elegant, as it allows you to write precise regex that match exactly what you want, without needing complicated workarounds.

#8. Duplicate Named Capture Groups

Traditionally, every named capture group in a JavaScript regex had to be unique. If you tried to reuse a name, it would throw a SyntaxError. This often led to repetitive names like year1 or year2, even when they represented the same concept.

Well, that restriction has been lifted: you can now reuse the same name in a single regex, and the results will be returned as an array of matches under that name.

// New ES2025 behavior
const regex = /(?<num>\d+)-(?<num>\d+)-(?<num>\d+)/;
const result = regex.exec("123-456-789");

console.log(result.groups.num);
// Output: ["123", "456", "789"]

Example:

Old way

const str = "Today is 2025-09 and tomorrow is 09-2025";

// Had to use two different names: year1 and year2
const regex = /(?<year1>[0-9]{4})-[0-9]{2}|[0-9]{2}-(?<year2>[0-9]{4})/g;

const result = [...str.matchAll(regex)];

// Collect whichever group matched
const years = result.map(r => r.groups.year1 || r.groups.year2);

console.log(years);
// Output: ["2025", "2025"]

New way

const str = "Today is 2025-09 and tomorrow is 09-2025";

// Same group name reused across both alternations
const regex = /(?<year>[0-9]{4})-[0-9]{2}|[0-9]{2}-(?<year>[0-9]{4})/g;

const result = [...str.matchAll(regex)];

console.log(result.map(r => r.groups.year));
// Output: ["2025", "2025"]

This is much cleaner, with no need for names like year1 and year2

Note: This feature is still new and not yet widely available in all JavaScript environments, so please be cautious when using it in production code.

Wrapping Up

And that’s a tour of the shiny new features in ES2025!

Some of these updates are small quality-of-life helpers — like RegExp.escape() and inline pattern modifiers — while others open up brand-new possibilities, like iterator helpers or Float16Array for squeezing more performance out of your code.

The important thing isn’t memorizing every single detail, but knowing what tools exist so you can reach for them when the time is right. Even if you don’t need Promise.try() or duplicate capture groups today, just being aware they’re available can save you hours of work down the road.

JavaScript continues to evolve in ways that make it more expressive, more efficient, and frankly more enjoyable to write. Try out these features in your own projects, keep an eye on browser and runtime support, and have fun exploring what’s new.

Because at the end of the day: better tools mean less boilerplate, cleaner code, and more time to build the stuff you actually care about.

Then life happened. Work got intense, the site stayed quiet, and a lot changed. Here’s what I’ve been up to, what’s coming back, and where Devmystify is headed next.

What I’ve been up to in the past decade

2016-2017

I lived the digital-nomad life—traveling around SEA and Europe as I tackled Upwork gigs. It taught me how to sell my skills, manage clients, and ship value quickly. I reached Top Rated and made a few essential connections.

2017-2020

Something funny happened during the summer of 2017: one of my friends posted something about Ethereum. I had just begun getting back into crypto and the blockchain world, so it piqued my interest and I got in touch with him. That friend was the CTO of Omise, a payment processing company in Thailand, and they were creating OmiseGO, a new company focused on blockchain and its uses in the payment world.

A couple of weeks later, I was officially hired and joined as a Team Lead. With the blockchain bubble in full swing, this was too good of an opportunity to pass up, and I don’t regret it at all!

Over the following years, I built a team of great engineers. We created an open-source blockchain-connected eWallet using Elixir. Three wild years. It was exhilarating, exhausting, and it pulled my focus away from this site.

I was promoted to Director of Engineering, which was great, as our engineering team was around 25 people at the time. But good things don’t last.

The company was sold and nearly everyone was let go.

2020 - 2024

I landed at a small web agency in Bangkok and hustled to bring in clients and projects to help the team succeed.

Meanwhile in life

I got married and became a dad to a little boy. Busy is an understatement.

2024 - 2025

After that, I took what I’d learned and started my own company with my partner, working with clients in the U.S. from Phuket. We’re growing carefully, but also diversifying. Consulting pays the bills, but I want to build lasting value: books and courses that distill 15 years of software engineering and technical leadership—and finally some SaaS products I’ve been itching to launch. I’m also leaning into content creation, especially YouTube, to demystify how developers can learn better and earn more.

Why Freelancing Still Matters

Even as I diversify into products and teaching, freelancing is still at the core. Right now, selling software services is our company’s primary source of revenue.

Setting your own schedule and working from anywhere (hello from Phuket 👋) is a freedom many developers want. Sure, freelancing has its own challenges, but it turns you into a business. You set your hours, choose your clients, and earn what you’re worth. That creates room to reinvest into side projects and bigger ventures.

About the Books: *Modular Rails* & *Master Ruby Web APIs*

Some of you may be wondering: Where did the books go? I made both free to read online for a long time, but I couldn’t keep them current—they were stuck around Rails 5. Outdated books help no one.

So I took them down… to rewrite and re-release them properly with my team. They’re coming back fully refreshed for modern Rails.

Rails, AI, and the Future of Developer Work

Interesting twist: after years of mostly doing JavaScript, I’m now back in the trenches working on a 15-year-old Rails monolith. It gave me some white hairs, but it also made me realize that Rails isn’t dead. Far from it, apparently. Maybe in a few decades, the Rails Cowboys will be a thing (see Cobol Cowboys , a team who maintain COBOL applications, a language created in 1959).

That said, Devmystify won’t be Rails-only. React is everywhere, and I use a lot of Next.js these days (heck, this website was written with Next.js!).

And of course, I have to mention AI, as it is changing how we work. My focus is practical: how to use AI to ship faster, communicate better, and be more productive, without chasing every shiny demo.

No vibe coding allowed though.

What I’m working on now (and Next)

• 📚 Book relaunches – Modular Rails and Master Ruby Web APIs, fully updated (Rails 7 & 8).
• 🎓 A complete course on freelancing
• 🎥 The Devmystify YouTube channel – real talk about developer income streams: freelancing, consulting, products, content, and how to pick what fits you.
• 🛠️ SaaS projects – long-standing ideas I can now staff and execute.
• 🌱 And plenty more as the community grows.

What Devmystify Stands For

Devmystify’s mission is simple: help developers learn smarter and earn more, by demystifying the roadblocks holding you back. That means practical tutorials, honest career advice, and real business case studies. If you’re a developer who wants more control over your time, income, and career direction, you’re in the right place.

If this resonates with you, you should join the newsletter — I’ll share updates, practical dev tips, and behind-the-scenes lessons you won’t find anywhere else.

Finally, if you’ve been here since the early blog days, thank you. If you’re new, welcome. I’m excited to ship useful things again and to build this next chapter with you.

Modular in Rails can be implemented using a feature that came with Rails 3: Engines. From the Ruby on Rails guides :

Engines can be considered miniature applications that provide functionalities to their host applications.

It's unfortunate that this feature, making the whole modular approach possible, is only present at the framework level, and not in the language itself.

Elixir

About 2 years ago, I started playing around with Elixir. I built a project with it for fun, but barely scratched the surface of its powers. A few months later, I started a new job as Lead Engineer and started building a more advanced Elixir application.

Through research, test implementation and help from my first team member (who had a background in Erlang), I was able to wrap my head around a lot of new concepts: functional programming, immutability, process management, GenServers, etc. But the thing I got most excited about was the Umbrella feature .

It's basically everything that was hacked together to make Rails engines work, but cleanly implemented in the language itself and offered with proper dependencies management. You can adjust how you want your sub-apps (as we call the individual applications in Umbrella apps) to interact and define if you want them to actually start and manage their own processes.

It was love at first sight.

I decided right away that we should build the project as an Umbrella app, in order to properly structure all the moving parts. It was so easy to get everything working that I'm not sure I want to go through the pain of doing it in Ruby anymore.

You can look at the sub-applications inside an Umbrella app as internal micro-services, each dealing with its own set of responsibilities and working with the others to provide an actually useful set of features to your users.

An example

Now, let's see how it looks like in practice, by making a very simple Umbrella app. We won't go into the details, I'm just trying to share the whole idea here, not how to actually code it.

We're going to be creating an example structure for a CRM application, that will offer the following features:

• Users & Authentication management
• Contacts / Leads management
• All interactions with the CRM should be available through a regular web interface, as well as through a web API.

We can actually structure it in two different ways (and probably more, but I found these two to be the most interesting ones). First, let's generate the Umbrella app and we'll go through the two approaches:

mix new crm_umbrella --umbrella

* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating apps
* creating config
* creating config/config.exs

Your umbrella project was created successfully.
Inside your project, you will find an apps/ directory
where you can create and host many apps:

    cd crm_umbrella
    cd apps
    mix new my_app

Commands like "mix compile" and "mix test" when executed
in the umbrella project root will automatically run
for each application in the apps/ directory.

cd crm_umbrella/apps

The "Business Logic Modules" / "Silos" approach

With this approach, we split the business logic of the CRM into modules, where each one contains everything it needs to function. In short, we will build a set of silos that connects the end user to the data layer.

To make things simpler, we start off with a core module where we will initialize a shared Ecto Repo:

mix new core

We can then create two more sub-applications, one for the users and one for the contacts:

mix new users

mix new contacts

We will have the entire stack in each one of them:

• User / Contact Ecto schemas
• The usual Phoenix stuff: router, controllers, views, and templates.
• Any needed modules between the data layer and the web layer.

The last thing we'll probably want to add is a dispatcher sub-application. Since we have more than one application that can handle web requests (both the users and contacts apps can), we want to have one sub-application that receives all web request and dispatch them to the right place:

mix new dispatcher

In the end, the dependency tree for our sub-apps will look like this:

    dispatcher
   |         |
 users     contacts
    \        /
       core

This approach is interesting if you're looking for something similar to usual micro-services, you can just add more sub-apps in the middle layer and have different teams working on each one of them.

Note that I usually dislike micro-services architecture, and I'm only referencing it as an example here. I don't recommend going that route. My simple rule of thumb to define if micro-services are needed is that if one developer is going to work on more than one micro-service, then you don't need micro-services.

The "Functional Layer Modules" approach

This approach focuses more on cutting your application horizontally, into a stack of layers.

First, we create a sub-application where we will put all our database schemas. This will represent the data layer to the rest of the sub-apps, making it easier to store and retrieve records.

mix new db

On top, we create another sub-app to hold the modules that will contain the business logic. To keep this simple, I'm only creating one, but nothing prevents you from having more:

mix new crm

Finally, we create sub-apps that can handle HTTP request and will be accessible by anyone. We create one for our website and one for our API. For the website app, we can either build a frontend using Phoenix templating system, or we could have a JavaScript "Single Page Application" that connects to the API sub-app. That's actually how the Admin Panel we built works.

mix new web

mix new api --module API

We end up with an Umbrella application structured like this:

web   API
 |     |
 \     /
   CRM
    |
   DB

I personally tend to prefer this approach lately, especially for smaller teams.

The End

I originally worked with the "Silos" approach for my first modular application, simply because the company I was working for wanted to be able to take those siloed features (encapsulated in modules) and add them to other applications. For example, a booking module could be used in an app for restaurants, for doctors or for massages. Another good example is Devise , which encapsulates the whole Authentication stack inside a Rails engine.

For that company project, we wanted to build a flexible, all-in-one, and easy to deploy application. We weren't planning to reuse modules anywhere else or run the sub-apps as micro-services. That's why it made sense for us to go with the Layered approach.

There is no right or wrong, both of those approaches are valid and there are definitely more ways to structure your modular applications. It really comes down to your needs.

Let me know which approach you prefer (or are currently using) and why in the comments :)

Oh boy, what a disappointment.

The usual origin story

I started like everyone else, learning that a properly built web API needed to offer nice looking resources (/users), handling the various HTTP verbs (get, post, etc.) which are semantically loaded with rules and behaviors defined in RFCs. I learned those approaches that by working on Ruby on Rails applications. All was well for a while, and I spent a few years building apps that way.

I never took the time to dig deeper into Roy Fielding’s dissertation or learn more about REST, I thought I was building RESTful APIs. I never actually wondered why people didn’t call them “REST APIs”, was there REST-half APIs or partially-REST ones? ¯_(ツ)_/¯

By that point, I had spent the past two years building web APIs in Ruby and had seen all kinds of APIs. I felt I knew the right way to build RESTful APIs. I also wanted to write another programming book, so I naturally thought I had to share my knowledge.

Writing Master Ruby Web APIs

The first thing I did, before writing a single line of text or code for MRWA, was research. I went through a lot of content, starting with RESTful Web APIs as I thought it would give me a great understanding of REST and what is a RESTful Web API. Well, it left me disappointed and wanting for more. There was so many mentions of the “Semantic Gap” that I felt most of the book was written from a theoretical perspective, so barely anything I could use in practice, for the book or my apps.

The Semantic Gap is the difference in understanding of web applications by humans and by programmed clients. We, as humans, are able to open the homepage of a website, discover linked pages and navigate around. The applications we build aren’t that smart, unfortunately, we need to tell them what to do. That’s why human-readable documentation is necessary for web APIs today, because humans need to read through them and implement their apps in the right way.

The current approach offered by REST is to basically try to bridge the gap as much as possible, until it is closed. Unfortunately, I don’t think we’re getting there in the coming years.

This realization was like a cold shower. I decided to focus more on building HTTP APIs, and the first step was dedicated a whole module to review the basics of building stuff for the Web. That meant reviewing and putting in practice all the features that came with HTTP (if they made sense in the context of an API), without worrying too much about all the REST side of things.

In the second module of the book, I teach how to build a complex Ruby on Rails web API by going up to level 2 in the Richardson’s Maturity Model. I felt that was enough since that’s what most businesses are doing today, and I wanted to teach something practical.

Picture from this post: Richardson Maturity Model

Getting frustrated

Finally, the last module was supposed to focus on HATEOAS. I tried, I really did. But I realized it wasn’t really practical. Sure, I could use hypermedia links to notify a client that an endpoint had moved (as long as the client had a way of handling this safely, as in don’t follow redirections forever or get stuck in a loop), but I still needed to hardcode how and where to interact with the API.

There were some interesting specifications though, like the Hydra spec . With it, if I was building a client to show data in the way the API was built, I could just build screens dynamically based on the returned data (unfortunately, I wouldn’t be able to customize each screen to offer a better UX to the users). While the idea sounds good in theory, it has little practical value for our needs today.

In the end, I feel building clean HTTP APIs is all about embracing good ol’ software engineering concepts and keeping your users happy.

Chilling out

These days, I’m not really worrying about building RESTful APIs anymore. I don’t really use the word anymore. At my latest job, we decided to not bind our APIs to HTTP, and went down the JSON-RPC road, with full custom error codes, etc. We wanted to stay “communication protocol”-agnostic to offer the same kind of responses through HTTP, Websockets, and whatever else fancies our minds.

In conclusion, most Web APIs out there are just HTTP APIs, and that’s good enough. You can call them RESTful, I don’t even get mad anymore, simply because I don’t care, I'll just check the docs to see how to use it. I’m more interested in providing value to people with interfaces they will like.

You will need to provide a human-readable documentation with your API, and it doesn’t matter if it’s RESTful, RESTish, RPC, or something else - and it’s all okay. Maybe one day, the gap will be bridged, but until then, we should worry about building things people want to use.

A good example to illustrate this point is the switch Github made , going from a RESTful API (with some pretty nice Hypermedia support) to using GraphQL , because following the REST principles was bloating their API and making it not flexible enough for its users.

I’m actually quite interested in using GraphQL and making clean RPC APIs lately, so I’ll probably cover those topics more in the future.

Relevant parts from Master Ruby Web APIs

• A REST Overview
• Why the app built in MRWA isn’t RESTful

Interesting articles

• REST is the new SOAP
• No, it’s not.
• Yes, it is.

Articles that resulted from my frustration a long time ago

• The Web API War - Devblast
• RESTful APIs? You’re doing it wrong.

As developers, we need computers for most of our work, and that usually means sitting in front of one for hours on end, with every little physical activity.

You've got to move it, move it

One of the biggest problems of working from a desk is that you don’t get enough opportunities for passive exercise. Take the perennial college job of working in a grocery store as an example - lifting heavy boxes or bags, climbing ladders in the backroom, or just walking around all day - you’ve essentially got a workout built in. Once you’ve traded in your nametag and pulled up a seat in front of a screen, the passive health benefits start to drain away.

One tip that always gets tossed around is the 1/10 rule - for every hour, get up and walk around for 10 minutes. If you work in a bigger office, this one is a little easier to turn into a habit - walk to a coworker’s desk, go hangout near the coffee machine, or take a spin around the breakroom. If you work from home or in a smaller team, use your phone’s timer to set break reminders for yourself. Or if your working hours are flexible, run out to the post office, grocery store, or take a quick walk around the block every two hours or so. In any case, you’re reaping double the benefits from unplugging for just a few minutes - getting a little exercise will also improve your mental clarity, energy, and possibly your overall job performance.

Ergonomics

“Ergonomics” was the buzzword in the office of the early 90s. As computer use became more and more frequent, so too did headaches, backaches, and repetitive strain injuries like carpal tunnel syndrome as the new occupational hazards. The solution? Proper design of things we used everyday, like keyboards, chairs, or computer mice.

Nowadays, there are tons of tools you can buy that claim to reduce repetitive strains with the added benefit of making your workspace a touch more futuristic. The split keyboard and chairs with increased lumbar support and cushioning are becoming more and more popular.

But an ergonomic workspace also means a lot of small, non-obvious adjustments. This might mean the positioning of your keyboard, the height of your computer screen, or the distance between your chair and the screen. No matter how expensive, new, or cool an office gadget might be, there is no magic bullet for solving all the problems that can come from inactivity or odd positioning over so many hours.

A good place to start is doing a full body scan while sitting in your normal position at your desk. How does your neck feel - achy? Tight? Are your legs falling asleep? Any muscle twitches? Tune into where you sense discomfort or repetitive, unnatural movement during daily tasks.

It is super important here to take into account the circumstances of your individual body. A workstation that might work for one person could be totally counterproductive or dysfunctional for someone else. Are you prone to back problems? Taller than most people? You might need to tweak the height of your desk or the tilt of your screen.

Diet

What it is it about working at a desk that utterly destroys healthy diets? If you work in an office with others, the breakroom snacks and lunch dates are obvious culprits. But those who work remotely aren’t immune either - if you regularly work from coffee shops or other coworking style cafes, you know how easy it is to add a not-so healthy treat in with your coffee order.

One way to get started is to get organized about eating. When we’re rushing to work or parked in front of the computer pushing to meet a strict deadline, it’s easy to grab things that will give us a quick boost but that aren’t that great for us. Having a plan for chaotic times is essential, whether it’s sliced fresh fruit in a desk drawer or portion-sized bags of trail mix in your bag. When making dinner, plan to make a little extra and set aside lunch the night before, making sure to tuck in lots of leafy greens and veggies as a side. We all know that processed foods aren’t good for our energy levels or overall health, so making it a habit to keep backups for stressful times is crucial.

Beat the Desk Life

At the end of the day, our productivity is inextricably linked to our health. Especially if you make your own hours as a freelancer or work remotely, the battle for consistency and stability is real. Many times, the first things to get sacrificed are our diet, posture, and other healthy habits. But if you think about it, an investment in your health is an investment in your job satisfaction and ability to get things done.

Besides some of these general tips, here a few actual, actionable things that you can do to fight back against a sedentary lifestyle.

Try

Exercise at Your Desk

This one sounds pretty obvious, but mixing in isometric exercises during your normal work day is a good way to stay fit. Choose one of these isometric exercises and do one during a short break or every hour. If you work in a bigger office and don’t want to break a sweat in public, use mealtimes to take a walk around the block or climb up and down a flight of stairs in your building.

Journaling

There are a million ways to keep yourself accountable to your health goals. If you’re keen on using visuals or like to jot things down manually, check out bullet journaling . The beauty of this journaling system is that it’s endlessly adaptable to different productivity styles and needs. Track meals and snacks, or keep a “health to-do list” the same way you would track work tasks - anything from “drink 8 glasses of water” to “20 push ups.” Then, make it a goal to get through as many as you can.

If you’re not really the artsy type or prefer keeping things all in the cloud, add health reminders to the productivity platforms you already use. There are the old standards, like Evernote , but you can also try the stripped-down Wunderlist . Create a separate list to make sure you step away from the desk, exercise, or grab a quick snack periodically.

Automating It

Use the tools you already have - set a timer on your smartphone or calendar for every hour you’re at your desk (just make sure to for the meetings). Take just a few minutes to get away stretch, drink a glass of water, walk around, or do a few crunches. By essentially making an appointment with yourself, you increase the odds that you’ll stick to any health plan. You can also go with some time-boxing techniques like Pomodoro to ensure you take regular breaks between your tasks.

Meditating

Meditation improves not only your mental health, but also gives your eyes a rest and gives you a chance to check in with your body. If you find yourself hunching over the computer, take just 5 or 10 minutes to close your eyes, relax, and focus on your breath. Try doing a body “scan” - just practice observing your body and your posture, and make adjustments (relax your shoulders, roll your wrists) if you notice discomfort anywhere.

Working Smarter

If you don’t always work in front of a computer, try re-organizing your daily routine so that your time at the computer is periodically broken up by other tasks. Batch similar tasks, like tracking your invoices or testing code, and then time yourself. If you feel like you’re getting sucked into the computer chair at the end of an hour, stand up and do a few stretches. Walk to a coworker's desk to have a quick chat instead of a text, or place your printer or other devices across the room so you have to get up in order to do certain tasks.

Working smarter also means streamlining your work process to minimize the time you’re in front of the screen overall. Evaluate the tools or software you use to get things done, and change things up if necessary. If you’re a writer and need a clean, distraction-free interface for getting creative or just taking notes, try chilled out OmmWriter . Or if you need a way to stay organized while doing web development work, try a text editor that streamlines the process with Vim ( here’s a few reasons to love it ).

Buy

A New Workspace

Standing desks are the hot new trend in startup office management (first they came for our cubicles, now it’s our chairs). Fans of standing desks (or other chairless workspaces like the “treadmill desk”) point to their benefits, like increased circulation and calorie burning - some go so far as to say that “ sitting is the new smoking .” Lifehacker’s guide to standing desks is a good place to start exploring your options. If getting a new desk is out of the question (or your budget), exercise balls and other “dynamic seats” are great for encouraging a more healthy seated posture.

The key with any workspace is to make sure it fits you as an individual. The cumulative effects of small movements, like pushing your neck forward to read your screen or overextending your wrists while typing, can negatively impact other parts of your body and cause spinal misalignments and muscle strains. Make sure you consider every area in your workspace by checking this doctor-approved guide .

Split Keyboards

Generally, a good keyboard should mirror the way you actually hold your hands while you type. Split keyboards divide the keys between the hands, and usually are curved or tilt the keys inwards, supporting optimal wrist position. Negative tilt (where the bottom of the keyboard is pointed down towards you) also combats repetitive wrist strains. Broad, curved wrist supporters on Microsoft models are good if you’re on a budget . Or check out the ErgoDox , a blowout success on Kickstarter - each keyboard can be engineered and customized to every user, with key switches specifically designed for developers, writers, and anyone else who lives in front of their computers. You can also take a look at ErgoDox EZ for pre-assembled keyboards.

The End

Though it’s difficult to put into practice, getting active is especially important for those that work in front of screens (which is honestly most of us nowadays). Working in a few exercises or updating our gear is ultimately an investment in our productivity and overall happiness - and at the end of the day, that’s really what it’s all about.

1. Functional Programming

Elixir is a functional language, which is quite a change when coming from the object-oriented Ruby where everything is an object . But what does it mean exactly?

If you don't know, functional programming is a programming paradigm . The principal characteristic of this paradigm is the absence of side effects when calling a method. Most features of the Elixir language (immutable data, pattern matching, first-class functions and more) can be derived from the desire to prevent side-effects, as can be expected from a functional language.

Functional Programming is a wide and interesting topic, one I'm not comfortable enough explaining. But if you want to take a closer look, I can recommend this article on Medium .

2. Immutability

The fact that data are immutable is a big change from Ruby. If you add an element to a list in Elixir, you won't be getting back the same list - a new one will have been created with the added element. However, a variable can be rebinded, which means you can change which data structure the variable points to/references in memory.

So you can do this...

x = %{} # x points to the immutable data %{}
x = %{one: "two"} # x now points to the immutable data %{one: "two"}

...but you cannot do the equivalent of this (written in Ruby):

x = {} # x points to the data {}
x[:one] = "two" # x still points to the same data,
                # but the data has been modified

It also means you cannot change data in loops; instead, map or reduce should be used. It's also a good example of how functions don't have side-effects and won't change the state of the program.

a = 0

Enum.each [1, 2, 3, 4], fn number ->
  # We are not changing a, just creating new variables
  # limited to the scope of this anonymous function
  a = a + number
end

# Therefore a didn't change
IO.puts a # => 0

This is easily fixed with reduce - we can tell Elixir to calculate the sum using an accumulator (acc).

a = Enum.reduce [1, 2, 3, 4], 0, fn number, acc ->
  number + acc
end

IO.puts a # => 10

The property of immutability has a number of advantages like data consistency and simpler concurrent programming (no need for locks!). It also makes it easier to reason about the code since functions are just about transforming their inputs into outputs, and not changing state.

3. Pattern Matching

I love pattern matching! I'm still learning all the intricacies, but it's super useful to implement guard clauses (for example). Whereas in Ruby, you might do something like this:

def foo(a)
  return 0 unless a > 0
  2.0 / a
end

p foo(0) # 0
p foo(3) # 0.6666666666666666

In Elixir, you can just write:

defmodule Calculator do
  def foo(a) when a > 0 do
    2 / a
  end
  def foo(_), do: 0
end

IO.puts Calculator.foo(0) # 0
IO.puts Calculator.foo(3) # 0.6666666666666666

And you can add as many definition as you need. Note that I used _ for the second definition of foo because otherwise, Elixir would give me a warning for having an unused variable.

It can also be used to implement recursivity. Here is a relatively simple naive implementation of Fibonacci:

defmodule Fibonacci do
  def calc(0), do: 0
  def calc(1), do: 1
  def calc(n) when is_integer(n) and n > 1 do
    calc(n - 1) + calc(n - 2)
  end
  def calc(_), do: {:error, "Only positive integers allowed."}
end

IO.inspect Fibonacci.calc(10) # 55
IO.inspect Fibonacci.calc("foo") # {:error, "Only positive integer allowed."}

We can do all sorts of things with pattern matching. Here, the foo function is returning a tuple . When using it, I can pattern match with another tuple to extract the values from the tuple.

defmodule Foo do
  def foo do
    {"foo", "faa"}
  end
end

# Thanks to pattern matching
{a, b} = Foo.foo
IO.puts a
IO.puts b

This pattern is often used to catch errors as you can see in the code below, using a case .

case do_something_dangerous() do
  {:success, data} -> # process data
  {:error, message} -> # process error
end

4. Supervisors and running stuff in the background

If you're used to working with Ruby on Rails, you know that the right way to run long tasks (like sending a bunch of emails or generating a report) is to create a background job with Sidekiq or Resque .

With Phoenix (thanks to Elixir&Erlang), there is absolutely no need for that - instead,concurrent processes (Elixir processes, not OS processes) can be spawned with 1 line of code (spawn(fn -> 2 * 2 end)).

In order to manage these processes, Elixir provides the Supervisor module.

When generating a new Phoenix application, you will have the following supervisor configuration:

# lib/devblast.ex
defmodule Devblast do
  use Application

  # See http://elixir-lang.org/docs/stable/elixir/Application.html
  # for more information on OTP Applications
  def start(_type, _args) do
    import Supervisor.Spec, warn: false

    children = [
      supervisor(Devblast.Endpoint, []),
      supervisor(Devblast.Repo, []),
      # Here you could define other workers and supervisors as children
      # worker(Devblast.Worker, [arg1, arg2, arg3]),
    ]

    # See http://elixir-lang.org/docs/stable/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [strategy: :one_for_one, name: Devblast.Supervisor]
    Supervisor.start_link(children, opts)
  end

  # Tell Phoenix to update the endpoint configuration
  # whenever the application is updated.
  def config_change(changed, _new, removed) do
    Devblast.Endpoint.config_change(changed, removed)
    :ok
  end
end

You can then add more supervisors and use them to run stuff in the background (I added one to handle small tasks like sending email, and another one as a memory cache).

children = [
  supervisor(Devblast.Endpoint, []),
  supervisor(Devblast.Repo, []),
  supervisor(Task.Supervisor, [[name: Devblast.TaskSupervisor]]),
]

Task.Supervisor.start_child Devblast.TaskSupervisor, fn ->
  # Run some suff in the background
end

I learned how to do this thanks to Daniel and his great article . Kudos to him!

5. Pipes are awesome

Familiar with *nix commands? Piping commands like ls -a | grep *.ex? Well, Elixir provides the same feature with the pipe operator.

This means you don't have to write code like this...

a = [1, [2], 3]
a = List.flatten(a)
a = Enum.map(a, fn x -> x * 2 end)

...or like this:

a = Enum.map(List.flatten([1, [2], 3]), fn x -> x * 2 end)

Instead, you can just pipe the output of each function and send it as the first argument of the following one with the pipe operator!

[1, [2], 3] |> List.flatten |> Enum.map(fn x -> x * 2 end)

This example was taken from the Elixir documentation . I was lacking the imagination to find an example...

6. Phoenix doesn’t have much hidden magic

There is much less magic in Phoenix than there is in Rails. One of the things you really need to understand is the Plug specification. In Phoenix, the entire HTTP layer is handled internally by a bunch of plugs (note that you can easily add your own!)

Here is a pipeline of plugs generated by Phoenix in the router file:

pipeline :browser do
  plug :accepts, ["html"]
  plug :fetch_session
  plug :fetch_flash
  plug :protect_from_forgery
  plug :put_secure_browser_headers
end

Each one of these plugs will receive the request object (conn) and transform it.

7. You need to learn how Brunch works

The Phoenix team decided to use an existing build tool for the assets, which is not a bad idea. They went with brunch.io , which is pretty simple and easy to use, as long as you go through their documentation .

8. Huge lack of tutorials

There is still a huge lack of tutorials and articles on Elixir and Phoenix. I had some issues for which I wasn't able to find any help, and had to spend a lot of time figuring on my own. I'm planning to write some stuff about them to fill the hole.

9. edeliver and exrm/distillery for deployments?

The commonly accepted way to deploy Phoenix applications is with edeliver and either exrm or distillery . edeliver lets us perform hot-code upgrades which is a cool way to upgrade your application without restarting it.

However, I was disappointed by how slow the deployment was. Maybe I did something wrong, but the generated release would take hours to get copied to the production server...

So instead, I decided to go with Dokku and I'm quite happy with it, even if I don't have hot-code upgrades!

10. Frameworks should have unique name.

Alright, this last point is a bit of a joke - don't take it too seriously. I really had this issue with Rails ,but it happened to me more than once with Phoenix: there are too many things named Phoenix!

I can't tell how often I searched for something in Google using "phoenix" and my query and received results about Apache Phoenix or the city of Phoenix .

Phoenix is not unique enough :')

The End

I still have many, many things to learn, but I just wanted to share some of the first things I’ve encountered in the past weeks. I will be writing more on my experience with Elixir and Phoenix shortly, so don't forget to subscribe to the newsletter or the RSS feed .

I'm still a beginner in Elixir so all the information in this article might not be 100% accurate. If you find anything wrong, please leave a comment to let me know.

You probably already have an idea of what a resource is. The term has been used widely, and most of the times pretty accurately, in different web technologies.

After being defined as a part of the REST style, it was pragmatically introduced as the target of URLs (Uniform Resource Locators - RFC 1738 ) before being extended to URIs (Uniform Resource Identifier RFC 3986 ) and IRI (Internationalized Resource Identifier - RFC 3987 ).

Before we continue on resources, let's define what these acronyms mean exactly.

URI vs URL vs URN

It is important to understand the difference between URL, URI, IRI and URN because they represent different concepts. Tim Berners-Lee defined in RFC 3986 a "Uniform Resource Identifier (URI)" as "a compact sequence of characters that identifies an abstract or physical resource" and claimed that a "URI can be further classified as a locator, a name, or both."

He also stated that the term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network 'location').

Got it?

Let me simplify this for you. Let's say you are a resource -

• URLs are locators (hence the name). A URL is your home address: 12 Whatever Street, 11002, Paris.
• URNs are names. For you, a URN is your name: John Smith.
• URIs can be a locator (URL), a name (URN), or both.

Basically, all URLs are URIs, but not all URIs are URLs.

The only thing that can qualify a URI as a URL is if the latter includes how to find the former. www.google.com/account is not a URL, just a URI. However, http://www.google.com/account is a URL (and still a URI) because it includes the protocol (http://) that can be used to access the resource (www.google.com/account).

URNs are much simpler - they are just names.

An ISBN (like 978-0553293357) is a unique identifier for a book, which makes it a URI, and more specifically, a URN.

Finally, IRIs are an extension of URIs meant to include characters from the Universal Character Set (Japanese Kanji, for example). Indeed, URIs are limited to a subset of the ASCII character set.

HTTP and URIs

In the scope of HTTP , URIs are "simply formatted strings which identify - via name, location, or any other characteristic - a resource."

A resource is the thing living on the other side of a URI and a URI only points to one resource. That sounds rather abstract, so let's look at the following example.

http://example.com/users

This URL points to a resource named users. Note that we can never retrieve this resource; instead, we can only get a representation of it as defined by the Uniform Interface constraint. So we can say that a resource never changes, only its representations do.

So how do we name resources? After all, resources are just abstract concepts pointed at by URIs. In theory, it can be anything since naming doesn't matter to the machine that will be the final client of your web API.

But we must also consider that we are building for human beings and we are still far away from removing developers from the equation. Since we are building web APIs for humans, who will use them to implement their client code, we should use concepts and semantics that they will understand. This follows the same principle used in naming resources for websites.

The following is based on the best practices to build an easy-to-use API, and not really on web standards.

If I want to represent the concept of a list of users, I would just use the pluralized word users, which is just a noun. Making a request to this URL would return a representation listing a bunch of users. Anyone would be able to understand this, and seeing the representation will just confirm their idea about this resource.

With the URL below, we are getting a list of users.

http://example.com/users

Verbs VS Nouns?

But shouldn't we call it http://example.com/get_users, so people understand it more easily?

The answer is no, but the question itself is not stupid. We just don't have to include this get in the URL because HTTP has us covered already. Thanks to HTTP methods, we are able to extract as much as possible from the URI pointing to a resource. The best practice here is to use only nouns for resources, and not include meaningless verbs or words.

Some people prefer to use singular names for their resources, like user. This choice is up to you, but I recommend simply using the plural version. Whatever you decide, stick to it. Don't use /users and /user/:id in the same API - it's just confusing for developers. Don't forget that your goal is to build something easy-to-use for them, not you. Think about them before thinking about what you prefer.

Going further

As said at the beginning of this article, you've just read an extract from Master Ruby Web APIs . If you'd like to learn more about HTTP and how to build web APIs with Ruby, feel free to check it out. While the book is targeted at web APIs, you will still learn a ton of ways to improve regular web applications.

That's it, I said it. It's the only thing you need to remember from this post. If you're working with code, you are already somehow testing, right?

Maybe you do it by hand, you know, manually checking that the feature you just added works correctly. That's a good start!

The problem with manual testing

The problem is that manual testing doesn't scale. Let's say you have an automated email being sent out anytime a user signs up. Are you doing it by hand? Of course not, because it doesn't scale. If you have one new user per day, it might be fine (still, it would be a pain, let's be honest).

When you have 10, 100 or even 100,000 new users every single day, you clearly cannot handle it manually anymore, so you just write code to deal with it. Now, let's go back to testing. The example we just saw is a bit extreme when we're talking about testing, I'll admit it. Still, testing one feature is fine. Once you've added 20, 30 or more features to your application, are you still going to test them all when you change a piece of code?

Your answer is probably no. Personally, I wouldn't do it (and I didn't back in the days) because, well, it would take forever. I'd just test the latest feature I implemented, and maybe one that's related. But I wouldn't realize that X broke in the Y feature. Damn. Quick deploy on a Friday afternoon for a quick adrenaline rush, and off for a weekend at the beach. What I wouldn't realize is the broken checkout process - a colossal loss of $1 billion over the weekend.

Scary story, huh?

It's actually inspired from a real story, but the numbers have been inflated. A lot. Else they would have fired me!

Manual testing has its limits - our limits.

Everything is getting automated in our lives, why not automate the testing of our applications? You know, the applications that we created to automate something else that was too annoying to do manually.

Enter automated testing. It's nothing new. Been around since people started writing code.

Wait... I don't know what is "automated testing"!

Alright. Let's me give you a quick explanation. The idea behind automated testing is to write a piece of code that only has one responsibility: ensure that a specific functionality in your application works as expected.

Automated testing includes the process of writing unit tests and integration tests. While unit tests are meant to test only "one unit" (a single component), integration tests are used to test multiple units, and how they interact together.

Now, let's take a look at some concrete examples. Say we want to test the #add method in the Calculator class below.

# calculator.rb
class Calculator
  def add(a, b)
    a + b
  end
end

And here is the method we would use to test that the #add method works correctly. We first setup an instance of the Calculator class, before using asset_equal (provided by Minitest ), to check that calling calculator.add(2, 4) returns 6 as expected.

def test_add
  calculator = Calculator.new
  assert_equal 6, calculator.add(2, 4)
end

Here is the complete Minitest example, for reference.

require "minitest/autorun"
require "calculator"

class TestCalculator < Minitest::Test
  def test_add
    calculator = Calculator.new
    assert_equal 6, calculator.add(2, 4)
  end
end

Now that you have an idea of what a test looks like, let's talk about why you would want to write them exactly.

Why write tests?

Spending time writing automated tests may seem counter-productive when you're trying to push features out as fast as possible. What you need to realize is that automated tests are an incredible useful tool that have a huge range of benefits:

• Save time & money
• Once you're good enough, you can actually develop faster by reducing the time you spend interacting with a web browser.
• The tests provide instant feedback on your code, allowing quick refactoring, forcing you to write code in a smarter way and reducing the coupling between your components.
• Tests will allow you to catch bugs early on, before pushing anything to production.
• A good set of tests for an application makes it super easy to introduce new comers to the codebase. They can play around, try to fix bugs or add features and the test suite will tell them if they broke anything.
• Tests give you confidence in your code.
• A test suite is an always up-to-date documentation for your code. If someone wants to know how a piece of code works, they can just checkout the logic in the tests.

Even if these don't sound good enough for you, wait until you try it to make a judgement ;)

Going further

Learning how to write tests takes longer than reading an article on the topic. If you're really serious about making your code better, faster and stronger, you might want to checkout this course I'm building: Rails 5 Testing - Why, Where and How? ,