Skip to content

Commit fd43374

Browse files
smyricksmyrick
committed
Initial setup
1 parent 126e29f commit fd43374

11 files changed

+3532
-12
lines changed

‎.editorconfig

+15
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
# EditorConfig is awesome: https://EditorConfig.org
2+
3+
# top-most EditorConfig file
4+
root = true
5+
6+
# Unix-style newlines with a newline ending every file
7+
[*]
8+
end_of_line = lf
9+
insert_final_newline = true
10+
charset = utf-8
11+
indent_style = space
12+
indent_size = 4
13+
14+
[{*.js,*.ts,*.json}]
15+
indent_size = 2

‎.gitignore

+5-1
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,9 @@
11
# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
22

3+
# IDE
4+
.idea
5+
.vscode
6+
37
# Dependencies
48
/node_modules
59
/.pnp
@@ -34,4 +38,4 @@ yarn-error.log*
3438
.turbo
3539

3640
# typescript
37-
*.tsbuildinfo
41+
*.tsbuildinfo

‎.nvmrc

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
lts/*

‎CODE-OF-CONDUCT.md

+3
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
# Apollo Project Code of Conduct
2+
3+
The Apollo Code of Conduct lives at https://www.apollographql.com/docs/community/code-of-conduct/

‎CODEOWNERS

+8
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
# This file is used to automate PR assignments
2+
# You can also assign per-directory owners if multiple owners are applicable
3+
# For more information on CODEOWNERS, see: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
4+
5+
# Example for assigning to the Solutions Factory
6+
# * @apollosolutions/solutions-factory
7+
8+
# * @REPLACE_WITH_YOUR_TEAM_OR_USER

‎CONTRIBUTING.md

+64
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
<img src="https://raw.githubusercontent.com/apollographql/space-kit/main/src/illustrations/svgs/astronaut1.svg" width="100%" height="144">
2+
3+
# Apollo Contributor Guide
4+
5+
> If this is your first time or 100th time contributing to a project, the [Open Source Guide](https://opensource.guide/how-to-contribute/) is a fantastic place to learn about Open Source Software (OSS) and how to get involved.
6+
7+
Excited about Apollo and want to make it better? We’re excited too!
8+
9+
Apollo is a community of developers just like you, striving to create the best tools and libraries around GraphQL. We welcome anyone who wants to contribute or provide constructive feedback, no matter the age or level of experience. If you want to help but don't know where to start, let us know, and we'll find something for you.
10+
11+
Oh, and if you haven't already, join the [Apollo community](https://community.apollographql.com/).
12+
13+
Here are some ways to contribute to the project, from easiest to most difficult:
14+
15+
- [Reporting bugs](#reporting-bugs)
16+
- [Improving the documentation](#improving-the-documentation)
17+
- [Responding to issues](#responding-to-issues)
18+
- [Small bug fixes](#small-bug-fixes)
19+
- [Suggesting features](#suggesting-features)
20+
- [Big changes or new features](#big-changes-or-new-features)
21+
22+
## Issues
23+
24+
### Reporting bugs
25+
26+
If you encounter a bug, please file an issue on this GitHub repository. If an issue you have is already reported, please add additional information or add a 👍 reaction to indicate your agreement.
27+
28+
While we will try to be as helpful as we can on any issue reported, please include the following to maximize the chances of a quick fix:
29+
30+
1. **Intended outcome:** What you were trying to accomplish when the bug occurred, and as much code as possible related to the source of the problem.
31+
2. **Actual outcome:** A description of what actually happened, including a screenshot or copy-paste of any related error messages, logs, or other output that might be related. Please avoid non-specific phrases like “didn’t work” or “broke”.
32+
3. **How to reproduce the issue:** Instructions for how the issue can be reproduced by a maintainer or contributor. Be as specific as possible, and only mention what is necessary to reproduce the bug.
33+
34+
Creating a good reproduction really helps contributors investigate and resolve your issue quickly. In many cases, the act of creating a minimal reproduction illuminates that the source of the bug was somewhere outside the library in question, saving time and effort for everyone.
35+
36+
### Improving the documentation
37+
38+
Improving the documentation, examples, and other open source content can be the easiest, and one of the most important, way to contribute to the library. If you see a piece of content that can be better, open a PR with an improvement, no matter how small! If you would like to suggest a big change or major rewrite, we’d love to hear your ideas! Please open a feature request for discussion before writing the PR.
39+
40+
### Responding to issues
41+
42+
In addition to reporting issues, a great way to contribute to Apollo is to respond to other peoples' issues and try to identify the problem or help them work around it. If you’re interested in taking a more active role in this process, please go ahead and respond to issues. And don't forget to say "Hi" in the [Apollo community](https://community.apollographql.com/)!
43+
44+
### Small bug fixes
45+
46+
For a small bug fix change (less than ~20 lines of code changed), feel free to open a pull request. We’ll try to merge it as fast as possible. The only requirement is, make sure you also add a test that verifies the bug you are trying to fix, and that the coverage report covers as much of your code as possible.
47+
48+
### Suggesting features
49+
50+
Most of the features in Apollo Client came from suggestions by you, the community! We welcome any ideas about how to make Apollo better for your use case. Open up a new feature request / discussion issue with your details.
51+
52+
## Big Changes or New Features
53+
54+
For significant changes to a repository, it’s important to settle on a design before starting on the implementation. This way, we can make sure that major improvements get the care and attention they deserve. Since big changes can be risky and might not always get merged, it’s good to reduce the amount of possible wasted effort by agreeing on an implementation design/plan first.
55+
56+
1. **Open an issue.** Open an issue about your bug or feature request in this repo.
57+
2. **Reach consensus.** Some contributors and community members should reach an agreement that this feature or bug is important, and that someone should work on implementing or fixing it.
58+
3. **Agree on intended behavior.** On the issue, reach an agreement about the desired behavior. In the case of a bug fix, it should be clear what it means for the bug to be fixed, and in the case of a feature, it should be clear what it will be like for developers to use the new feature.
59+
4. **Agree on implementation plan.** Write a plan for how this feature or bug fix should be implemented. What modules need to be added or rewritten? Should this be one pull request or multiple incremental improvements? Who is going to do each part?
60+
5. **Submit PR.** In the case where multiple dependent patches need to be made to implement the change, only submit one at a time. Otherwise, the others might get stale while the first is reviewed and merged. Make sure to avoid “while we’re here” type changes - if something isn’t relevant to the improvement at hand, it should be in a separate PR; this especially includes code style changes of unrelated code.
61+
6. **Review.** At least one core contributor should sign off on the change before it’s merged. Look at the “code review” section below to learn about factors are important in the code review. If you want to expedite the code being merged, try to review your own code first!
62+
7. **Merge and release!**
63+
64+
<img src="https://raw.githubusercontent.com/apollographql/space-kit/main/src/illustrations/svgs/observatory.svg" width="100%" height="144">

‎LICENCE

+21
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
The MIT License (MIT)
2+
3+
Copyright (c) 2024 Apollo Graph, Inc. (Formerly Meteor Development Group, Inc.)
4+
5+
Permission is hereby granted, free of charge, to any person obtaining a copy
6+
of this software and associated documentation files (the "Software"), to deal
7+
in the Software without restriction, including without limitation the rights
8+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9+
copies of the Software, and to permit persons to whom the Software is
10+
furnished to do so, subject to the following conditions:
11+
12+
The above copyright notice and this permission notice shall be included in all
13+
copies or substantial portions of the Software.
14+
15+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21+
SOFTWARE.

‎README.md

+8-7
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,8 @@
1-
# Node.js Hello World
1+
# GraphOS Webhook Listener
22

3-
Simple Node.js + Vercel example that returns a "Hello World" response.
3+
Example code that listens to a GraphOS webhook notification
4+
5+
The code in this repository is experimental and has been provided for reference purposes only. Community feedback is welcome but this project may not be supported in the same way that repositories in the official Apollo GraphQL GitHub organization are. If you need help you can file an issue on this repository, contact Apollo to talk to an expert, or create a ticket directly in Apollo Studio.
46

57
## How to Use
68

@@ -21,11 +23,10 @@ git clone https://github.com/vercel/examples/tree/main/solutions/node-hello-worl
2123
Install the Vercel CLI:
2224

2325
```bash
24-
npm i -g vercel
26+
npm run vercel
2527
```
2628

27-
Then run the app at the root of the repository:
29+
## Endpoints
2830

29-
```bash
30-
vercel dev
31-
```
31+
- `/api/hello` Simple test endpoint that returns a hello world message
32+
- `/api/webhook` Example Webhook that understands [GraphOS Notifications](https://www.apollographql.com/docs/graphos/platform/insights/notifications/schema-changes)

‎api/webhook.ts

+24
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
import type { VercelRequest, VercelResponse } from '@vercel/node'
2+
3+
export default function handler(req: VercelRequest, res: VercelResponse) {
4+
try {
5+
if (req.method !== "POST") {
6+
res.status(405).json({ error: "Method Not Allowed" });
7+
return;
8+
}
9+
10+
// Process the webhook payload
11+
const payload = req.body; // Assuming the payload is in the request body
12+
13+
// Do something with the payload
14+
console.log("Webhook received:", payload);
15+
16+
// Return a response (optional)
17+
res.status(200).json({ message: "Webhook received successfully!" });
18+
} catch (error) {
19+
console.error("Webhook error:", error);
20+
res
21+
.status(500)
22+
.json({ error: "An error occurred while processing the webhook." });
23+
}
24+
}

0 commit comments

Comments
 (0)