feat: The Desktop Application

[Nishchit14]

Introduction

The Firecamp Desktop Application aims to provide users with a seamless and feature-rich desktop experience for managing API requests. By leveraging the desktop environment, Firecamp will be able to extend its capabilities beyond the web browser, offering enhanced performance and native experience.

Features

Firecamp desktop app will have the all features of the web version. alongside It'll have other desktop-specific features like SSL, proxy, CORS whitelist, and native performance.

Technology Stack

The application will be built using the following technologies:

• Electron: To create the cross-platform desktop application.
• React: For building the user interface components.
• TypeScript: To ensure the desktop packages' type safety
• Axios: For handling HTTP requests.
• WebSocket API: For establishing WebSocket connections.
• IndexedDB: For storing user preferences and other relevant data.

Phases

• The electron, typescript basic configuration and setup (minimum mvp)
• Integrate the Firecamp application within the Electron, and change the request execution agent to desktop.
• feat: Implement secure desktop authentication flow #152
• feat: File Upload in Desktop App #147
• feat: Desktop app - Build and Distribution #150
  • feat: auto update and release configuration for desktop app #148
  • Mac
  • Windows
  • Linux

ETA

the new ETA will be 31st Dec 2023

[TECHNOFAB11]

There is also Tauri but that requires knowledge of Rust. It uses the system WebView to be less bloated than electron. There might also be alternatives which are based on (Node) JS which use the system WebView.
Just an idea :)

[Nishchit14]

Yes, @TECHNOFAB11 I am trying Tauri with a sidecar. I am facing some issues with the configuration level. I am building minimum POC to check whether Tauri could satisfy all use cases of the Firecamp desktop or not.

[Nishchit14]

@TECHNOFAB11 Tauri is very promising. I am now considering it to build the first phase of the desktop app.

[chris-stytch]

Insomnia threw their user base under the bus today (Kong/insomnia#6577) so was poking around here for an alternative.

Will the desktop client be local-first (or only)? Would love a local desktop client that is simple and not interested in forcing cloud/enterprise features.

[Nishchit14]

The first version of the Firecamp desktop will be the cloud first, as we have other API services that are connected and dependent on it like API Documentation and collaboration. However, we are planning to support the offline client for REST API-only for solo devs or those who want to manage collection with local git.

[Nishchit14]

I have done extreme research on all desktop frameworks. In our case, the electron is the only feasible solution for now. The second solutions are Tauri and Wails, but they do not support the Node Runtime at the core which is required in the Firecamp case. However, I am not happy with the Electron bundle size, I hope we'll have a more flexible solution in the future.

[Nishchit14]

https://twitter.com/Nishchit14/status/1717515020630642780

[Nishchit14]

Evaluating Electron vs. Tauri for building a desktop app

I have been experimenting with building the desktop app with Electron and Tauri. Here are my findings so far:

Electron

Electron is highly stable with Nodejs runtime, and solves all use cases for Firecamp to build a desktop app. The drawback is they're bundling the chrome/v8 engine and nodejs in an app which dramatically increases the app size to 230MB+. also, memory consumption seems to be slightly higher (community voice).

Tauri

Tauri is perfect for building desktop apps with exciting web knowledge and with a much smaller bundle size (10mb-20mb, 10x-20x smaller than electron). But they are not offering Nodejs runtime, it's built with Rust thus they only support Rust as an app/system backend. In Firecamp our services are built with JS/TS, so they require js-runtime (web/nodejs/bun/deno) by default to function the same on each platform. Here Rust can not run js services on the desktop which is the biggest roadblock for us, however, there are some side hacks that we can try but I am more concerned about the future of the application, which I envision to be the highly flexible and scalable dev tool, which is easy to achieve if we use js-runtimes everywhere to write code once and use everywhere.

There are some side hacks that we can try to achieve the desktop application's purpose

1. use Rust services for the desktop environment

   • need to manage two versions of all services,
     • service written with JS/TS for the web environment
     • same service written with rust for the desktop environment)

