DEV Community: Valentin Radu

Introducing stencil.email

Valentin Radu — Tue, 09 Feb 2021 18:55:06 +0000

stencil.email provides a set of 4 HTML email templates that can be quickly used in just a couple of lines of code.

All templates are:
✅ Responsive
✅ Customizable (colors, text, icons)
✅ Tested on all major email clients
✅ Ready for production

I built this because many times I just wanted to send a simple, but good looking, transactional email without having to pollute my workspace with .html files or rely on hosted third parties.

This is all you need:

const Stencil = require('@radval/stencil')


const stencil = new Stencil('transactional')
const html = stencil.render({
    heading: 'Welcome, Jane! 🎉',
    message: 'We’ve heard you like emails!',
})

Check out the repo for examples and the list of customizable features.

Hope it helps someone out there!

A remote-only jobs newsletter using NextJS and AWS SES

Valentin Radu — Sat, 16 Jan 2021 02:56:20 +0000

I decided to start a newsletter a couple of weeks ago and while I never expected a high number of subscribers, I still wanted to avoid unnecessary costs, so I built it from scratch.

Here's the stack for anyone interested (most are free, open source or with a generous free tier plan)

NextJS
Vercel (these guys are amazing for small to medium project hosting, as I'm sure many of you already know)
mjml (email-ready HTML is a pain without it)
FaunaDB (generous free tier plan, friendly UI)
AWS SES (it's hard to beat their $0.1 for 1K emails, first 62K free)

About the newsletter:

I feel like most of the job postings out there are generic and missing lots of important info:

tools & processes (i.e. teamrank.dev questions)
salary (at least a range)
how long has the position been open
how many candidates applied (at least an estimate)
detailed tech stacks
coworkers expertise and company culture

startremote.dev is an effort to improve that.

Let's build a simple blockchain

Valentin Radu — Wed, 25 Nov 2020 19:37:53 +0000

The problem

How can you trust a data store distributed among an arbitrary number of independent peers? Since each peer has control over its own version of the data, how can you reach a consensus? In a nutshell, these are the main problems blockchain solves.

The core idea revolves around immutability: once written, the data stored in a blockchain can't be modified without consensus between peers and becomes literally impossible to alter as the transaction gets older (because of the computational cost associated with the proof of work, more about it later on).

In layman's terms

Theoretically, you could build a blockchain-like system using only spreadsheets. Each block would be a row and the entire spreadsheet your blockchain. Each row would have a timestamp, some fields where you could store data (e.g. transaction data, account owner, the amount transferred, recipient, etc), a reference to the previous row's hash and the cryptographic hash value of all the fields combined (including the reference field: this puts the chain in the block*chain*).

I'm assuming you're familiar with cryptographic hashing, if not, there are plenty of resources out there explaining it in various levels of detail (starting with Wikipedia). Simply put a cryptographic hash function is a one-way function that always produces the same hash value for the same input in a way that makes it impossible (or extremely difficult) to reverse the process (i.e. to find the original input, given the hash value)

Since all fields get hashed together, any attempt to modify one would automatically result in a different hash value for that specific row.

So, in order to modify our table and keep the blockchain valid we would have to:

change the row
recalculate its hash value
recalculate all the hash values of the subsequent rows since they won't have the correct previous row hash value anymore

This is time-consuming for a human, but nothing for a computer. The hashes can be recalculated in less than a second even for a large blockchain.

This poses a problem. When picking between two conflicting versions of the chain, the one that required the most computational effort (combined among multiple peers) wins. If chains can be easily altered and recreated the CPU time race turns into a bandwidth race slowing down the entire system.

That's why blockchain requires proofs of work: computing a hash value might be fast, however, computing a hash value with a certain constraint (e.g. n leading zeros: normally an SHA hash looks like this 979c8b5f0598fec69..., our constraint would require a new field, the nonce, be tweaked until the hash starts with a certain number of zeros, 0000001fb32013...) requires significantly more time.

The best way to learn is by building

The first thing we need to consider is the block. Like in the spreadsheet example each block has a timestamp, data, and a reference to the previous block. In addition, we have a method to serialize our block (toString - in a more realistic setup we would also have one to deserialize it), one that calculates the hash based on the current fields, and some setters. Nothing spectacular so far.

class Block {
    /**
     * Represents a block
     * @constructor
     * @param {number} timestamp - The timestamp of the block creation
     * @param {data} data - Arbitrary data we wish to store in the block
     * @param {object} prev - A reference to the previous block, if any
     */
    constructor(timestamp, data, prev) {
        assert(timestamp)
        assert(data)
        this.timestamp = timestamp
        this.data = data
        this.nonce = 0
        this.prev = prev
    }
    /**
     * Used to update the nounce in order to get a different hash value.
     */
    randomizeNonce() {
        this.nonce++
    }
    /**
     * Calculates the hash of the block based on its string representation
     */
    calculateHash() {
        return crypto
            .createHash('sha256')
            .update(this.toString())
            .digest('hex')
    }
    /**
     * Once we know the required hash, we seal the block by setting its hash
     * value.
     */
    seal(hash) {
        this.hash = hash
    }
    /**
     * Returns the string representation of the block
     */
    toString() {
        return (this.prev && this.prev.hash || '') + '\n' +
                JSON.stringify(this.data) + '\n' +
                this.timestamp + '\n' +
                this.nonce
    }
}

Next, we need to create a class responsible for calculating the block's zero prefixed hash. Doing this requires multiple tries and therefore time.

class Miner {
    /**
     * Represents the entity that does the work calculating the required hash for each block.
     * @constructor
     * @param {number} complexity - In our case, the complexity is the requireed number of zeros in front of our hash value. As we increase this value the time and resources needed to compute the hash increases *exponentially*.
     */
    constructor(complexity = 1) {
        this.complexity = complexity
        this.prefix = new Array(this.complexity + 1).join('0')
    }
    /**
     * Mining basically means finding a nonce which hashed together with the rest of the fields, the output hash will be prefixed with a number of zeros equal to the complexity.
     */
    mine(block) {
        let hash = ''
        while(!this.isHashValid(hash)) {
            block.randomizeNonce()
            hash = block.calculateHash()
        }
        block.seal(hash)
    }
    isHashValid(hash) {
        return hash.startsWith(this.prefix)
    }
}

And finally, the piece that puts everything together. Adding a block to the chain is straightforward enough: we create it using the current timestamp and a reference to our last block, mine its hash then simply replace the last block with our newly created one.

Things get more interesting in the isValid method. To validate the entire blockchain we need to:

go through each block
check the proof of work by ensuring the hash starts with the given number of zeros
check the hash (there's a small catch here, when we calculate current hash we also include the previous block's hash and thus validating the link between them)
finally, when we reach the last block we need to make sure it's the same genesis block as the one we created, otherwise the blockchain could be valid, but it might not be our blockchain.

class Blockchain {
    /**
     * The aggregator that puts everything together
     */
    constructor() {
        this.genesisBlock = new Block(Date.now(), {})
        this.lastBlock = this.genesisBlock
        this.miner = new Miner(2)
    }
    /**
     * Adds a new block with the given data
     * @constructor
     * @param {object} data - Arbitrary data
     */
    addBlock(data) {
        const block = new Block(Date.now(), data, this.lastBlock)
        this.miner.mine(block)
        this.lastBlock = block
        return block
    }
    /**
     * Checks if the entire blockchain is valid
     */
    isValid() {
        // we start with the last block and while there
        // is a previous block before it 
        // (in other words, it's not the genesis block),
        // we check its hash with the value we compute using
        // the current data (possibly tampered) and the previous'
        // block hash
        let block = this.lastBlock
        while (block.prev) {
            if (!this.miner.isHashValid(block.hash) ||
                block.hash != block.calculateHash()) {
                return false
            }
            block = block.prev
        }

        // if we reach the last block, we compare it with the 
        // genesis block to be sure not only that the blockchain is
        // valid but also that it's **our** blockchain
        if (block.toString() != this.genesisBlock.toString()) {
            return false
        }

        return true
    }
}

And there you have it. Your own toy blockchain. Feel free to give it a spin:

const blockchain = new Blockchain()

const quiBlock = blockchain.addBlock({
    name: 'Qui-Gon',
    order: 'jedi'
})
const obiBlock = blockchain.addBlock({
    name: 'Obi-Wan',
    order: 'jedi'
})

// the block should be valid
blockchain.isValid()

// tampering with the data
firstBlock.data.order = 'sith'

// the blockchain is not valid anymore
blockchain.isValid()

FAQ

Where does the data (i.e. the actual bytes) lives?
Blockchain data (e.g. the string representation of each block, one after the other) lives on each of the peers which are actively taking part in the blockchain network. There is no central storage authority/entity.
What happens if one peer tries to fraudulently modify the blockchain?
To keep the blockchain valid, it would have to modify the hashes of all the blocks following the one that he alters. That would take a lot of time, depending on the size of the blockchain. Even if it manages to do it somehow, since there are usually many other peers in the network with the blockchain unaltered, the majority would win when reaching consensus. Modifying the blockchain requires control over 50% + 1 of the network and a lot of computing power.
I don't have a distributed network at my disposal, how can I use blockchain technology?
There are lots of options out there like the Ethereum project that allow you to use their network to store arbitrary data.

AWS Lambda + Rust

Valentin Radu — Tue, 10 Nov 2020 17:19:05 +0000

This article was first published on techpilot.dev
TL;DR: There's an example repo here for those who want to skip the story mode

Rust piqued my interest when I found out it consistently ranked first in the StackOverflow's annual developer survey for the world's most loved programming language. Here's the 2020 survey, but it also holds the first position for 2019, 2018, 2017, and 2016.

It turns out it's as awesome as they say and now I'm in that particular moment in the hype phase when I try to do everything in Rust. I know that's a terrible idea and I strongly advise against it: pick the language that has the strongest support (aka libraries, community) for the problem you're trying to solve. Doing ML in Rust when Python is de facto standard is not such a great idea.

Anyways, I figured I can make an exception and since I'm not that excited about any of the popular backend languages, I started to experiment in that direction.

Running a Rust HTTP server using Rocket is really easy and well documented, however, if you plan to go serverless, there's still a lot of uncharted territories.

For AWS Lambda, there are a couple of resources out there, but many are outdated or somehow incomplete.

Here are the main steps we'll have to follow:

implement the lambda handlers
(cross)compile our code for the Amazon Linux platform (x86, 64bit)
build each lambda as a standalone binary
configure AWS Lambda for deployment
deploy & enjoy

So, let's get started!

# create a new crate
cargo new rust_aws --bin
# delete the main.rs, we'll be using a binary for each lambda
cd rust_aws && rm src/main.rs
# these are the two lambdas we're going implement
touch src/comment.rs
touch src/contact.rs

Next, our dependencies in Cargo.toml

[package]
name = "your_proj_name"
version = "0.1.0"
authors = ["You <you@example.com>"]
edition = "2018"

[dependencies]
lambda_runtime = "0.2.1"
lambda_http = "0.1.1"
tokio = { version = "^0.3", features = ["full"] }

[[bin]]
name = "comment"
path = "src/comment.rs"

[[bin]]
name = "contact"
path = "src/contact.rs"

A couple of things to mention here.
First, we have the lambda_runtime and lambda_http crates which are responsible for communicating with the Lambda API. This usually means running the setup code, fetching the handler name from an environment variable, and passing events to our code. You can find out more about how custom runtimes work here.

Although lambdas are stateless, AWS can run our binaries and send multiple events to the same process, as long as the process doesn't exit. This requires an event loop: a fancy way to handle asynchronous I/O and scheduling. We use tokio for that.

Finally, we declared 2 different binaries, one named comment, the other contact and each will be deployed as a standalone lambda function

Next up, compilation. Unless you're on an x86, 64bit Linux machine, you'll have to cross-compile your code. To do so, we need the correct toolchain:

# adds the x86 64 target to the toolchain
rustup target add x86_64-unknown-linux-musl
# installs the x86 64 toolchain on macOS (for Windows, you can probably do it with cygwin-gcc-linux, but I haven't tried it out)
brew install FiloSottile/musl-cross/musl-cross

Lastly, we need to let cargo know we're cross-compiling: add the following in ./.cargo/config.toml

[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"

Now we're ready to compile. cargo build --target x86_64-unknown-linux-musl to test it out.

The next thing we need to do is to configure SAM. I'll assume you're already familiar with SAM and focus only on the critical section for our case. You can have a look at the full template.yml in the example repository. Also, skip sam init since there is no Rust template available anyhow (to my knowledge) and simply start with the template.yml file and build your own directory structure.

Let's go through the one of the lambdas' definition:

# template.yml
Resources:
    Comment:
    Type: AWS::Serverless::Function
    Properties:
    FunctionName: Comment
    Handler: doesnt.matter.the.runtime.is.custom
    Runtime: provided
    MemorySize: 128
    Timeout: 10
    CodeUri: .
    Description: 
    Policies:
        - AWSLambdaBasicExecutionRole
    Events:
    comment:
    Type: Api
    Properties:
    Path: /comment
    Method: post

This tells SAM to create a lambda serverless function named Comment, with a custom runtime (handled by or Rust lambda_runtime) and expose it as a REST API resource at /comment.

We're almost done. One last (important) thing: when we build and deploy our lambdas with sam build && sam deploy --guided SAM will look for a Makefile since it doesn't know how to build our project by itself.

touch Makefile

build-Comment:
    cargo build --bin comment --release --target x86_64-unknown-linux-musl
    cp ./target/x86_64-unknown-linux-musl/release/comment $(ARTIFACTS_DIR)/bootstrap

build-Contact:
    cargo build --bin contact --release --target x86_64-unknown-linux-musl
    cp ./target/x86_64-unknown-linux-musl/release/contact $(ARTIFACTS_DIR)/bootstrap

The way this works is straightforward, you need to add a target for each lambda name and prefix it with build-. That's it. SAM will invoke them as needed.
Each target builds the respective binary (--bin contact) and copies it in the artifacts directory, where it will be zipped and sent to the AWS servers for deployment.

And that's it. We're done. Have fun with your new Rust-powered AWS lambdas!

How to spot a great team during interviews

Valentin Radu — Sat, 31 Oct 2020 00:02:23 +0000

I've published this article on my blog in April, and it ultimately led to teamrank.dev, an app that ranks teams based on ideas presented here. Feel free to try it out and share your results!

How?! Well, by asking the right questions! 😁
While at techpilot.dev I've had my fair share of interviews, and although I've heard the most intriguing answers to the technical questions, one thing was always the same: it seems very few really want to know more about the team they might join in the future. 😅

I think it's a wasted opportunity, so here are a few ideas on what to ask.

Workflow

How do they manage requirements and feature specs?
What tools do they use in the process?
Who is writing the specs? (i.e. there should definitely be someone and the answer should be prompt)
Is the release process well defined?

Issues and bug management

Are bugs fixed before writing new code?
Where and how do they track bugs and issues?
How do they prioritize and sort bugs? Who does that?

Testing

Who's doing the manual/integration testing? (e.g. ideally a designated tester)
Does the project have unit tests? What's their coverage?

Release cycle and automation

Do they use CI? If so, how's the setup?
What tools do they use? (e.g. Jenkins, Github Actions, etc)
Do they build a daily/nightly version?

Growth

If hired, will you have a mentor or a person that can help you with your career path?
Do they review code? At what point in the development lifecycle? Who does it (i.e. peer, lead, etc)
Do they have a library or do they buy tech books for their employees?
Will there be any opportunities for greenfield projects shortly? (starting a project can be challenging, but also a great way to learn things!)

Workspace

Is it quiet?
How crowded is it?
What equipment does each dev get (in general look for companies which understand that equipment affects your productivity)

Codebase, frameworks, and tools

How old is the project? (the older, the greater the chance it's messy)
What stack and tools do they use? (keep in mind you want a job where you fit or one that you can easily adapt to, so even opinionated views matter)
Did they adopt a coding style? If yes, do they enforce it with a linter?

Team

How large is the team you're going to be part of if hired?
Who else shares similar responsibilities? (i.e. you want to avoid 1-man teams unless you know exactly what you're doing)

And if you're feeling bold:

Ask how did they solve a particular task or architectural problem that you have previous experience with (e.g. "How do services communicate with each other?", "How are the private keys stored securely?", etc)
Ask about the current team members' backgrounds. Make it clear you're not looking for personal information, but you're interested in the team maturity and experience (things like years in the field, areas of expertise, etc)

Finally, here are some things to avoid:

Don't ask about things you're not genuinely interested in. Be frank and to the point. A never-ending interview can also mean a predisposition to never-ending meetings. (on both sides)
Generic, mindless, low-effort questions. Although HR might like it, in a technical interview is best to avoid them and be spot on instead. Things like "How does your team approach problems in general?" "Are there opportunities for professional development?" should have an answer in the more detailed questions above. Asking them directly doesn't help anybody. Is like asking "Is this job good?". "Yes!". "Ok, that's all I wanted to know!".
Personal details. You might think it would set a more familiar and relaxed tone, however, people have different views on it, and assuming otherwise is gambling with your chances: you might win, but you might also lose.

A practical guide to microservices

Valentin Radu — Wed, 10 Jun 2020 14:57:35 +0000

First published on techpilot.dev

Microservices are the natural evolution of monolithic systems in an increasingly demanding, modular, and distributed industry. The strongest argument against them is usually the implied complexity, debugging, and deployment challenges coupled with the poor development experience for small teams/projects.

In practice, most of these problems come from suboptimal implementations, not from the architectural pattern itself. There's still lots of confusion around microservices. Almost every time I bring the topic up, I find someone with a new, unique understanding of it. So, here's my (opinionated) attempt at debunking some of these myths and hopefully help you navigate these stormy waters.

Take it step by step. Between a seemingly steep learning curve and the multitude of overlapping tools and frameworks out there, things can quickly become overwhelming
Evolve your architecture using only tools that solve the problems you know you have, not problems you might think you'll have at a one point.
It's perfectly fine to start with a "monolith": all actors in one place, but try to design it in such a way that it won't require a tremendous amount of effort to migrate each actor in its own process.
To achieve this, use standard best practices: inject dependencies, favour composition over inheritance, have a test-driven approach, encapsulate external dependencies etc. I'd argue that by adding a messaging queue to a well designed, modular "monolith" automatically turns it into microservices. Which takes us to our next topic.
Use a messaging queue right from the start. Using a messaging queue, something as simple as Redis pubsub or as sophisticated as RabbitMQ will allow you to draw hard lines between your components and stop caring if they run in the same process, on the same machine or even in the same data center.
Draw seams based on the problem domain What is a microservice after all? Where do we draw the line between units in our system? Is paramount that the answer to these questions is problem domain-driven. Don't expect a certain count or size, just split them however comes natural for the problem you're trying to solve.
Avoid breaking-up your components too early Your enemies here are boilerplate code and lack of domain knowledge. Lay down strong foundations using the best practices you already know and let your system grow.
When you start a new project you usually don't have enough domain knowledge to correctly define your seams. Breaking-up your system into too many parts early will result in lots of boilerplate code for little functionality.
Start small, grow steady. For example, an online store, could only have 4 microservices in its first iteration: account, payments, orders and notifications. Later as your solution matures, you could add inventory, affiliates, tracking, suggestions and so on.
Validate both the input and the output of each microservice You should reason about each unit of your system in isolation. This is not necessary microservices related, it's architectural 101. Each unit will have an API, a set of functions and capabilities exposed to its peers. Its input and output should always be validated.
Develop and debug in-process As much as possible try to take architectural decisions that don't impair your ability to load all your microservices in a debugger within the same process if needed. This is priceless for development speed and bugfixing.
One of the traditional advantage of microservices is the ability to use different technology stacks for various parts of your system, but this comes with a high price, use it wisely. Having a cohesive development and debugging process is much more important, especially for a small team or solo developers.
Don't let the persistence layer drive your architecture There's a misconception that you have to choose between sharing a database among your microservices and have database per microservice. In truth, it doesn't matter, the only thing that matters is that each microservice owns its data store. That means, two microservice should never query or reference the same data store. You can achieve this in many ways, but some make it harder to brake the rules we mentioned above, like having a microservice per database, or per schema (which is what I usually prefer, since it's a design that allows you to deploy both on the same and different database).
Replicate data to completely separate data stores Lets imagine we have an online store that has an account and order component, among others. As we learned earlier, the data stores of these two should be owned by each. However, the order needs to know its owner (aka the entity who place it), so how should we approach this?
In a monolith this would be a foreign key in database, but this breaks the ownership rule, the order service's database should not reference the account's id since they might not even be on the same machine.
One elegant way to solve this problem is using data replication. The order's database could have one table only with unique owners ids. These would be populated by events in your system: every time a new user is added the account microservice broadcasts their ids and the order microservice (and probably others too) adds them to the owners manifest.
Authorize using JWT and similar technologies The simplest way to handle authentication/authorization is to skip the central authority and use technologies like JWT to verify claims without leaving the process (or without calling another microservice). There are many options here and it really depends on the security level your apps requires, but in general for highest security each microservice should check the authorization and permissions before doing anything, no matter how small, while for convenience this can be done at the gateway level only (aka in the component that exposes the public API). I usually go with the former since I think the added security justifies the small overhead of locally checking the identity each time.
You don't have to deploy using Docker or Kubernetes right from the start Don't get me wrong, these are great technologies, but both add another layer of complexity to your app. You should consider learning them based on the return of investment rule: does the added complexity and time spent on learning these tools justifies the advantages? Unfortunately, this is a bit difficult to answer. That's why it think it's better to start small.
If your project uses a popular stack, one of the PaaS out there (e.g. Heroku) is probably a much better fit. There's a strong tendency of overcomplicating things when it comes to microservices deployment.
Don't forget, microservices are an architectural pattern than can be used no matter how or where you're deploying your app. Your ultimate goal should be to have a clean, scalable solution that doesn't require disproportional effort to build and maintain.
Monitor your cluster Logging and monitoring helps you find issues early and react accordingly.
Avoid third-party or self-made realtime logging libraries (aka you should never make an in-process remote request to log things). Simply log everything using stderr and stdout (with something as simple as debug), then aggregate your logs. If you're using a PaaS, this last step might be already done for you.
Testing is a must Write unit test, write integration tests, write end to end tests. In inverse order of their magnitude (i.e. unit tests should come in the largest number). Also, each bug you ever find should have corresponding unit test. With microservices unit testing is not optional, you will never be able to reason about your system as a whole if you can reason about it in isolation.

Are unit tests a waste of your time?

Valentin Radu — Sun, 07 Jun 2020 22:36:00 +0000

First published on techpilot.dev

TL;DR In a perfect world, we would have automated tests for everything, but in reality, there's always a compromise between code quality and costs.

I've been lucky enough to start a fair amount of greenfield projects in the past years. Looking back, I feel like writing tests had always saved time in the long run but were rather cumbersome when working on UI and smaller projects.

It goes without saying that for some apps (i.e. life-critical, mission-critical) an unit test coverage of 80%+ should be required. But, despite what most of the literature says, in some cases, unit tests are actually slowing us down. In which case, how do we decide if it's worth the trouble and keep a balance between quality and costs?

Here are a couple of things to consider.

Debugging process Remember when you had that one awkward bug, and it took days only to reliably reproduce it? Unit tests allow you to control the state of your components in great detail, making it easier to find and fix such issues.
Reusability and life span If you wrapped up some code in a reusable library, chances are you'll improve it frequently in the beginning. Unit tests can help you ensure no breaking changes sneak through each iteration.
Complexity When you can't reason about a system in the wild, it helps to frame it in isolation. Unit tests do just that.
Third-party dependencies Software requires the perfect alignment of many moving parts, some of them not under your control. When third parties act unexpectedly, it becomes almost impossible to debug your system. Mocking dependencies in your unit tests solves this.
Costs If you think you don't have enough time to write unit tests it automatically means you're ready to trade quality for it. This might work in some scenarios (e. g. proof of concepts), but you must be aware of the implications.
Team size You'll find that as you make your code testable, you also increase its intrinsic quality. Also, unit tests are the closest thing to written specs, and while you can manage without any formal requirements while working on a part-time project by yourself, larger, heterogeneous teams would have a hard time doing so.

Unit testing is time-consuming, especially if you have a poorly designed codebase. You can decide to skip it, and it might be the right thing to do, depending on the context, but you'll have to trade code quality in return.