
_Object-Oriented Programming (OOP)_ is one of the most popular paradigms when it comes to building software, however, the more I learned about JavaScript, I got introduced to _Functional Programming (FP)_, a completely different way of thinking. In this article, I'll share with you what I've learned and I'll explain to you using my own examples.

Example: You want to build a game, where the main character is a student in Hogwarts and he's learning witchcraft from his teacher.
So you create a _Student_ Class where your student object will be able to take tests, and you have another class called _Teacher_, where the teacher object will be able to grade Tests.

```js
Student.takeTest();

Teacher.gradeTest();
```

Assuming you want to add some features like eating, sleeping and walking, you'll end up with something that looks like this

```js
Student.takeTest().sleep().eat().walk();

Teacher.gradeTest().sleep().eat().walk();
```

The problem is that the code above doesn't follow the DRY principle, which stands for ( Don't Repeat Yourself), so the solution is to create a _parent_ class where we put the sleep, eat and walk features. So we end up with something like this:

```js
Human.sleep().eat().walk();

Student.takeTest();

Teacher.takeTest();
```

Yaaay problem solved! everyone's happy. However, a few months later, to make your game even more exciting, you decide to add another character to your game, let's say you want to add a dragon. This is what you end up with:
SO you end up with something like this:

```js
EvilDragon.breathFire().fly();
Human.sleep().eat().walk();

Student.takeTest();

Teacher.takeTest();
```

While this is great, you're not satisfied, so you decide to make the game more realistic by giving your dragon abilities like humans, you want your dragon to be able to sleep and eat, so you end up with something like this:

```js
GameObject.sleep().eat();

EvilDragon.breathFire().fly();

Human.walk();

Student.takeTest();

Teacher.takeTest();
```

Now, this is working completely fine, but assuming that in your game, the teacher, after careful study of witchcraft, was able to create a cape that allowed him to fly.
Now comes the problem: _how_ do you structure your project? you can't add the flying ability to the humans class because not all humans can fly, and you can't make the teacher inherit from the EvilDragon Class, because the teacher can't breathe fire.
There is a solution it's to add features that will never be used by the teacher object to make him able to fly, like breathing fire. However, this is like asking for a banana and receiving a gorilla holding a banana.
So now, you've hit a wall, you can't turn your game idea into a reality.
Of course, you can repeat yourself, but since you're an excellent developer who cares about every line of code he writes you won't do that.
Don't worry though, there is a solution: **Composition**

With inheritance, you structure your classes around **<Highlight type="underline" content="what they are."  color="var(--color-text-accent)"/>** With functional programming, you structure your classes on **<Highlight type="underline" color="var(--color-text-accent)" content="what they do" delay={4000}/>**.

By favoring composition over inheritance and thinking in terms of what things _do_ rather than what things _are_, you free yourself of fragile and tightly coupled inheritance structures.

Here's a snippet of what our code might look like in our game when we think in terms of objects:

```js
class Teacher {
  constructor(name) {
    this.name = name;
  }
  sleep() {
    setTimeout(console.log("Damn, that was a great nap"), 8000);
  }
}

const teacher = new Teacher(Dumbledore);
teacher.sleep();
//outputs 'Damn, that was a great nap' after 8 seconds
```

When we write our project using a functional approach we end up with a collection of stand-alone functions, each one of them serving a single purpose, which facilitates maintainability and makes debugging easier since we can predict the outcome of a function. When creating an object, we simply import all the functions that we need.

```js
//same code rewritten using factory functions
//factory functions are functions that create objects
//we will use
const sleep = () => {
  return setTimeout(console.log("Damn, that was a great nap"), 8000);
};
Object.assign();
```

Which one wins? well normally you would use inheritance when there is a _relation_ between objects, like me, Mahmoud, I'm a human, so I will inherit all of the things that a human has. On the other hand, you would use composition for example when an object _has_ a certain feature, like for example a car will have an engine component.

