Top 5 DEV Comments from the Past Week

#bestofdev

This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.

@leightondarkins offers their take in What's your most up-to-date opinion on "monolith vs microservices"?:

Leighton Darkins • Jan 30 '20

Start with a Monolith, break into services when it starts to hurt.

Staying with a Monolith when it's causing you pain is bad.

Starting with Microservices without a good idea of where your pain will be is also bad.

As is usually the case, nuance is what's most important here. Both are great, and bad. Picking the right great, and bad, is totally subjective.

In general, for scale, logically breaking things into small-ish pieces is a great idea. Keeping their data isolated is also a great idea. Communicating between services asynchronously is yet another great idea.

Note that none of the above are owned entirely by the Microservices umbrella. You can do a lot of it without breaking your monolith up at all.

For context, my current situation: We need to rewrite and rearchitect a very large, and old, monolith. Here we already know what hurts from years of development experience, so we start with a good idea of what needs to sit in isolation. We also know that we have really ambitious delivery goals, a very large team of technologists (100+), and need teams and services to be able to work and deploy with as few dependencies as possible.

This is the type of situation the concept of Microservices was created to enable. So, like a cat on the internet, if I fits, I sits.

@chadalen talks about a guard clause in The Life-Changing Magic of Flat Code:

Chad Adams • Jan 31 '20 • Edited

This if statement

  if(!isNotUnset) {
    return null
  }

is called a guard clause like you mentioned it's a way to reduce if else blocks. In the end, it makes your code cleaner and easier to read.

@sidvishnoi adds a helpful comment to 3 Weird Things You (Probably) Didn't Know You Can Do With The JavaScript Spread Operator:

Sid Vishnoi • Jan 30 '20 • Edited

As spread operator acts as if we used String[Symbol.iterator], it is better to use spread operator instead of regular String.prototype.split to split given string into characters when the string may involve Unicode characters. It's not foolproof, but better.
For example,

"😂👻".split("") // (4) ["�", "�", "�", "�"] <- wut?
[..."😂👻"] //  2) ["😂", "👻"]

So, if you get asked to reverse a string with JS in an interview, following might be treated as too naive:

function reverse(str) {
  return str.split('').reverse().join('');
}
reverse('foo') // "oof"
reverse('𝄞') // "��"

Following is slightly better:

function reverse(str) {
  return [...str].reverse().join('');
}
reverse('foo') // "oof"
reverse('𝄞') // "𝄞"

</div>

@tiguchi offers an approach that will hopefully make everyone happy in response to 🙏 Please Add .gitattributes To Your Git Repository:

Thomas Werner • Feb 3 '20

There's also an option that makes everyone happy: Let the git installation on a user's machine decide which line ending to use when a repository is checked out:

* text=auto

That way it really doesn't matter and Windows users can still open their files using Notepad if they wish (I'm not judging 😄).

AFAIK line endings are committed to the repository "normalized" as LF, but the checked out version depends on the OS default for line endings.

The setting can be also fine tuned with additional overrides in case there are specific file types that need their line endings preserved (e.g. shell scripts or Windows batch files)