
I'm excited to share why I joined WorkOS as a Developer Advocate. I wanted to share my thought process and why I decided to start this new adventure.

I was at Prisma for a little over a year. I had a wonderful time working with brilliant people on a remarkable open-source project.

I'm super proud of all the things I've accomplished: I filmed 20+ videos, written multiple blog posts, did livestreams, helped with release communication, maintained code examples, met new people, and spoke at several meetups/conferences.

The community was growing, and everything was going well, so why the switch?

The main reasons were:

- I was seeking a new challenge in a different space
- The company's philosophy and its approach to building tools for developers was appealing
- Opportunity to work on a smaller DevRel team and wanting to grow it

## A new challenge, in a different space

I'm obsessed with developer tools. It's by far one of the most fun and rewarding spaces to be a part of.

Building for developers is a unique challenge. They're skeptical by default, understand very well that no tool is perfect, and that everything has trade-offs.

In my previous role, I was at a company focused on making database access easier and on defining workflows that increase developer productivity. It was fun. However, I realized there were so many areas in developer tools to be explored:

- Platforms for frontend developers
- Serverless/cloud platforms
- Backend-as-a-service
- GraphQL tools
- Search
- Collaborative tools
- Databases
- Analytics
- Monitoring
- DevOps
- Testing
- Infrastructure
- And so much more

So if the right opportunity in this space presented itself, I decided that I would go for it. That's when I came across WorkOS.

### What is WorkOS

Before sharing what WorkOS is, here's a little bit of context on the problem that it solves.

Over the past few years, a lot of SaaS providers became successful by adopting the following framework:

1. Build a tool focused on solving a problem very well for a single user.
2. Allow multiple users to collaborate. For example, role-based access control (RBAC) or live editing.
3. Start selling to enterprises where each one can have hundreds or even thousands of users.
4. Profit 💰

A few great examples that come to mind are Figma, Notion, and Vercel.

There's a reason that this framework works very well. Since individual users and enterprises have their own pros and cons to being customers, having both of them helps in building a healthy and sustainable business.

Individual users are always willing to try new products when they hear about them. Whether that's through friends, coworkers, or by seeing them online, this means that word-of-mouth and marketing campaigns can be super effective in raising awareness and driving growth.

On the other hand, individual users are usually price-sensitive and churn quickly. So if a business solely relies on them, it will experience volatility in revenue, especially if it's in a competitive area where users have a lot of alternatives.

That's why SaaS providers start building for teams. They can charge per team member and likely end up with lower churn. That's because switching tools is more challenging when many people are involved. Of course, adding support for teams costs time and resources. However, the investment pays off in the long run.

Now you might think that an enterprise is just a bigger-than-usual team, and while that's true, enterprises usually require a set of extra features before considering using a SaaS:

- Single Sign-On integration: an enterprise will set up its own identity provider (IdP), which provides all employees with a single set of credentials across many apps. There are hundreds of identity providers out there, including Okta, Azure, Google, and more. Each enterprise will require a SaaS provider to integrate with their choice of IdP.
- Directory integration: an enterprise will have a central service set up to define user groups, policies, and manage access to resources. There are different Directory providers such as Workday, BambooHR, Google, and more. An enterprise might require a SaaS provider to sync user accounts with their directory. That means that whenever a new employee is added or removed from a Directory, an account should be automatically created or removed from the SaaS provider's application.
- Audit trails: enterprises with many employees want SaaS providers to give them the ability to monitor actions done across the app. For example, when a resource gets requested, created, updated, or deleted. The IT admins should see who did what and when.
- Security compliance
- Privacy compliance
- And much more

While these features may seem boring to build and have zero impact on the actual user experience, SaaS providers miss out on a ton of revenue by not having them.

So one of two things end up happening:

1. Companies decide not to go the enterprise route because they can't allocate enough engineering resources to build these features.
2. Companies divert engineering resources to building and maintaining these non-core features, often delaying new product releases due to resource constraints.

That's where WorkOS comes in.