2. use Nodejs sidecar with Tauri

   • can build a trpc/ws server that starts/stops on app open/close events. need to try a packaged server with all different platforms.
   • sidecar has limitations, it can only run CLI commands and communicate with command-line applications

3. use Tauri's native HTTP api

   • need to map with Axios types to make it supported with web and desktop both
   • only solves http supports, yet need to figure out a solution for socket-io, ws

Pros, Cons, and Trade-offs

Electron

• Pros:
  • Highly stable with Nodejs runtime
  • Solves all use cases for building the desktop app
• Cons:
  • Bundles the chrome/v8 engine and nodejs, increasing app size (230MB+)
  • Slightly higher memory consumption

Tauri

• Pros:

  • Much smaller bundle size (10-20MB, 10-20x smaller than Electron)
  • Memory efficient
  • Use native web view

• Cons:

  • No Nodejs runtime, so cannot run JS services directly
  • Would need to rewrite services in Rust just for the desktop app
  • Sidecar has limitations, can only run CLI commands

• Potential workarounds for limitations:

  • Use (Rust + JS) services for desktop and web, the downside is managing two separate codebases
  • Nodejs sidecar
  • Use Tauri's native http package, which has limited support atm.

App	Size
Electron	230MB
Tauri + Rust	10MB
Tauri + Nodejs sidecar	60MB

My preference at the moment is to use Electron given it supports Nodejs runtime out of the box. Tauri would require significant work to support our JS services. The bundle size increase seems a reasonable trade-off to avoid maintaining two separate codebases. But I'll keep building the app with Electron and Tauri both for some more experiments, will keep you updated here.

what are your thoughts?!!

[Plunts]

I'm currently not using firecamp, but looking for an alternative for Postman that doesn't store things in the cloud. Anyway, since there doesn't seem to be a big audience here, I'll answer to your question:

I understand that Electron is the easier way to go. The bundle size is a medium problem in my eyes and I would also accept it. But there is another point you didn't have considered (at least in your text) and that is runtime resources. Electron is eating RAM like hell and firecamp is definitly not the only App running on my system. I can't estimate the actual effort you'd have to re-implement the backend in Rust, but in my eyes it's not a bad idea to do so. Depending on your hosting conditions, it may also save you money in the end.

[nathanlesage]

You've asked for feedback over on GitHub, so to make it quick: use Electron.

As far as I can tell your app is centered around web technologies. Tauri is a cool thing but unless there's a Rust wizard among the contributors it is going to add tons of friction trying to maintain a Rust codebase regardless of how little code you actually reimplement.

I would like to disagree with the previous comment regarding memory footprint: your app is mainly targeted at devs who are often using beefier machines than regular end users, and even there, many people have Slack, Teams, Discord, and Chrome running -- effectively four electron apps; likely a few additional electron apps as well, and for most users this seems fine.

Taking everything into account, go with Electron.

[TECHNOFAB11]

My two cents on this:

I recommended Tauri but as you all said it's not great because the backend basically already exists in Node.
I still think that Electron is bad, the argument of devs having beefier machines isn't great. Maany devs use laptops and code on the go. And nobody wants even more electron apps which drain the battery (or basically increase power consumption) and are bloated. Just because these companies settled with Electron it's not a good idea to do the same.

Here's an "awesome" of Electron alternatives: https://github.com/sudhakar3697/awesome-electron-alternatives

I'm currently not very involved in the node ecosystem but there are some using Node which sound promising.
I think the most important thing is that it should use the system WebView if available and not bundle Chrome for example.

[nathanlesage]

And nobody wants even more electron apps which drain the battery (or basically increase power consumption) and are bloated.

Many apps don't do that; the only apps I know of that can be very demanding on the battery are Teams and Slack. The rest barely registers. They're bigger than Tauri, and utilize more memory, but they don't consume significantly more power than other apps. I don't know too many people who are against Electron, but that may depend on which group one is in, and I may be in a lenient one.

That being said, I gave feedback, it is ultimately not my project; so I am certain that you will make the right call! Have a good one.

[Nishchit14]