However, this is not completely true because, for example, a car is a vehicle and me Mahmoud, I have arms and I can lift things. So, in reality, you can follow any of these patterns.
Buuuut, composition is easier to debug, maintain, everything is encapsulated and in a project, you can easily add features.


A comparison between Object-oriented programming and Functional programming

Composition Over Inheritance


## Consistency Is Hard

I heard about the 100 days of code challenge around two years ago when I got into web development. It's a challenge where you're supposed to code at least 1 hour a day for 100 days straight.

I failed at it. _HARD_.

I just couldn't manage to stay consistent.

Some days I coded, others I didn't.

Some days I felt inspired and motivated, other days I felt like crap and I couldn't get anything done.

Some days I was just, well, busy. Life got in the way.

Coding 1 hour a day for 100 days, sounds easy, but it's not. The consistency aspect is super hard. At least for me.

So after multiple tries, I've accepted defeat.

## Going with the flow

I decided to go with the flow. Code depending on how I felt.

So some days I'd code for 5-7 hours, and on these days everything would just magically work ✨

That code snippet I copied from stack overflow? Runs the first time.

I Encounter a bug? The answer was the first one on Google.

On other days though, things were _slow._ Nothing seemed to work, I felt stuck, and I wasn't focused at all. Sometimes it feels like the only productive thing I've done during the day was running `npm install`.

What's also weird was I had no in-between. It was binary.

Either I'm super productive, or a potato.

With time though, I managed to accept it.

Getting used to this cycle made me happier since I didn't feel guilty all the time.

For all beginner developers out there, I want to let you know that It's okay not to be productive every day. It's okay to stumble, struggle, and be stuck. In fact, it's part of the journey.

If you're productive and in the zone, enjoy it while it lasts.

If you're stuck, ask for help or take the day off. It's fine. You can always try again tomorrow.

Now some of you might find a hard time believing what I'm saying. You might be worried that missing a couple of days will greatly impact your progress as a developer.

I'm here to tell you it won't.

## What truly matters: doing your best

In reality, what matters is the _total_ hours spent.

Two people can end up coding the same amount even if they follow different schedules.

