feat: GraphQL subscriptions

[nedsalk]

This PR introduces GraphQL subscriptions without a dependency on any external library by using the Streams API and async generators. The native EventSource unfortunately couldn't cut it because it's limited only to GET requests. Alternatives to EventSource like eventsource, SSE.js, fetch-event-source have their own problems (only GET, slow/non-existant maintenance, missing typescript declarations, lack of nodejs support...), so I opted to just use the native APIs. The core logic is in fuel-graphql-subscriber.ts and fits in less than 100 lines of code.

Also, for documentation purposes, we already tried graphql-sse and reverted it.

closes #301 #782 #1293.

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟢	Statements	87.36% (+0.35% 🔼)	6128/7015
🟡	Branches	71.42% (+0% 🔼)	957/1340
🟡	Functions	79.15% (+1.4% 🔼)	1010/1276
🟢	Lines	87.19% (+0.18% 🔼)	5880/6744

Show new covered files 🐣

St.❔	File	Statements	Branches	Functions	Lines
🟢	... / fuel-graphql-subscriber.ts	82.61%	60%	100%	82.61%

Test suite run success

1483 tests passing in 259 suites.

Report generated by 🧪jest coverage report action from 2f6f236

[Torres-ssf]

LGTM 🚀

@nedsalk Why not adapt TransactionResponse class to make it possible to use the subscription submitAndAwait instead of just submit mutation when submitting a Transaction?

fuels-ts/packages/providers/src/provider.ts

Lines 540 to 544 in 1690004

	const {
	submit: { id: transactionId },
	} = await this.operations.submit({ encodedTransaction });
	const response = new TransactionResponse(transactionId, this);

[nedsalk]

@Torres-ssf

Why not adapt TransactionResponse class to make it possible to use the subscription submitAndAwait instead of just submit mutation when submitting a Transaction?

The TransactionResponse class isn't concerned with submitting a transaction; it's concern is to get a submitted transaction, so I'm not sure why and how we'd adapt it for those mutations.

If you were thinking about modifying the Provider.sendTransaction method to use submitAndAwait as the default, that wouldn't be appropriate because a transaction can take an indefinite amount of time to execute on the node and using submitAndAwait as the default would block our users from executing anything on their side until the node executes the transaction.
We'd have to create a new workflow for those who want to both submit and await the execution of a transaction in one go.

[arboleya]

We can have it as a secondary option, like sendTransactionAndAwait() or similar.

[arboleya]

Left a minor observation, and there's the sendTransactionAndAwait thing.

[nedsalk]

@arboleya

... and there's the sendTransactionAndAwait thing.

This PR is just to introduce the subscription mechanism and verify that it works on TransactionResponse by replacing the previous polling mechanism with the new server-sent events one. Introducing submitAndAwait properly for the user to benefit from it would require some additional refactoring, thinking about the API on the level above the Provider (e.g. how to best provide it on FunctionInvocationScope, Account methods like transfer, etc.), which IMO deserves to be its own PR.

[arboleya]

@nedsalk I thought it'd be easy; maybe I got something wrong.

Could you please elaborate on the rationale in a new issue and link it here?

[nedsalk]

@arboleya

Could you please elaborate on the rationale in a new issue and link it here?

Here's the issue: #1563.

[arboleya]

Thank you.

[Torres-ssf]

@Torres-ssf

Why not adapt TransactionResponse class to make it possible to use the subscription submitAndAwait instead of just submit mutation when submitting a Transaction?

The TransactionResponse class isn't concerned with submitting a transaction; it's concern is to get a submitted transaction, so I'm not sure why and how we'd adapt it for those mutations.

If you were thinking about modifying the Provider.sendTransaction method to use submitAndAwait as the default, that wouldn't be appropriate because a transaction can take an indefinite amount of time to execute on the node and using submitAndAwait as the default would block our users from executing anything on their side until the node executes the transaction. We'd have to create a new workflow for those who want to both submit and await the execution of a transaction in one go.

Sorry @nedsalk I don't follow, can you help me by giving more context here?

My initial thought was to modify the Provider.sendTransaction to use submitAndAwait as I was under the impression that the process was not going to stop and wait till the transaction was processed as submitAndAwait is also a subscription, just like the one being used in this PR statusChange.

Maybe I am missing something here.

UPDATE:

And maybe make the TransactionResponse accept the subscription object on the constructor or another method. Then, there we would call for await.... But yeah, I am aware that this would involve some thinking and maybe it is not the best approach.

I've asked this to bring the submitAndAwait to the conversation.