feat: remove graphql-request dependency

[nedsalk]

This PR replaces the graphql-request and graphql-tag dependencies with a simple fetch implementation.

This change reduces the final bundle size by 15.68 kB.

Note

• Incoming from Investigate tree-shakeability of our umbrella `fuels` package #1592

[Torres-ssf]

@FuelLabs/sdk-ts After going through this PR solution, I can validate that it is working as intended and accomplishes what it's supposed to do. The implementation is both valid and well-structured.

I do agree with the advantages of having our own solution, particularly in terms of reducing our package size, but I have a few considerations to share.

After reviewing the graphql-request library, I've noticed that there are some aspects of their implementation that are not fully addressed in our custom solution. These include:

1 - Comprehensive Error Handling: The graphql-request library provides a robust mechanism for handling various types of errors, which can be crucial in a production environment. While I understand that in this proposed solution, any thrown error will be caught elsewhere, there is a clear benefit to having specific errors properly handled and managed within the context of the library itself.

2 - Subscription Management: graphql-request effectively manages multiple subscriptions, which is important for resource management.

3 - Community Support and Maintenance: By utilizing a well-established library like graphql-request, we benefit from ongoing community support and regular updates. This significantly reduces the maintenance burden on our team and ensures that we stay aligned with industry standards and best practices.

While the custom solution works well, I believe it's important to weigh these factors.

We should consider the potential risks and missing features against the benefits of a reduced package size.

Unforeseen errors and edge cases could introduce instability and require additional development and maintenance efforts, potentially offsetting the initial benefits.

I suggest we carefully consider the long-term implications of this change. It might be more beneficial to continue using graphql-request, ensuring that we have a robust, well-supported solution for our GraphQL needs.

However, I'm open to further discussion and insights you might have on this matter.

[nedsalk]

1 - Comprehensive Error Handling: The graphql-request library provides a robust mechanism for handling various types of errors, which can be crucial in a production environment.

I went through their source code and didn't find anything comprehensive around error handling. I only found them providing the ability to configure an error policy, which is something we don't have a need for because we want to throw all errors.

While I understand that in this proposed solution, any thrown error will be caught elsewhere, there is a clear benefit to having specific errors properly handled and managed within the context of the library itself.

The only specific error they have is ClientError, meaning they just differentiate between two types of errors:

• Those that are returned by the client in the response body's errors property (handled by their ClientError),
• all other errors that are just re-thrown

They don't provide any comprehensive error handling because that's not their purpose as they're a general-purpose library. It is up to their consumers to do a try/catch on their ClientError, read the message or response field, and then differentiate between specific errors by implementing custom error handling via some string matching. This PR isn't passing the error-handling responsibility away to someone else, it's doing the exact same amount of error handling as does graphql-request.

2 - Subscription Management: graphql-request effectively manages multiple subscriptions, which is important for resource management.

graphql-request only supports subscriptions over web sockets, which isn't applicable to us as our fuel node implements subscriptions over SSE.

3 - Community Support and Maintenance: By utilizing a well-established library like graphql-request, we benefit from ongoing community support and regular updates. This significantly reduces the maintenance burden on our team and ensures that we stay aligned with industry standards and best practices.

This library has been in the SDK's dependencies since the beginning and its only usage was for creating a proper fetch request and parsing the response correctly - something that was replaced by 21 lines of code (create a request object and send and parse the response). We don't need the ceremonies of a library to do a simple fetch, however well the library is maintained. The maintenance burden of a fetch call is minimal and IMO less than keeping up with a library's changes in this simple context. Any industry standard improvements upon fetch will benefit both us and graphql-request the same.

I suggest we carefully consider the long-term implications of this change. It might be more beneficial to continue using graphql-request, ensuring that we have a robust, well-supported solution for our GraphQL needs.

IMO two-ish years of usage in the SDK that only amounted to the use case of fetching is enough to say, "We don't need this library if we can replace it with a simple fetch". Fetching has been our only need met by graphql-request. IMO fetch should have been the default here since the beginning and a library like graphql-request should've been considered only if some additional functionality was needed.

As far as the future goes, if the potential case arises where we need some additional functionality we can always take inspiration from them or even return to them if we see that it's too complex to maintain. As for the current situation, the size reduction and easier grokking of the whole 21-line fetching functionality compared to whatever other library that hides it internally IMO is enough to go through with this PR.

[github-actions]

Coverage Report:

Lines	Branches	Functions	Statements
78.29%(-0.13%)	68.52%(+0.09%)	76.47%(-0.18%)	78.26%(-0.13%)

Changed Files:

Ok	File (✨=New File)	Lines	Branches	Functions	Statements
🔴	✨ packages/providers/src/fuel-graphql-request.ts	97.77% (+97.77%)	95% (+95%)	100% (+100%)	97.82% (+97.82%)
🔴	packages/providers/src/fuel-graphql-subscriber.ts	0% (-80%)	0% (-37.5%)	0% (-100%)	0% (-80%)
🔴	packages/providers/src/provider.ts	70.27% (-0.67%)	55.46% (-0.73%)	66.66% (-1.03%)	68.79% (-0.8%)

[Dhaiwat10]

My two cents on this PR:

If everything is working as intended like @Torres-ssf mentioned, I think we should go ahead with this PR and get it merged.

I did read through the points that Sergio mentioned in his comment, too. I think the Nedim's explanation in his response is fair enough. I don't see a downgrade in terms of quality/reliability or an increase in burden maintenance-wise if we go ahead with Nedim's solution. On top of that, this PR would decrease the bundle size - which is crucial.

I agree that we cannot be 100% sure that nothing will break unexpectedly, but we can be 99% sure and that's good enough. If something pops up, we can put together a quick fix or roll things back. The benefits outweigh the costs here.

[arboleya]

All points make sense, but I'm mainly concerned with unknown unknowns and the possible introduction of unforeseen problems, especially in preparation for the subsequent releases, as I'm not sure the risk outweighs the benefits.

[danielbate]

I agree with the fact that graphql-request was potentially overkill at the time it was implemented here. As it was implemented at the inception of the SDK, it was likely it was chosen to obtain functionality with minimal overhead. Now we have the time to question these decisions and I am glad we are doing so. I believe a fetch would suffice, if we needed additional functionality that we don't want to maintain, at that point we'd bring in a library. The using a sledgehammer to crack a nut analogy comes to mind here.

My main problem here is that right now stability should be our top priority, alongside delivering main net features. Although package size is a big consideration, I would rather deliver a stable package that we have complete confidence in than one that is leaner in size, but has unknowns. At this point in time, if something even has 1% unknowns it is worth not merging at the moment. Especially, as we already have a working solution. I'd be in favour of closing the PR.

[nedsalk]

Closing this PR because most of the team is not in favor of it at the moment.