- Notifications
You must be signed in to change notification settings - Fork0
Fanout package template for Go based Fastly Compute projects.
License
fastly/compute-starter-kit-go-fanout
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
Install this starter kit to useFanout, the real-time message broker operating at Fastly's edge. This starter kit routes incoming requests through the Fanout GRIP proxy and on to an origin. It also provides some endpoints for testing real-time messages without needing an origin.
For more details about this and other starter kits for Compute, see theFastly Documentation Hub.
For the basic case, this starter kit may be used as-is to forward all traffic through Fanout to an origin.
If you would like to implement Fanout logic at the edge, this starter kit is also a good starting point for that, and you can modify it to fit your needs. See the test endpoints for inspiration.
For test requests (Paths under/test/), the app is actually invoked twice.
Initially, a client request arrives at the app without having been routed through the Fanout proxy yet. The app checks for this via the presence of a
Grip-Sigheader. If that header is not present, the app callscreateFanoutHandoff(request, 'self')and exits. This tells the subsystem that the connection should be routed through Fanout, and is used for HTTP requests controlled by GRIP.Since
selfrefers to the same app, a second request is made to the same app, this time coming through Fanout. The app checks for this, and then handles the request accordingly (inhandleTest()).
Non-test requests are simply forwarded through the Fanout proxy and on to the origin.
Important
The starter kit forwards all non-test traffic through Fanout to the origin. In a production environment, be selective about the requests you send through Fanout. SeeWhat to hand off to Fanout for a discussion on this topic.
The app expects a configured backend named"origin". It forwards all non-test requests through Fanout to this backend.
Additionally, for the test endpoints to work, the app expects a configured backend named"self" that points back to app itself. For example, if the service has a domainfoo.edgecompute.app, then you'll need to create a backend on the service named"self" with the destination host set tofoo.edgecompute.app and port 443. Also set "Override Host" to the same host value.
You'll also need toenable Fanout on your Fastly service to run this application. To enable Fanout on your service, type:
fastly products --enable=fanout
To test Fanout features in the local testing environment, first obtainPushpin, the open-source GRIP proxy server that Fastly Fanout is based upon, and make sure it is available on the system path.
Create a Fastly Compute project based on this starter kit.
mkdir my-fanout-projectcd my-fanout-projectfastly compute init --from=https://github.com/fastly/compute-starter-kit-go-fanoutThefastly.toml file included in this starter kit includes alocal_server.pushpin section:
[local_server.pushpin]enable =true
Run the starter kit:
fastly compute serveThe Fastly CLI starts Pushpin and then starts the starter kit app athttp://localhost:7676/.
The app handles requests to the following endpoints at the edge:
/test/stream: HTTP streaming oftext/plain/test/sse: SSE (streaming oftext/event-stream)/test/long-poll: Long-polling/test/websocket: bidirectional WebSocket- In the example, the WebSocket endpoint is set up to echo back any messages it receives from the client.
Connecting to any of these endpoints subscribes the connection to channel"test".
On the local testing environment, data can be sent to the connections via the GRIP publish endpoint athttp://localhost:5561/publish/. For example, here's a curl command to send a WebSocket message:
curl \ -d'{"items":[{"channel":"test","formats":{"ws-message":{"content":"hello"}}}]}' \ http://localhost:5561/publish/Once deployed to your Fastly service, the GRIP publish endpoint is athttps://api.fastly.com/service/{service-id}/publish/. Here's the same example on Fastly service:
curl \ -H"Authorization: Bearer {fastly-api-token}" \ -d'{"items":[{"channel":"test","formats":{"ws-message":{"content":"hello"}}}]}' \ https://api.fastly.com/service/{service-id}/publish/
Non-test requests are simply forwarded through the Fanout proxy and on to the origin.
For test requests, the app is actually invoked twice.
Initially, a client request arrives at the app without having been routed through the Fanout proxy yet. The app checks for this via the presence of a
Grip-Sigheader. If that header is not present, the app callsreq.handoff_fanout("self")and exits. This tells the subsystem that the connection should be routed through Fanout, and is used for HTTP requests controlled by GRIP.Since
selfrefers to the same app, a second request is made to the same app, this time coming through Fanout. The app checks for this, and then handles the request accordingly (inhandle_test()).
This app is not currently supported in Fastly'slocal development server, as the development server does not support Fanout features. To experiment with Fanout, you will need to publish this project to your Fastly Compute service. using thefastly compute publish command.
Please seeSECURITY.md for guidance on reporting security-related issues.
About
Fanout package template for Go based Fastly Compute projects.
Topics
Resources
License
Code of conduct
Security policy
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Uh oh!
There was an error while loading.Please reload this page.
Contributors3
Uh oh!
There was an error while loading.Please reload this page.