I'm currently not using firecamp, but looking for an alternative for Postman that doesn't store things in the cloud. Anyway, since there doesn't seem to be a big audience here, I'll answer to your question:

I understand that Electron is the easier way to go. The bundle size is a medium problem in my eyes and I would also accept it. But there is another point you didn't have considered (at least in your text) and that is runtime resources. Electron is eating RAM like hell and firecamp is definitly not the only App running on my system. I can't estimate the actual effort you'd have to re-implement the backend in Rust, but in my eyes it's not a bad idea to do so. Depending on your hosting conditions, it may also save you money in the end.

I agree with you @Plunts, electron app size and RAM consumption have been the biggest concerns for the whole community for a long time. But that's also true that there is no other drop-in replacement at this moment. we have big hopes from Tauri (the nearest alternative) if they can offer node bindings in the future. I can consider Rust implementations for Firecamp but there are some limited supports for protocol/api-style like socketio, kafka, etc.

I am experimenting with something futuristic atm, I'll post it here soon.

Also, We're a cloud-first app in the beginning but we do have a plan for the local first approach. i am going to release the roadmap by this week.

[Nishchit14]

Thanks for the clear opinions and feedback @nathanlesage and @TECHNOFAB11 It is really hard to choose the best out of Electron and Tauri. Both have their own trade-offs.

I have tried almost all electron alternatives listed on the given repo, majority of them lack maintenance. the only solutions we can rely on are Electron and Tauri at this moment.

As I mentioned in the above comment, I am going to experiment with something out of the box. I will soon post it here.

[Proziam]

At my current startup we use Tauri in production. It works very well and we've had no major complaints about the rust side of things since we write rust every day anyway. If you aren't familiar with rust, Wails.io is an alternative in Golang and is (IMO) much easier to maintain for non-rustaceans.

Tauri is currently (slightly) better in size, and it better supports multi-window applications if that's a consideration. Other than that you'd likely find wails to be a pretty good alternative.

[Nishchit14]

Thank you for your feedback @Proziam. I am not a Go person also :D. I found that Tauri has more features and is ahead in the roadmap than Wails.

Since you're a Rust person, I would like to ask. Is it possible to create the native Nodejs/Bunjs bindings for Tauri if the budget and resources are not a concern?

[Proziam]

@Nishchit14

Sure, there is Neonwhich provides rust bindings for Node. If you just need to reach the rust functions from JS, Tauri supports that out of the box. Since you're blending languages you'll need to make sure your types match up between Rust/TS but that's pretty straightforward.

Tauri Quickstart with Vite, the last code block shows using invoke to run a rust function from JS.

And Tauri gives you most of the normal APIs you'd want, which lets you write more JS and less rust if that's your preference.

@nathanlesage is correct that if there's nobody who is reasonably comfortable in rust the added friction may not be worth it, regardless of whether Tauri is suitable as a tool or not. Worth keeping in mind.

[Nishchit14]

Thank you for sharing those all details @Proziam

I am asking something like, we can bypass Rust completely with Nodejs in Tauri. All the heavy operations (like OpenApi parsing) will be performed at the node environment and the result will be sent to the front over IPC.

Tauri has three component

1. backend (rust)
2. core (rust)
3. front (native webview)

Here core helps as a middleman or tunnel between the backend and frontend for communication.

Now if we want to replace the backend rust environment with Nodejs, then is it possible?

The new setup

1. backend (Nodejs/Bunjs) <--- here is the major change.
2. core (rust)
3. front (native webview)

Is it feasible and possible?

[Proziam]

I believe this is doable though I've not considered it very deeply.

1. Backend (Node/Bun Sidecar)
2. Tauri Core serving as your launch point, updater, etc
3. And then whatever you prefer as your front-end, anything works

This would keep the 3 major pieces clearly separated which is nice.

[Nishchit14]

I have experimented with the sidecar feature, but it has limitations, I have explained them here #62 (comment) @Proziam

Sidecar bundles the node app with pkg, which means It'll create a CLI executable of your app, It accepts the CLI command (stdin) from frontend through invoke api and executes the command the same as in the terminal but programmatically, then passes the outcome (stdout) to the front side.

