Skip to content

Commit

Permalink
feat(docs): add using gatsby professionally section (#12779)
Browse files Browse the repository at this point in the history
* using gatsby professionally, v1

* prettier

* add paragraphs to stub articles

* basic draft for all articles

* more stub modifications

* best practices
  • Loading branch information
calcsam committed Mar 26, 2019
1 parent edd6cb1 commit 8b4d5de
Show file tree
Hide file tree
Showing 24 changed files with 506 additions and 0 deletions.
20 changes: 20 additions & 0 deletions docs/docs/answering-it-security.md
@@ -0,0 +1,20 @@
---
title: Answering IT & Security Questions
---

At larger companies, such as the Fortune 500, there are Security teams that audit new technologies being used inside the company.

If security engineers are interested in your project, some talking points that can help answer their questions include:

- Because Gatsby compiles your site to flat files, rather than having running app servers and databases users are targeting, it reduces the attack surface of the site to outsiders.
- Gatsby adds a layer of indirection which obscures your CMS -- so even if your CMS _is_ vulnerable, bad actors have no idea where to find it. This is in contrast to systems where bad actors can easily locate the admin dashboard at, eg, `/wp-admin` and attempt to hack in.
- Gatsby lets you serve your site from a global CDN, likely whatever CDN your company is using (eg Akamai, Cloudflare, Fastly...), which effectively eliminates the risk of DDOS attacks.

It's helpful to emphasize to security personnel that these benefits were a factor in why Gatsby was selected for the project. You chose Gatsby, in part, because it is _more_ secure.

--

This is a stub. Help our community expand it.

Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
pull request gets accepted.
14 changes: 14 additions & 0 deletions docs/docs/best-practices-for-orgs.md
@@ -0,0 +1,14 @@
---
title: Best Practices for Organizations
---

When you have multiple teams building Gatsby sites, there are some best practices to ensure you're working well at scale. These docs explain those practices.

[[guidelist]]

--

This is a stub. Help our community expand it.

Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
pull request gets accepted.
34 changes: 34 additions & 0 deletions docs/docs/component-libraries.md
@@ -0,0 +1,34 @@
---
title: Creating Component Libraries
---

Component libraries are often used in component-based UI systems like React and Vue. They are typically versioned repositories of components.

IBM's [Carbon Design System](http://carbondesignsystem.com/) and Palantir's [Blueprint](https://blueprintjs.com/) are both good examples.

## Why component libraries

There are several rationales for creating component libraries.

- **Create unified design**. In large web properties and web apps, the look and feel can diverge across different sections maintained by different teams. Component libraries are often used to implement a [design system](https://www.designsystems.com/).
- **Avoid reinventing the wheel**. Component libraries include common elements like carousels or dropdowns to avoid the need for individual teams to reimplement these components.

## Tooling & team setups

Component libraries are typically maintained by one individual or a design team that acts as a curator; when a website team or feature team needs a component, it is typically available ready for them to use, so they can move faster.

Component libraries are typically stored in a separate repository. Individual apps or websites then specify in their dependencies (in `package.json`) which version of each component they are using.

One drawback of using component libraries is the additional complexity of cross-repository dependencies.

For example, if a feature developer need to change a library component, that developer's workflow typically involves two pull requests; one to the component repository repo to make the changes, and one to the website repository to bump the component version.

## Different versioning approaches

There are two different approaches for versioning component libraries.

The first is to version on globally across the component library. At any given commit, the library has one version number (eg `30.3.1`). Any commit updating a component will then bump the version number accordingly. Both Carbon Design System and Blueprint take this approach.

The second approach is to version each component in the component library. This was used, for example, [by Walmart.com](https://medium.com/walmartlabs/how-to-achieve-reusability-with-react-components-81edeb7fb0e0) -- they built their component library as React components, and created every component as a separate, versioned npm package.

This approach allows more granularity -- _what if you want an older version of one component, but a newer version of another one?_ -- but requires additional tooling to make developer workflows pleasant.
15 changes: 15 additions & 0 deletions docs/docs/convincing-others.md
@@ -0,0 +1,15 @@
---
title: Convincing Others
---

This section of the documentation has a slightly different tenor than the rest of the docs.

The purpose of the rest of the docs is to help you understand Gatsby. The purpose of this section to help you explain Gatsby to others.

Explaining Gatsby well to others, and helping convince them to use it (or to let you use it) is a different kind of problem than becoming a talented Gatsby developer.

It requires understanding what things those around you value, and helping them understand how Gatsby meets _their_ needs, rather than simply how Gatsby meets yours.

Gatsby is a transformative technology, and teams using Gatsby have the change to radically improve the way they design, develop, and deploy websites. As you help others around you understand how Gatsby meets their needs, you facilitate their growth.

https://twitter.com/ryanflorence/status/1104060348363988992
20 changes: 20 additions & 0 deletions docs/docs/different-organization-types.md
@@ -0,0 +1,20 @@
---
title: Different Organization Types
---

Using Gatsby more is a different kind of problem depending on the type of organization you work in.

As a freelancer, the most important thing is [helping clients understand](/docs/winning-over-clients) the benefits of Gatsby.

As an agency, you'll want to show others [how Gatsby helps your agency](/docs/gatsby-for-agencies) ship higher quality sites faster and under budget -- and see how Gatsby can contribute to the agency's growth strategy.

If you're at a company, there are [different strategies for adopting Gatsby](/docs/gatsby-for-companies) depending on the type and size of company.

[[guidelist]]

--

This is a stub. Help our community expand it.

Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
pull request gets accepted.
9 changes: 9 additions & 0 deletions docs/docs/faster-recruiting.md
@@ -0,0 +1,9 @@
---
title: Faster Recruiting
---

With the rise of React, it's become easier to find talented developers who are skilled in React, than developers who are skilled in various flavors of CMS UI development frameworks.

Jesus Olivas, the Head of Engineering at WeKnow, a 40-person agency based in San Diego, CA, [explains](https://www.youtube.com/watch?v=tWu1xfF18FI&feature=youtu.be&t=2392):

> On the agency side of things, it's easier to get a developer that knows React, than finding another developer that knows Drupal theming [and] Twig...
26 changes: 26 additions & 0 deletions docs/docs/first-professional-project.md
@@ -0,0 +1,26 @@
---
title: "Using Gatsby Professionally"
---

The most important professional Gatsby project you or your organization will ever ship is your first project.

Why is that?

## Shipping Gatsby websites changes the conversation

- **Shipped means more real.** It's common to talk about exciting new technologies, but much less common to actually see them used in production. Shipping a Gatsby website will make others see Gatsby as an actual choice to consider.
- **Seeing is believing.** Gatsby sites shock people by how fast they are. When someone ships a Gatsby site, other people start asking how they can get sites that fast.

https://twitter.com/Netlify/status/1011344285529182211

- **Discover allies.** Once you ship a Gatsby website, other Gatsby enthusiasts may come out of the woodwork. It's common to want change, but believe it's impossible. When the first Gatsby site ships, others may join you in trying to push for increased Gatsby usage.

- **Creating a case study.** Once business metrics, such as decreased page load times, increased conversion rates, or decreased bounce rates, are available from the new project launch, you can use these metrics as evidence that Gatsby is worth considering.

## How to ship your first website

Gatsby adoption within organizations tends to follow a "bottoms-up" rather than "top-down" approach.

What that means is that the first usage is typically not driven by executive mandate for a high-profile project. Instead, typically, initial websites are often smaller or have fewer stakeholders.

This could be one-off campaigns, landing pages, brochure sites, as well as documentation pages or other internal resources.
7 changes: 7 additions & 0 deletions docs/docs/gatsby-for-agencies.md
@@ -0,0 +1,7 @@
---
title: Using Gatsby Inside Agencies
---

There are several aspects of Gatsby that create interesting potential playbooks for agencies using Gatsby, as well as unique benefits to agencies using Gatsby.

[[guidelist]]
35 changes: 35 additions & 0 deletions docs/docs/gatsby-for-companies.md
@@ -0,0 +1,35 @@
---
title: Spreading Gatsby in Companies
---

Broadly speaking, in terms of overall Gatsby usage, there are two types of organizations which have high receptivity to using Gatsby across the organization.

First, **software companies** -- more broadly, organizations who primarily build, and generally sell, software.

Second, **Internet-adjacent organizations** -- non-software organizations whose activities have been significantly affected by the Internet. This includes businesses in areas like travel, retail, consumer finance, media, and so on.

## Software companies

Software companies -- whether small startups or large, Fortune 500 companies -- tend to have lots of software developers.

Moreover, in software companies, technology decisions are often made bottoms-up by developers rather than top-down by executives.

In these environments, if one developer is excited about Gatsby, they can build company projects in Gatsby. If several developers become excited by Gatsby, they may get a team or a group of teams using Gatsby.

If you work in this organization, and want your organization to use Gatsby more, you can go a long way simply by [getting other developers excited by Gatsby](/docs/winning-over-developers).

After that, you'll find winning over [engineering leaders](/docs/winning-over-engineering-leaders), [marketers](/docs/winning-over-marketers) and [executives](/docs/winning-over-executives). is significantly easier.

## Internet-adjacent organizations

Internet-adjacent organizations whose activities have been significantly affected by the web, including areas like travel, retail, consumer finance, media, and so on.

[Digital presence is increasingly important](https://www.gatsbyjs.org/blog/2018-10-10-unbundling-of-the-cms) for these businesses, but they often don't often see themselves as software companies.

Because developers are often not the decision-makers around technologies in these businesses, bottoms-up adoption can be challenging.

If you're in an organization like this, it's important to:

- strongly emphasize Gatsby's benefits in language familiar to [marketers](/docs/winning-over-marketers) and [executives](/docs/winning-over-executives).

- position Gatsby as part of "digital transformation" initiatives your company undertakes. Faced with new competitors taking market share (eg Amazon in retail, Expedia and Airbnb in travel, PayPal in consumer finance), these businesses typically emphasize a priority as a company to be more Internet-native. This can provide an opening to pitch Gatsby as a way to do this.
12 changes: 12 additions & 0 deletions docs/docs/gatsby-for-freelancers.md
@@ -0,0 +1,12 @@
---
title: Gatsby for Freelancers
---

As a freelancer, the most important thing is [helping clients understand](/docs/winning-over-clients) the benefits of Gatsby.

--

This is a stub. Help our community expand it.

Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
pull request gets accepted.
24 changes: 24 additions & 0 deletions docs/docs/going-gatsby-only.md
@@ -0,0 +1,24 @@
---
title: Going Gatsby-Only
---

Some agencies and freelancers have decided that in order to unify their business, they will _only_ build sites on Gatsby and turn down clients or projects where it's not possible to use Gatsby.

Some of the benefits such agencies list include:

- reduced knowledge silos
- a unified technology stack
- consistent fast development
- no time ever spent on performance optimization
- ability to build projects across CMS-es
- a more cohesive team.

One example of this is [Narative.co](https://www.narative.co/), based in Montreal. Narative [wrote a blog post](https://www.gatsbyjs.org/blog/2018-06-18-why-narative-loves-gatsby/) laying out some of these benefits:

> Gatsby allows our team to use the powerful React API when creating page based websites with almost no drawbacks. All the principles and techniques we’ve learned from using React for the last few years can be leveraged with Gatsby. This has enabled us to create a team that is extremely dynamic and cohesive without the worry of creating silos or losing knowledge across teams. Our team is able to learn once, write everywhere. With an engineering team that’s familiar with React and Gatsby we’re able to tackle more problems faster, which is highly beneficial to our partners and the services we offer.
> Gatsby does not only allow us to deliver fast websites, it has also sped up our development time. The developer experience is another focus of the team behind Gatsby - and it shows. Features such as live reload are ready to go at when you start a new project. There’s no need to setup a custom Webpack configuration as the basics are completed for you. Building your website and deploying is also carefully thought out by Gatsby and often requires running a single command and using one of the many integrations for hosting. Furthermore, the documentation is comprehensive and has plenty of content from introductory guides to complex use cases. This has been amazing for training and on boarding new members of our team, especially if they’re already familiar with React.
> Many popular CMS tools are tightly coupled to their source of data. Gatsby offers a clear separation between the data and view layer building on top of the Headless CMS principles. The advantage for Narative is that we can develop without CMS lock-in such as WordPress. If our team decides to go with a new view layer the migration would be less painful than migrating all the data as well. Often times flexibility in software means more complexity to manage but in this case the flexibility is in the right spots where it reduces complexity.
> We pass this flexibility on to our partners. They are able to manage their data while our team is able to deliver an excellent product on top of their existing infrastructure. This has made our solutions to revamping legacy projects even stronger than before.
18 changes: 18 additions & 0 deletions docs/docs/how-gatsby-boosts-career.md
@@ -0,0 +1,18 @@
---
title: How Gatsby Can Boost Your Career
---

If you're a developer, and you've come to this section looking for tips about spreading Gatsby in your organization, your main motive is probably the ability to work more with a tool you love.

One, unintended, side effect: this is also good for your career.

As you ship Gatsby sites and get [other developers](/docs/winning-over-developers), [engineering leaders](/docs/winning-over-engineering-leaders), [marketers](/docs/winning-over-marketers) and [executives](/docs/winning-over-executives), and [clients](/docs/winning-over-executives) excited about Gatsby, you'll notice that you gain visibility, a reputation for driving results and business value.

https://twitter.com/ryanflorence/status/1104060348363988992

--

This is a stub. Help our community expand it.

Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
pull request gets accepted.
15 changes: 15 additions & 0 deletions docs/docs/lower-bids-more-profit.md
@@ -0,0 +1,15 @@
---
title: Lower Bids, More Profit
---

Many agencies use a different pricing model for bidding Gatsby websites that enables them to make more money and expand their business.

After identifying projects that are a good fit for Gatsby, they will bid _significantly under_ a typical bid for a project of that time. Because Gatsby enables the team to work faster, they've still able to make standard profits on the project while growing their business and creating happy clients.

Ben Robertson, of the 80-person Mediacurrent agency, [explains this strategy](https://www.youtube.com/watch?v=QiocnDGnKfs&feature=youtu.be&t=1145) in the context of Mediacurrent's work on the citysprings.com website for the city of Sandy Springs, GA:

> "This was an experimental project for us. We had done decoupled Drupal before, but this was our first project as a team that was using Gatsby and it was a budget that was actually significantly under what we would charge for a full Drupal 8 build. And that was scary!
Not only was the team able to deliver the project on time and under budget, but the client was so happy they were able to [get additional work immediately](https://www.youtube.com/watch?v=QiocnDGnKfs&feature=youtu.be&t=1531):

> Because they saved a significant portion of the money that they had already set aside, they [told us], "Hey, you guys just saved us a bunch of money, and also we would like some new features, so can we please pay you some money to build those features for us?"
14 changes: 14 additions & 0 deletions docs/docs/making-components-discoverable.md
@@ -0,0 +1,14 @@
---
title: Making Components Discoverable
---

In larger organizations using Gatsby, it becomes important for different teams to be able to browse components used by other teams, in order to avoid reinventing the wheel.

Tools like [Storybook](https://www.gatsbyjs.org/docs/visual-testing-with-storybook/) can help with this.

--

This is a stub. Help our community expand it.

Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
pull request gets accepted.
15 changes: 15 additions & 0 deletions docs/docs/sanitize-your-stack.md
@@ -0,0 +1,15 @@
---
title: Sanitize Your Stack
---

Websites come in a thousand different flavors. Timeframes, budgets, interactivity requirements and content systems can vary wildly from one project to the next.

This variety puts agency website teams between a rock and a hard place. They often have to maintain frontends built in multiple development systems, stretching their developers’ skill sets. Implementing the same dropdown in five different frameworks can be a huge headache. But what’s the alternative — turn down good client projects?

To add to the difficulty, when your UI development framework is coupled to your client’s CMS backend, it doesn’t just cause technical problems; it causes people problems. It makes your team’s staffing plans dependent on specific projects. It hamstrings your ability to respond to changing client requirements by shifting resources around.

Gatsby solves this -- because Gatsby pulls your data from wherever it lives and exposes it in a uniform GraphQL interface, agency teams can build all their UIs in React — no matter where their content is coming from.

Gatsby lets agencies stop reinventing the wheel and makes agency developers more productive. Teams can use the best tool for the job, without creating a hodgepodge of technologies to maintain.

Sanitize your stack, with Gatsby.
20 changes: 20 additions & 0 deletions docs/docs/sharing-components-across-websites.md
@@ -0,0 +1,20 @@
---
title: Sharing Components Across Websites
---

One of the benefits of multiple teams using Gatsby within your organization is the ability to share React components across different websites.

There are several strategies here.

**Component libraries** are a cleaner and purer approach, but often requiring additional tooling or causing some changes to require pull requests to multiple.

Alternately, teams can implement **systems for component discoverability**, such as Storybook or Styleguidist, on a per-site basis and simply copy-paste desired code across repositories.

[[guidelist]]

---

This is a stub. Help our community expand it.

Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
pull request gets accepted.

0 comments on commit 8b4d5de

Please sign in to comment.