WorkOS is an API platform that helps developers quickly ship common enterprise features.

Think of it like Stripe but for adding enterprise features. No one wants to build their payment processing system, the same way no one wants to build these enterprise requirements.

You also get a Stripe-like experience:

- Each enterprise feature has its own API, and developers can integrate these APIs within hours.
- The product has a pay-as-you-grow pricing model where you only pay for what you use. You can learn more by going through the [pricing page](https://workos.com/pricing).
- Stripe started with Developer APIs and then focused on building a great end-user experience through services like [Stripe billing portal](https://stripe.com/docs/billing/subscriptions/integrating-customer-portal) and [Stripe payment links](https://stripe.com/payments/payment-links). WorkOS also focuses on the end-user experience. In this case, it's the enterprise customer. Instead of a dozen back-and-forth emails for setting up an integration, customers can go through a self-serve setup using the [Admin Portal](https://workos.com/docs/admin-portal/guide).

At the time of writing this article, WorkOS powers 100+ apps, allowing them to unlock more revenue and save time. That's wild considering the fact that the product officially launched near the beginning of 2020.

If you're interested in learning more about how companies are using WorkOS, feel free to check out some of the case studies:

- [How Vercel leverages WorkOS to land enterprise customers like GitHub](https://workos.com/blog/vercel-case-study)
- [How Patch unblocked $1 million in enterprise GMV with WorkOS SSO](https://workos.com/blog/patch-case-study)
- [How Hopin Saved Two Months of Engineering Time with WorkOS](https://workos.com/blog/case-study-hopin)

## The company and its culture

WorkOS is still small. At the time of writing this article, we're 27 people working fully remotely.

![WorkOS all-hands meeting zoom](/images/writing/why-i-joined-workos/workos-all-hands.png)

When it comes to the DevRel team, it's just [Zeno](https://twitter.com/zenorocha) and me at the moment. And we have some big plans to raise awareness about WorkOS and empower the developer community.

That honestly excites me. I feel like I can think outside the box and that I'll be able to see my impact directly. There's something unique about building something from scratch and seeing it slowly grow in front of you.

## Final thoughts

If you're a builder and you're thinking about becoming enterprise-ready, feel free to reach out to me by [email](mailto:mahmoud@workos.com) or on [Twitter](https://twitter.com/thisismahmoud_).

We're also planning on growing our team even more during this year. So if you're looking for a new role at a fast-growing, fully-remote startup, feel free to reach out as well. I'd love to get to know you 😄


Why I Joined WorkOS


## The system I used to track my progress and why it's flawed

It always starts with a goal and a specific time period.

Maybe it's going on a diet for 90 days, writing a writing post every week, or reading 20 pages every day.

So to track my progress, I use a calendar. If I complete the desired task on a given day, I will mark that day as complete. Otherwise, I leave it blank.

Writing that big X at the end of the day feels fantastic, like receiving a hard-earned medal. On the other hand, when I miss a day, I feel like crap. But I would just shrug it off and try the next day again. I consider it part of the process.

The biggest flaw when thinking about progress this way is that it's either a hit or a miss.

Say I read 15 pages instead of 20 on a given day, does this count as a success or a fail? If I count it as a fail, then this discards all the work I put in, and if it's the other way around, I would feel like I'm cheating.

This system made me develop an "all-or-nothing" mentality when it comes to growth. Either I'm doing a perfect job, or I'm not.

When in reality, every step towards a goal counts. It doesn't have to be a perfect step. It just has to be in the right direction.

## A better system

A better system should help me track how close I am to achieving a target I set, so instead of 0% **or** 100%, I should be able to pick any value between these two numbers.

I'm thinking like GitHub's contribution graph, where the more you contribute, the darker the color:

![GitHub contribution Graph](/images/writing/why-i-changed-the-way-i-think-about-progress/system.png)

I don't know if such a to-do app/habit tracker exists or not (if it does, let me know), so I'm building one as a fun side-project.

I'm currently learning [AWS CDK](https://aws.amazon.com/cdk/), so that's what I'll use to build it along with [Next.js](https://nextjs.org/), [TypeScript](https://www.typescriptlang.org/), [TailwindCSS](https://tailwindcss.com), and [framer-motion](https://www.framer.com/motion).

## Final thoughts

If you made it this far, thank you so much for reading! If you have any questions or want to chat about anything, please DM me on Twitter.
If you want to get notified about future articles, make sure you subscribe to my newsletter below.


Reflections on why the system I used to track my progress was flawed, and how I changed the way I think about progress

Why I changed the way I think about progress


<Callout
  variant="info"
  content="In this article I share my own story of how I got into Develeoper Relations. I'm using this article to document my journey. Absorb what is useful, discard what is not."
/>

## Table of Contents

- [My background and how I got the role](#my-background-and-how-i-got-the-role)
- [Working remotely](#working-remotely)
- [Working with Prisma, the product](#working-with-prisma-the-product)
- [Working with Prisma, the company](#working-with-prisma-the-company)
- [Challenges I faced](#challenges-i-faced)
- [Accomplishments and achievements](#accomplishments-and-achievements)
- [The road ahead](#the-road-ahead)
  - [Building community](#building-community)
  - [Growing as a content creator](#growing-as-a-content-creator)
  - [Growing as a developer](#growing-as-a-developer)
- [Final thoughts](#final-thoughts)

## My background and how I got the role

I'm currently a 4th-year computer science student in a 5-year program.

I got into Frontend Development around 3 years ago, and I fell in love with it. I started building my own projects and learned a lot about the field. I then managed to land an internship at a cool startup and some freelance contracts.

One important lesson I learned is that marketing yourself and being known is just as important as your coding skills. It doesn't matter how good you are if people don't know about you. So I decided to focus on creating content and being active in the Frontend community to help advance my career in the future.

Fortunately, I had a secret weapon that I knew would serve me well on this journey: I knew how to create videos

Filmmaking and storytelling were one of my hobbies during my senior year in high school. I learned about writing, cameras, lighting, angles, and various editing tricks. At some point, I considered pursuing a career as a filmmaker, but seeing how hard it is to get noticed and to make a living, I changed my mind.

I also started a YouTube channel and failed (multiple times) because I didn't have a content strategy or a target audience in mind. However, I got good at talking to a camera.

I never knew that this skill would serve me in the future, but looking back, it's probably one of the best things I have done.

So in 2020, I spoke at my first ever remote conference, ByteConf React, where I shared the [mistakes I made when learning how to code](https://youtu.be/N9wK9AlZwdg). I didn't follow the traditional style where you have slides and made iit more of a YouTube-style video. I got positive feedback for it, which was encouraging.

Then a couple of months later, I managed to land two significant opportunities:

- I became an instructor at [Egghead](https://egghead.io/q/resources-by-mahmoud-abdelwahab)
- Joining Auth0's [ambassador program](https://auth0.com/ambassador-program)

I first joined Egghead as a learner advocate, where I was responsible for taking notes for courses and giving feedback on workshops. I was basically getting paid to watch courses and learn. It was awesome.

Then after a while, they reached out to me about becoming an instructor. I _of course_ immediately accepted. They then sent me high-quality audio recording equipment, I recorded a couple of lessons and I'm planning on recording more.

![Joining Egghead announcement](/images/writing/6-months-as-a-developer-advocate/join-egghead.png)

On the other hand, I learned that Auth0 has an ambassador program. This is a program where you collaborate with Auth0's DevRel team on creating content related to security, authentication, and authorization. In exchange, you get early access to features, and you get some cool swag. I met some fantastic people through this program and gave a talk on [how to add Auth0 to a React app](https://egghead.io/talks/egghead-authenticating-react-apps-using-auth0) at Egghead.

Creating content never felt like work to me. I enjoyed the process. That's when I realized that I wanted to become a developer advocate after I graduate and create content full-time.

---

One day, while I was scrolling through Twitter, I came across a tweet from a company called [Prisma](https://prisma.io). It's a backend tool that handles the database layer. They were looking for a part-time, working-student Developer Advocate.

![Job position tweet](/images/writing/6-months-as-a-developer-advocate/prisma-job-listing.png)

As a frontend developer, I've always reached for backend-as-a-service tools like [AWS Amplify](https://aws.amazon.com/amplify/) or [Firebase](https://firebase.google.com/). I didn't consider building my own backend from scratch. I simply wasn't interested in spending time on this part of the stack. I would rather instead focus on the UI layer and the user's experience.

So I wasn't a database expert, I worked with Node.js and MongoDB before, but I didn't have "real-world experience." I also had some basic SQL knowledge from college. This made me feel hesitant about applying, and imposter syndrome was at an all-time high.

However, I had a portfolio of content that demonstrated my ability to communicate and teach, which was the main requirement for the job. This gave me the confidence to apply.

A couple of days later, I interviewed with the head of People Operations (HR). It was a casual chat about my experience. I like to refer to this stage as "the vibe check," where they make sure I can communicate clearly and that I'm not a weirdo or anything.

Next, there was an interview with the Head of the DevRel team along with the Developer Sucess Lead. We chatted about my experience, and it was a bit more technical. There was no coding interview or whiteboarding.

Finally, there was a take-home assignment. I would need to write an article on end-to-end type-safety. This was a topic that I haven't explored before, so it was exciting. There were no specific requirements about who the target audience is or the length of the article. It was up to me to decide. If you're interested in reading the article, you can check it out [on the writing](https://mahmoudabdelwahab.com/writing/intro-to-end-to-end-type-safety).

Fast-forward about ~1.5 weeks, I got an offer which I accepted. It took me a while to process what happened because it felt surreal. I got my dream job as a developer advocate while still being a student. But not only that, I was getting paid to do it and this role gave me the motivation to explore a new area of Software Engineering.

If you're wondering how I managed to do all of this while being a student, I'll let you in on a little secret: I'm a shitty student. I'm talking C's and D's. So don't feel bad because you haven't figured out what you want to do in the future. I just decided what my priorities and goals are early on. Which will most likely evolve and change with time anyway.

## Working remotely

Usually, the role of a Developer Advocate involves a lot of traveling and speaking engagements, where you go to meetups and conferences. However, with the pandemic, things have changed. Everything is now online.

Working from home has been a positive experience for me, once I followed the following rules:

- Work in a quiet environment with minimal distractions
- Take frequent breaks and go on walks

Also investing in a sit/stand desk and a decent chair helped a lot when working for long periods of time. I'm also lucky that I don't share my room with one of my brothers anymore and live in a quiet area.

## Working with Prisma, the product

If you ask two Developer Advocates about what a day in their life looks like, you'll receive two different answers. The main reason is that every product and team is different.

Prisma is a very well-crafted product, where the engineers took the time to design clear workflows and friendly APIs. Also, the documentation is very mature and covers a lot of information due to having some incredible technical writers.

Prisma also has a fantastic community where developers give back by creating helpful resources like articles and videos. However, for me, the most impressive thing is seeing developers build tools that make other Prisma developers more productive. For example:

- [Prisma-Appsync](https://prisma-appsync.vercel.app/) - generates a fully working AWS AppSync ⚡ GraphQL CRUD API. 🚀 by [Sylvain](https://github.com/maoosi)
- [Pal.js](https://paljs.com/) is a set of tools to help you bootstrap your next NodeJS, Prisma, GraphQL, React project. by [Ahmed Elywa](https://github.com/AhmedElywa)

So overall, the experience has been amazing.

## Working with Prisma, the company

Working at Prisma has been an absolute delight. The people are friendly, have tons of experience, and my team is very understanding about me being a student. They also provide helpful feedback on the things I'm working on.

One thing I love is how everyone is aware of what the different teams are working on and often offer helpful suggestions. So engineers, PMs, Designers can start conversations, even if it's not directly correlated to their work.

Another interesting thing is how the team is distributed across multiple countries. This made me talk to people with different backgrounds and cultures, which was eye-opening.

I'm also incredibly fortunate that I'm part of a big Developer Relations team, which is a lot of fun and is super empowering.

Finally, the biggest and most important thing for me is that I'm allowed to express my ideas and experiment. If I didn't have that, my performance would suffer.
The reason I can create high-quality content isn't because I know how to write, talk to a camera or shoot videos. It's because I'm genuinely excited.

In conclusion: I don't have anything to complain about. Highly recommend working there. Check out [prisma.io/jobs](https://prisma.io/jobs) and see if there's a role that excites you and come work with me.

## Challenges I faced

The biggest challenge I faced is communication. It is _easy_ to be misunderstood when communicating over Slack, which is why it's vital to _overcommunicate_. I'm still working on this one, but with time, I see myself overcoming it.

Another area where I need improvement is estimates. They're painfully hard 😆.

![Meme where genie says there are three rules, no falling in love, no wishing for death and no bringing back dead people. I wish for knowinghow to estimate a task and genie says there are 4 rules](/images/writing/6-months-as-a-developer-advocate/estimates-meme.png)

## Accomplishments and achievements

In the past 6 months, I:

- Published an article on Dev.to, [to help teams working with other ORMs adopt Prisma at work](https://dev.to/prisma/a-letter-you-can-send-to-your-manager-to-adopt-prisma-at-work-4k94). 💌
- Published an article about [React Server Components](https://www.prisma.io/writing/database-access-in-react-server-components-r2xgk9aztgdf) on the Prisma writing. ⚛
- Went on a [Livestream with Colby Fayock](https://www.youtube.com/watch?v=5UZBhWAlyTo) where I built a Next.js X Prisma demo.
- Created the [What is Prisma](https://www.youtube.com/watch?v=EEDGwLB55bI) video because [Prisma is now Production-ready](https://www.prisma.io/writing/prisma-the-complete-orm-inw24qjeawmb) ✨
- Created a [video anouncement](https://www.youtube.com/watch?v=VRzuTofSooo) for Prisma's Data platform, an exciting product that helps teams collaborate when working with databases. Go check it out 👀 🎥
- Went on my first mini-podcast (It's 9-mins) with [Rosie Sherry](https://twitter.com/rosiesherry) where we talked about [how developer communities improve Developer Experience](https://racket.com/rosiesherry/rRYf7). 🎙

There was also some cool stuff like attending live streams and joining Twitter spaces.

In the upcoming few weeks, I'll publish a course where I'll teach how to build a fullstack app using Next.js, GraphQL, TypeScript and Prisma. It's an app where users browse through a list of curated links and can bookmark their favorite ones. It's going to be huge and hopefully it'll help devs who are interested in working with this stack.

## The road ahead

There are some areas I want to get better at this year:

### Building community

One area that I would like to focus on is community building. I want to be more involved in the Developer Community, get to know people who use Prisma, understand their use-cases, and help them be successful. I tried it for a bit and the feeling of someone saying, "it works now! Thanks," makes me want to do a backflip.

### Growing as a content creator

I want to grow my own YouTube Channel, with the focus on making other developers successful. I want to share important lessons I learn and help them level up in their careers. I also want to write more on this writing and share the things I learn.

### Growing as a developer

There are a lot of areas where I would like to deepen my knowledge:

- TypeScript
- Testing
- CI/CD
- AWS

I also want to work on side-projects and experiment with different tools.

## Final thoughts

If you made it this far, thank you so much for reading! If you have any questions or want to chat about anything, please DM me on Twitter.
If you want to get notified about future articles, make sure you subscribe to my newsletter below.


Reflections about my journey as a developer advocate for the last 6 months

Six Months as a Developer Advocate


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.

`test`

## 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/writing/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

Introduction to End-to-end Type Safety


## 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 writing 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


_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 "what they are. With functional programming, you structure your classes on what they do.

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

Writing

Top Picks