Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simple GET fails with HTTPClientError.cancelled #477

Closed
mvolkmann opened this issue Nov 14, 2021 · 5 comments
Closed

simple GET fails with HTTPClientError.cancelled #477

mvolkmann opened this issue Nov 14, 2021 · 5 comments

Comments

@mvolkmann
Copy link

I'm trying this package with a simple GET request to a local URL, but I get failure(HTTPClientError.cancelled).
Pasting the same URL in a web browser works.
I am sending the request from an init method in a ViewModel class. Should this work?

You can see my very basic code here:
https://github.com/mvolkmann/SwiftUI-AsyncHTTPClient/blob/main/SwiftUI-AsyncHTTPClient/ViewModel.swift

An instance of ViewModel is created in ContentView.swift which is here:
https://github.com/mvolkmann/SwiftUI-AsyncHTTPClient/blob/main/SwiftUI-AsyncHTTPClient/ContentView.swift

@dnadoba
Copy link
Collaborator

dnadoba commented Nov 14, 2021

Hey Mark,
the problem is that the HTTPClient is shutdown synchronously after your method returns through the call to .shutdown() at line 16 in ViewModel.swift but the request is executed asynchronously. This results in the behaviour you observed, namely that all requests are cancelled right after init() returns.

To fix this, you need to wait before you call .shutdown() at least until the request has finished.
In addition, creating a HTTPClient is a rather expensive operation and you usually want only one HTTPClient for your whole App. To solve both problems at the same time, you should give your ViewModel an already created instance of HTTPClient. ViewModel should then not call .shutdown() and some other part of your app should eventually shut it down.

If you just want to quickly experiment with the HTTPClient you could also call .shutdown() from within the completion closure e.g. at the end of the switch state after line 33 in ViewModel.swift.

Furthermore, if you only want to do HTTP requests on Apple platforms (iOS, macOS etc.) you actually do not need to use AsyncHTTPClient and can just use URLSession from Foundation which already ships with the OS.

@mvolkmann
Copy link
Author

Thanks so much for clarifying that! I have fixed my code in the GitHub repo referenced above in case others want to see a working version.

You mentioned that I can use URLSession to send the HTTP request. The reason I reached for AsyncHTTPClient is that I was looking for a simpler API for making REST calls. It does seem simpler, but I was hoping for something along the lines of JavaScript's Fetch API. I know this is a matter of opinion, but do you think most Swift developers use URLSession directly for REST calls and don't mind how much code is required to use it?

@mvolkmann
Copy link
Author

I just learned how to use async/await with URLSession and I like the code MUCH better now!
For anybody that is interested, check out https://github.com/mvolkmann/SwiftUI-AsyncHTTPClient/blob/main/SwiftUI-AsyncHTTPClient/ViewModel.swift.

@mvolkmann
Copy link
Author

@dnadoba
Copy link
Collaborator

dnadoba commented Nov 15, 2021

I highly recommend you URLSession in your use case. AsyncHTTPClient is tailored towards use cases which are more relevant on the server like cross platform support, logging/tracing, scaling on high core count hardware and efficient proxying through first class integration with SwiftNIO. Whereas URLSession has more features you would use on the client like first class support in Instruments to inspect requests (much like you can do in the browser with e.g. Chrome DevTools) and good OS level integration for e.g. requests which are executed in the background without the need that your app is even running.

async/await is not yet supported by AsyncHTTPClient but we have a proposal to add support for it and we are already working on an implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants