mirror of
https://github.com/hoppscotch/hoppscotch.git
synced 2026-04-25 08:45:58 +03:00
[GH-ISSUE #267] [request] Offline cross-platform native build #91
Labels
No labels
CodeDay
a11y
browser limited
bug
bug fix
cli
core
critical
design
desktop
discussion
docker
documentation
duplicate
enterprise
feature
feature
fosshack
future
good first issue
hacktoberfest
help wanted
i18n
invalid
major
minor
need information
need testing
not applicable to hoppscotch
not reproducible
pull-request
question
refactor
resolved
sandbox
self-host
spam
stale
testmu
wip
wont fix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hoppscotch#91
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @liyasthomas on GitHub (Nov 5, 2019).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/267
Originally assigned to: @AndrewBastin, @NBTX on GitHub.
Is your feature request related to a problem? Please describe.
Apart from the postwoman.io online web client, make an offline build.
Describe the solution you'd like
We can create an installable proxy server so users can install it on their OS.
It should be lightweight and easy to install. A proxy just like that we have now but install on the user locally.
Describe alternatives you've considered
Electron, Ionic, Meteor (but don't use any of these).
Additional context
The benefits:
@hosseinnedaee commented on GitHub (Nov 5, 2019):
Wow, such a good idea!
@arangates commented on GitHub (Nov 19, 2019):
also it would be awesome if we start as vscode extension directly
https://github.com/liyasthomas/postwoman/issues/313
@orthros commented on GitHub (Nov 20, 2019):
I started with Postwoman today and have been very impressed!
I recognize this might be out of scope for this Issue, but for further thinking and context:
I'm currently running the application in a container on my host, and accessing it through the browser; it would be great if the proxy could be bundled into the application itself (possibly a different Docker image that contains both it and the application), or if the proxy could be distributed separately and then patched in with a
--netdirective todocker runand a flag to the app with the address of the proxy.@liyasthomas commented on GitHub (Nov 20, 2019):
@orthros We can certainly do that. Would you like to contribute to this Proxy setup along with @NBTX .
We've Telegram and Discord community for discussion. Links are in readme.
@orthros commented on GitHub (Nov 25, 2019):
I would be glad to contribute! I'll swing by the Discord 👍
@NBTX commented on GitHub (Nov 26, 2019):
Perhaps if this is a discussion about making the proxy, rather than the interface a native application (which I believe is ideal), we should transfer the issue to the postwoman-proxy repository?
@liyasthomas commented on GitHub (Nov 26, 2019):
This issue is intended to track offline build progress. Better take concerns regarding Proxy to https://github.com/NBTX/postwoman-proxy/
@NBTX commented on GitHub (Nov 28, 2019):
@liyasthomas Indeed but is the plan to make the application or the proxy a native standalone application?
As Postwoman is a PWA the interface itself can already run offline - I thought the discussion was about making the proxy native.
@liyasthomas commented on GitHub (Nov 28, 2019):
@NBTX even though being a PWA make it runs offline, we're missing out the possibilities of testing APIs in
localhostwhich could only be fixed by a local server setup. So, a native wrapper for the very PWA seems essential while consideringlocalhostsupport.@NBTX commented on GitHub (Nov 29, 2019):
@liyasthomas If the proxy is running locally and you enter that proxy into the Postwoman PWA, you will be able to make local requests because the requests will be executed by the proxy - which is running locally - meaning a native wrapper for the entire PWA is not actually necessary.
@liyasthomas commented on GitHub (Nov 29, 2019):
Wow, that is correct. Let's take the discuss over to the group.
@AndrewBastin commented on GitHub (Nov 30, 2019):
Is this issue thread for a native proxy or for native Postwoman (like Postwoman but as a native app) ?
@liyasthomas the title seems a bit ambiguous.
@liyasthomas commented on GitHub (Nov 30, 2019):
Proxy wrapper discuss could be done on @NBTX repo https://github.com/NBTX/postwoman-proxy/
This thread is for offline native build.
@AndrewBastin commented on GitHub (Nov 30, 2019):
Okay then,
Can I get assigned for this as I am already working on it.
@andreujuanc commented on GitHub (Nov 30, 2019):
Hey @liyasthomas few days ago I found this on my twitter feed.
https://github.com/SteveSandersonMS/WebWindow
It's like cordova, but for desktop apps. So, instead of embeding chrome+node, it uses the local web engine of the OS, which reduces the size considerably.
It's super pre-alpha stuff, BUT, it might be worth a try.
Vscode extension is also cool, but not everyone is using it, some people prefer atom,
or vim@AndrewBastin commented on GitHub (Nov 30, 2019):
@andreujuanc Thanks for the info on WebWindow, I am keeping an eye on it's development.
I already have some stuff going around regarding native wrapper which I will release once it gets more stable, we are kinda waiting for more enhanced support for IE before releasing the native builds.
Also, the strikeout on vim, dude, I am a vim user, working on Postwoman with Vim 😂
@liyasthomas commented on GitHub (Dec 5, 2019):
Important announcement:
@AndrewBastin will be leading this issue.
Please contact him for latest updates.
@AndrewBastin commented on GitHub (Dec 5, 2019):
My status as of today:
I have a native wrapper solution in the works, but in order for it to be stable on Windows, we need to iron out the issues we are facing with IE Support (see #386). Once that issue is closed, I will iron out the native code, integrate it with the postwoman mono-repo (integrate it with the npm scripts and so on) and open a draft PR so the community can help me around with testing and ironing out bugs until we hit production stable, after which we will merge with this repo.
@liyasthomas commented on GitHub (Dec 5, 2019):
Status on IE support:
Transpiled build throws out errors on vendor.js and is quite difficult to track down which part is misbehaving. Currently trying out with older versions of IE.
@andreujuanc commented on GitHub (Dec 6, 2019):
It'd be nice if in this native xplat build we can have the httpclient being build outside of the browser, so this way we can remove the "origin" header, and this way get rid of any CORS config issues :)
@liyasthomas commented on GitHub (Dec 6, 2019):
Temporarily, you can make use of Proxy mode to resolve CORS issues.
@AndrewBastin commented on GitHub (Dec 9, 2019):
@andreujuanc Yeah, the native wrapper will offer an interface to the Postwoman app to run requests natively rather than through the browser
@eladcandroid commented on GitHub (Dec 15, 2019):
Maybe Homebrew Formulae?
https://formulae.brew.sh/
@liudonghua123 commented on GitHub (Dec 20, 2019):
I think it maybe more experience friendly via wrap it with
pwaorelectronto provide smooth and quickly usage.@NBTX commented on GitHub (Dec 20, 2019):
We can't use
electron; it's too bulky - and Postwoman is already a PWA - PWAs don't let you get around CORS restrictions which is why we were considering a native build.The solution we're working on at the moment is to build a proxy server that you can install on your local machine and then use with the postwoman PWA or website.
https://github.com/liyasthomas/postwoman/pull/445
https://github.com/postwoman-io/postwoman-proxy
@axelburks commented on GitHub (Jan 4, 2020):
What about on iOS? I have found for api test tools on iOS for long time and finally found postwoman. But it have to use with proxy because CORS. Not every one have a server to run proxy.
So I wonder could postwoman support http/socks proxy? Now many vpn apps on iOS support open a socks and http proxy on localhost(usually can access them with "http://127.0.0.1:8888" or "socks://127.0.0.1:8889"), and postwoman can use it to resolve CORS on iOS.
Or you can build a native iOS app, it will be popular for many developers.
We really have found a postman-like api testing tool on iOS for so long time.
@liyasthomas commented on GitHub (Jan 4, 2020):
We do really want it! @NBTX @AndrewBastin
@AndrewBastin commented on GitHub (Jan 6, 2020):
Well, I am just back from my holidays. Still catching up on the project.
@axelburks that's an awesome idea actually, and technically it isn't really difficult and it really aligns with the framework in my head for native stuff. So I am pretty sure we could get it absolutely rolling once we figure out getting native rolled out.
@axelburks commented on GitHub (Jan 6, 2020):
We developers have to always use vpn in China, please please consider that condition🤕🙏
@AndrewBastin commented on GitHub (Jan 6, 2020):
@axelburks I am kinda working on a system for making Postwoman work using the native platform http code instead of the browser one, so stuff like CORS won't matter and since its the platform http client, it will respect the platform integrations like VPNs and stuff out of the box 😄
@AndrewBastin commented on GitHub (Mar 9, 2020):
Since this is a big feature request and there hasn't been a big talk about this. I just want to revive the discussion.
Basing on @liyasthomas 's main ideas behind creating Postwoman, we have taken certain decisions on how a native postwoman app should work.
So as Liyas described in the issue, we are completely against using Electron for the native app implementation.
But still, we are a Vue web app and we want to leverage all the features and would like to use the same codebase and not roll out a completely separate implementation.
We have a current plan to use native webviews to render Postwoman, this works flawlessly for Linux and macOS (minus tiny native webview wrapper leaks and bugs) but Windows offers IE as the native webview (atleast in older versions and on older builds of Win10), Postwoman doesn't render on IE and we dropped the plan to support IE as well because of it being too 'hacky' to implement without disturbing existing code and to implement it without introducing too much issues.
In my opinion, I don't think Postwoman is in need of a Native App soon. Since we do now support cross-origin requests through Browser Extensions. In my experience, extension + PWA really fills the gap for a native app. It is fast, lightweight enough and works flawlessly.
Although, we could discuss about mobile apps to be implemented as browser extensions aren't really popular on mobile devices. And since both iOS and Android use WebKit webviews, we are fine with all the rendering stuff, we just need to work on the native hook.
If there is a demand for mobile apps of Postwoman, please do comment on it here.
Any thoughts ?
@liyasthomas commented on GitHub (Mar 9, 2020):
I second @AndrewBastin
The very request for Native build came from the necessity for
localhostsupport,CORSissues etc. Since most of them are solved with extension, I think there's no more need for a native build.@NBTX commented on GitHub (Mar 9, 2020):
@AndrewBastin For Windows we can now consider WebView2 SDK (based on the Chromium Edge rendering engine) - At the moment it requires Chromium Edge to be installed along with the WebView2 SDK, however I believe in future the requirement will be only the Chromium Edge browser and I imagine it will be provided in Windows by default.
It's currently in a developer alpha preview, but we can start experimenting now and release an implementation when the WebView2 code hits beta.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
@liyasthomas commented on GitHub (Mar 11, 2020):
Since there's no activity towars this feature request, I think we could close this issue. After all Postwoman PWA + Browser extension could fill the gap for a native wrapper for PW.