![Comparison between two developers, 1 coding for 1 hour daily and one that goes with the flow](https://dev-to-uploads.s3.amazonaws.com/i/6wkpqcgg0wu31o7hzi4h.png)
Here you can see that in the weekly progress chart, the person coding 1 hour a day codes for 7 hours per week, while the other person codes the same amount but for fewer days.

And for the total number of hours spent coding during the year, the person that went with the flow spent on average the same number of hours as someone that coded 1 hour every day.

I'm the second type, and luckily, I track how much time I spend on my text editor.

I use [Wakatime](https://wakatime.com), which is a VSCode extension that tracks the amount of time you spend coding. I installed it on December 24th, 2018. Since then, I've coded for a total of 1218 hours.

This is what my chart looks like

![WakaTime Chart](https://dev-to-uploads.s3.amazonaws.com/i/ai5rsgttne3aczehttjd.png)

As you can see, I have times where I coded consistently, others I had _zero_ activity.

The moral of the story, do what works best for you.
Don't feel like you have to follow a specific schedule religiously to get better. Just make sure you're always trying to get better. Eventually, you will.

The funny thing is, 1218 hours in two years is around 1.7 hours per day. So I guess I did complete the challenge after all.

## Track how much you work, but don't obsess over it

Tracking the number of hours is not the best metric, the quality of the time matters too. You should strive to achieve both quality _and_ quantity.

These numbers also do not show the full picture. They don't include the time I spent reading other people's code (which taught me _a lot_), watching talks, reading blog posts, and meeting new people.

However, I think tracking helps in keeping you accountable and it can also act as motivation.

Do your best, trust the process, and remember: you're only competing with yourself.


Reflections on how I failed the 100 days of code challenge

How I Failed The 100 Days Of Code Challenge


In this article, you're going to learn what end-to-end type-safety means and why it's beneficial.

The only prerequisites needed are:

1. Have some basic JavaScript knowledge.
2. Understand how full-stack Web Apps work.

## Type-Safe JavaScript

You're working inside a JavaScript codebase, and you find the following code block:

```js
const constructFullName = (firstName, lastName) => {
  return `${firstName} ${lastName}`;
};

constructFullName("Mahmoud", "Abdelwahab"); // "Mahmoud Abdelwahab"
```

This is a function that takes two parameters, a first name, last name, and returns the full name as a string. Seems pretty harmless right? Well, what happens when you call this function and pass it only one argument? The other one will be undefined.

```js
const constructFullName = (firstName, lastName) => `${firstName} ${lastName}`;

constructFullName("Mahmoud"); // "Mahmoud undefined"
```

A quick fix is to set a default value for the parameters to avoid this behavior, this way if we don't pass any parameters we won't get undefined.

```js
const constructFullName = (firstName = "", lastName = "") =>
  `${firstName} ${lastName}`;

constructFullName("Mahmoud"); // "Mahmoud"
```

But what if we want all parameters to be required, to construct a full name, we need _both_ the first name and the last name. We want the developer that will call the function to always pass the two arguments.
Here's one way to do it:

```js
const isRequired = () => {
  throw new Error(`param is required`);
};

const constructFullName = (
  firstName = isRequired(),
  lastName = isRequired()
) => {
  return `${firstName} ${lastName}`;
};
constructFullName("Mahmoud"); // Error: param is required
```

We're setting a function as the default value for the parameters, if we don't override this function by passing an argument, we will get an error.

This works but what if we want to strictly pass strings to the function? We can do this:

```js
const isRequired = () => {
  throw new Error(`param is required!`);
};

const constructFullName = (
  firstName = isRequired(),
  lastName = isRequired()
) => {
  if (typeof firstName !== "string" || typeof lastName !== "string") {
    throw new Error(`you must pass a string to this function!`);
  }
  return `${firstName} ${lastName}`;
};
constructFullName("Mahmoud", "Abdelwahab"); // Mahmoud Abdelwahab
constructFullName("Mahmoud", someVariable); // Error: you must pass a string to this function
```

Notice how much work is done for _one_ function, just to prevent us from making these mistakes and leading to unpredictable behavior. This is of course not ideal since this process is slow and tiring.

JavaScript is a weakly typed language, it doesn't enforce types. A variable can be assigned a string but later can be assigned a number. JavaScript won't complain.

```js
let age = "Twenty One Years Old";

let age = 21; // no problem
```

This behavior makes type mismatches the most common type of error: a certain type of value is expected ( String, Number, Boolean, etc. ), but another is received. This can happen due to a misunderstanding of the API, typos, or by making a mistake.

Finally, an important thing to note is that the errors we're throwing in the code above will be thrown during _runtime_, they'll only appear _after_ we run our app. This means without proper testing we may ship code that can break our app.

All of this affects developer productivity but also it makes developers less confident with the code they're shipping. Fortunately, it doesn't have to be this way. TypeScript to the rescue!

### What is TypeScript?

TypeScript is a superset of JavaScript, developed by Microsoft and got released to the public in 2012.

It's scalable, type-safe JavaScript that catches type errors during compile time.

We assign types using the following syntax:

```ts
// age has a type of number

// TypeScript also infers types, however adding types makes the code readable and more predictable.

let age: number = 21;
```

Here's an example where we try to assign the variable `age` a string, which is the wrong type.

TypeScript prevents us from doing this and throws an error. We wouldn't be able to compile this code.

![Type Safe JS](https://user-images.githubusercontent.com/27310414/98813184-7715a400-242c-11eb-945a-be30c26f9455.gif)

Let's go back to the `constructFullName` function we defined above using JavaScript, this time without checking the type of parameters or making sure that we passed them. Here are different inputs to the function and their outputs:

```js
const constructFullName = (firstName, lastName) => {
  return `${firstName}, ${lastName}`;
};
constructFullName("Mahmoud", "Abdelwahab"); // Mahmoud Abdelwahab
constructFullName("Mahmoud", 21); // Mahmoud 21
constructFullName("Mahmoud"); // Mahmoud undefined
constructFullName(); // undefined undefined
```

With TypeScript, all we need to do is define the **argument(s) type(s)** and the **return type** of the function.

In our case we want the `constructFullName` function to take 2 strings as a parameter and to return a string. Here's the same function but written in TypeScript:

```ts
const constructFullName = (firstName: string, lastName: string): string => {
  return `${firstName}, ${lastName}`;
};
```

If we try the past examples we automatically get an error, _before_ running our code. TypeScript detects errors _as we type_ our code.

![TypeScript type checking example](https://user-images.githubusercontent.com/27310414/98815425-c6a99f00-242f-11eb-8f44-e583bc6a75b3.gif)

Notice how TypeScript auto-completes the function name, displays the function's arguments with their types and the return type of the function.

Also, if we don't provide **all** the arguments with their **correct types** we automatically get an error.

### Why Type-Safety is Beneficial To Developers

When using a type-safe language like TypeScript you get a ton of benefits:

- Code is self-documenting: No need to add lots of comments, you can understand what a function does from its types
- Code is predictable
- Less unit tests to write
- Awesome Developer Experience in VSCode
  - Refactoring is easier
  - Auto-import: VSCode automatically adds any missing imports (No more errors due to forgetting to import a file/library)
  - Auto-complete

In conclusion, you feel more confident in the code you write and ship.

> But isn't this more work?

When a codebase grows and becomes more complex, you want to be able to make changes and add more code with confidence. With TypeScript you start slow but your productivity in the long run drastically increases, with JavaScript it's the opposite. Think of it as an investment that will pay off in the future.

![TS vs. JS](https://user-images.githubusercontent.com/27310414/98849786-6bda6c80-245c-11eb-9259-88b0ca746fe3.gif)

---

## Type-safety In The Context of Full-stack Web Apps

We've already discussed how Type-safety is beneficial to developer productivity and project scalability. It's even more important in the context of full-stack Web Apps.

To fully understand "end-to-end" type-safety we need to go over how a web app works.

This is a "traditional" monolithic web app architecture, you have several components interacting with each other through a request/response cycle. While there are other types of architectures this is the most common one and it's the one we'll be focusing on in this article.

![Web App Architecture](https://user-images.githubusercontent.com/27310414/98822179-2ce6ef80-2439-11eb-9325-21badeb12616.png)

- Front-end: What the user sees and interacts with. It can be a Web App, a Mobile App, a Desktop App, etc. In the context of Web Apps, you write it using HTML, CSS and JavaScript. Most likely you'll use a front-end framework like (React, Vue, Angular, etc.).
- API: how the front-end interacts with the server. The most popular types of APIs are REST and GraphQL APIs.
- Server: Contains the core business logic of the app. It can be written in any language like JavaScript, Python, Java, Go, Rust, etc.
- How the server interacts with the database. Usually through on ORM/ query builders/ raw Database queries. Here's a [comparison](https://www.prisma.io/dataguide/types/relational/comparing-sql-query-builders-and-orms) between each way.
- Database: where data is persisted and stored. Can be relational, document-based, key-value pairs, etc.

Now as you can see, we have a lot of options when it comes to each component in the stack each option offering some advantages and drawbacks. We'll be taking a look at different stacks and comparing them:

### Full-stack Apps and REST APIs

If you're working with REST APIs and full-stack JavaScript you're not getting any type-safety, this will lead to unpredictable code, unnecessary bugs, and slowdown the development process.

> Will using TypeScript help?

Writing the front-end and the backend in TypeScript doesn't make an app type-safe, this is because the API that's connecting them is not typed. The system is as strong as its weakest point, in this case, it's the API.

Developers working on the front-end will have to _assume_ the type of the returned data when interacting with the API. Since there's room for assumption, type mismatches can occur often and thus slowing down the development process.

We also have **multiple sources of truth** for our types and they can easily get out of sync.

Here's a visual summary:

![Full stack TS + REST](https://user-images.githubusercontent.com/27310414/98855089-2326b180-2464-11eb-910d-285ef71dd626.png)

Furthermore, when using a REST API, you encounter the following problems:

1. Maintaining documentation for the API: You need to define all of the endpoints, their parameters, and the values they return (including errors). For example, check out [GitHub's REST API documentation](https://developer.github.com/v3/)
2. Overfetching: the endpoint returns more data than you need.
3. Under-fetching: the data you need is spread across multiple endpoints and you have to manually stitch them together.
4. The returned data is _not_ typed, which affects developer productivity and the code quality (How well it scales and how predictable it is).

Fortunately, there is a better alternative: **GraphQL**.

### GraphQL: The New REST

If you're not familiar with GraphQL it's a new way to build APIs. Instead of defining multiple endpoints you define a single endpoint and interact with it. It also solves the issues that REST APIs have:

1. You only **ask for the data that you need** so no more under-fetching or over-fetching
2. **Documentation is automatically generated**, so no need to document any changes.
3. It's a spec: all GraphQL APIs work the same, so there's **no learning curve**. (REST APIs can be built in different ways)

What's great about GraphQL is that it has a built-in [type system](https://graphql.org/learn/schema/). So we're one step closer to creating an end-to-end type-safe system.

![REST vs GraphQL](https://user-images.githubusercontent.com/27310414/98841282-8e668880-2450-11eb-8e3f-01df06dbb4b8.png)
_GraphQL vs. REST_

### Leveraging GraphQL Tooling To Build An End-to-end Type-safe System

To achieve end-to-end type-safety status, types must be consistent and in **sync** across the whole stack.
The goal is to maintain a **single source of truth** for our types. Doing this is a lot of manual work, which leaves room for error. So the best solution is to _automate_ this task.

There are multiple stacks that can achieve end-to-end type-safety, I'll be showing you one way to do it.

1. We use an ORM to get the types of our database ([Prisma](https://prisma.io))
2. Use a code-first approach to define our schema and resolvers using [Nexus](https://https://nexusjs.org/). A Schema-first approach can also work, however, it leaves room for error. Here's a [comparison between code-first and schema-first development](https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3)
3. Generate types from the schema to use on the front-end using [GraphQL code generator](https://graphql-code-generator.com/)

This is a **unidirectional flow** that starts from the backend and our types propagate to the frontend. It also maintains a single source of truth (the GraphQL schema) and allows us to have a clear 3 step process in case we want to do any migrations/updates.

1. Update the database schema and types.
2. Update the types and fields in the schema generation step.
3. Update the fields on the front-end.

![Full Stack TypeScript + GraphQL API](https://user-images.githubusercontent.com/27310414/98915084-1b9df180-24d2-11eb-9199-027a9312cbe5.png)

If you're interested in a practical code example, [Prisma](https://prisma.io) has an end-to-end type-safe [example](https://github.com/prisma/prisma-examples/tree/latest/typescript/graphql-nextjs) which uses the following stack:

- Next.js ( Full Stack Framework) + TypeScript.
- Apollo GraphQL (GraphQL Client + GraphQL server).
- Prisma (database toolkit to interact with the Database).
- SQLite (can easily be replaced with PostgreSQL).
- Nexus (code-first GraphQL Schema + generates types).

They also have a [guide](https://dev.to/prisma/complete-introduction-to-fullstack-type-safe-graphql-feat-next-js-nexus-prisma-c5) which shows how to build this Fullstack, Type-Safe GraphQL example.


Introduction to End-to-end Type Safety and the benefits it offers

Blog

Composition Over Inheritance

How I Failed The 100 Days Of Code Challenge

Introduction to End-to-end Type Safety

Follow along