I am talking about the direct communication with invoke/IPC APIs from the web to node/bun. This feature is not available atm nor it seems to be in the roadmap. thus I just want to learn if Is it possible to implement it in Tauri in some way contributing to the core part.

[Proziam]

@Nishchit14 I see, so you're looking to either sidestep invoke or extend it for that use-case I suppose.

My recommendation is the same as:
SimonHyll and Fabian

Communicating with the sidecar is gonna have to use something along the lines of what you suggest, http or grpc. If it's enough for your purposes then I might suggest WebSocket simply because it gives you the option later to connect to it as well with your frontend, in case that's desired. There's no magical IPC with a sidecar, it's literally another binary running on your computer separate from the app, so normal communication limitations apply

Tauri is generally are very welcoming to contributions, but they are a security-conscious bunch so it would be best to ask them directly to see what they'd be willing to merge.

[MarshallOfSound]

Hey folks, Electron maintainer rolling through here to give some perspective that might be valuable (feel free to keep rolling on regardless, use what works best for you 👍). Specifically on the two cons listed against Electron above:

Slightly higher memory consumption

Without getting crazy into specifics, on Windows specifically this is technically impossible / neglible. Tauri is backed by WebView2 which is inherently backed by an identical Chromium (Blink/V8) engine to the one that Electron uses, therefore resource consumption although varies between runs due to various heuristics, on average is identical. This blog post still rings true. -- When it comes to rendering your web content, we expect little performance difference between Electron, WebView2, and any other Chromium-based renderer.

On macOS the resource usage difference is also negligible in practice, benchmarks exist to demonstrate this or you can do incredibly basic comparisons yourself between memory usage of a tab in chromium vs the identical website in Safari (under the hood that's the technical difference on this platform). In fact on modern MX series chips Chrome outperforms Safari on memory consumption tests in some cases.

On Linux I honestly don't know enough about Tauri's implementation to comment on the perf characteristics, but I'd not that most Tauri benchmarks are run on ubuntu machines on GitHub Actions and are therefore not a super great representation of real world users for most apps. (The super majority of desktop users are on macOS or Windows, and that's where folks like Chromium and therefore Electron focus most of their optimization time unfortunately).

TLDR: The reality of memory characteristics on core platforms is basically a no-diff

Bundles the chrome/v8 engine and nodejs, increasing app size (230MB+)

This truly comes down to your use case but there are a few things to consider here:

• Stability
• Security

By shipping the full engine with Electron you're paying a 200MB disk penalty (which tbh nowadays really isn't much) but you can the benefit of a guaranteed stable engine backing your app, it won't change or break randomly ever. By relying on OS provided webviews, especially on macOS / Linux that could break at any time and you basically have no recourse. This happens more than you'd think.

The inverse here is Security, if you as an app developer are not going to ship frequent updates (at least once every 8 weeks at a minimum) then you are potentially putting your users at risk by using Electron and not updating the framework. Electron does a great job of releasing security fixes, constantly backporting Chromium fixes, updating V8/Node, etc. but you have to release your app often enough that these patches make it to your users. On the flipside when using system webviews that no longer becomes your responsibility, which can be nice, but for most folks that isn't worth the price of losing complete control over the stability of your apps backing framework.

[Nishchit14]

Thank you @MarshallOfSound for taking the time for a detailed explanation. It is so grateful to hear thoughts from the core maintainer of Electron.

[TheGlorySaint]

@Nishchit14 Since the 29th of Nov 2023 past, I haven't seen a download for the Desktop Client. Could you give us a new ETA?

[Nishchit14]

@TheGlorySaint I was facing my Apple developer account renewal issue which was resolved recently. The ETA is 31st Dec. The desktop app will be released before that.

[danielloader]

Just dropping by to put some support behind SOCKS5 and to a lesser extent, HTTP/HTTPS proxy support. Similar postman competitors don't seemingly have this feature.

[Nishchit14]

@danielloader Great suggestions, Thank you. Would you mind to open the feature request for the same?

[Nishchit14]

The desktop app has been released, please follow the discussion here, #167