-
Notifications
You must be signed in to change notification settings - Fork 52
Tightened homepage intro #797
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -1,7 +1,7 @@ | ||||||
--- | ||||||
title: Documentation | ||||||
toc: true | ||||||
subtitle: ' ' | ||||||
toc: false | ||||||
subtitle: 'Use Apollo to unify your data with GraphQL' | ||||||
description: Learn how Apollo GraphQL can help enterprise architects, API implementers, and client developers build, deploy, and manage a supergraph of unified microservices, data sources, and applications. | ||||||
--- | ||||||
|
||||||
|
@@ -30,15 +30,10 @@ import { | |||||
GradientCard | ||||||
} from '../../components/HomePage'; | ||||||
|
||||||
Apollo provides the developer platform and tools to unify your data and services into a _supergraph_—a single distributed GraphQL API. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like how you condensed most of this into the GraphOS Gradient card. At the same time, one opening line might make things more cohesive? Something like: Apollo makes GraphQL work for you at any stage and any scale, whether you're just getting started or migrating your platform onto the supergraph. |
||||||
Apollo makes GraphQL work for you at any stage and any scale, whether you're just getting started, building your first API, querying an API, or migrating your platform onto the supergraph. | ||||||
|
||||||
## For architects | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we're keeping the TOC, I'd keep this. |
||||||
|
||||||
<GradientCard | ||||||
icon={<GraphOSIcon />} | ||||||
title="Build a supergraph" | ||||||
description="Use Apollo GraphOS to define, build, connect, and observe all of your data services together in a supergraph." | ||||||
description="Use Apollo GraphOS to build a supergraph—all your data services combined into a single distributed GraphQL API." | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe we can start introducing Federation terminology here, just to warm users up to it.
Suggested change
|
||||||
path="/graphos" | ||||||
cta="Learn about GraphOS" | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be nice to have a stronger CTA, e.g. "Build your supergraph", but until we have a stronger quickstart to link to, it seems like that would be setting false expectations about the page we're currently linking too. |
||||||
/> | ||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if the subtitle is the best place for this unless we can come up with something really short and snappy. (Which feels more like the realm of a marketing website.)
Most documentation landing pages don't appear to have something like this, but if they do (e.g. Stripe) it's more about the documentation, not about the product, e.g. "Explore our guides and examples to integrate Stripe."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The subtitle as-is does need editing. Still, I prefer we condense the gist of our intro paragraph into a subtitle. It'd be more eye-catching and more efficient use of space on the page.
And it being about the documentation feels like a lost opportunity to position docs to our target personas. We could lean into federation with Apollo:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me! Maybe we include "services"? (Either replace or add to data):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data sources
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "sources" minimizes things, since we're actually federating whole services. Just "data" works too!