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.