This Week #11: New cycle, binwrappers, and comments support

Lucille

This week, I focused on refining the team-switching UX for Jetpack users - extending authentication sessions and exchanging JWTs based on their chosen organization. I also did some investigation with Rodrigo on how users can start a new project on Jetpack with their GitHub repositories, which involves looking into GitHub OAuth and App installation flow.

On the flip side, I battled Vercel issues with serverless functions, which I couldn’t reproduce locally. The build failures fixed themselves miraculously on Friday, but the ordeal left me longing for a more consistent and reliable build process for production applications that is easily reproducible locally. Isn’t that what Devbox is for?

Mohsen

This week, I continued my work on integrating payments into our paid feature system. It mainly involved implementing the update and cancellation flows of subscriptions. I also implemented a bit of frontend in which I had to refresh my memory on react and learn how Remix works, plus Tailwind CSS classes. Overall, we made significant progress on finishing up payments. I’m confident we can have a demo-able payment system by the end of next week.

Daniel

From a technical perspective, I've mainly focused on building a "unified API service" that can act as our primary backend for Jetpack Cloud. As we've created different features and products, we've ended up with a mishmash of ad-hoc APIs and services.

Instead, we plan to unify those services into a single API service. I'm experimenting with Buf's Connect, to declare the interface of the API, and then automatically generate server and client code from that definition.

John

Wrapping up some of the documentation work from last week, I published a first draft of the docs for Jetpack Cloud + Secrets. In the process of writing these docs, I assembled a friction log for the team that highlights some good improvements in our Authentication and Secrets management flow that we can focus on for the upcoming cycle.

We're also heading into a new cycle, so I worked with the team to prioritize the key projects for the upcoming sprint. In addition to the work on Secrets and Deployments, one project we've decided to prioritize is removing our wrappers for Nix binaries in Devbox projects. This project should address a number of issues with performance and reliability. We also expect it to simplify how services and scripts work in both the project and global setting.

Savil

I spent most of last week planning for our next cycle. I'll be focussing on our upcoming secrets product and teaming up with Greg to add a new backend storage on the same cloud provider as the deployments tool that Rodrigo and others have been developing. In addition, I'll get the chance to be re-acquainted with the wild, wonderful world of frontend engineering to finish up the Secrets Dashboard that Lucille had begun, as she'll be focussing on a more meatier frontend project.

In addition to this, I landed a couple of Devbox improvements. One is a perf improvement to devbox add or devbox install that adds a local file cache. This cache affects a code path for users on nix before version 2.17 who cannot benefit from the Devbox 0.6 perf improvement. The bottleneck in this scenario was calls to nix search, an API that accepts a regular expression for a wide range of queries and hence can be slow. However, most of our questions have a particular pattern that will always resolve to the same result for a user, i.e., they are time-invariant. So, we can cache them once nix has resolved them for the user's system. On my system, for a devbox.json with about 50 packages, this resulted in a 20x speed improvement.

The other improvement was some fixes for users of zsh shells when starting a devbox shell. We now respect ZDOTDIR and better resolve the startup files (like .zshenv).

Greg

Aside from planning for the upcoming cycle, last week, I merged a change that allows devbox.json to have comments and trailing commas. This change is one of those features that seems trivial, but requires a bit of work so that edits made by the CLI maintain the positioning of comments.

Next week I'll be switching gears and helping with the backend work for Devbox secrets management.

Mike

I did some planning for the upcoming cycle and focused on a big change that removes bin wrappers from devbox. Bin wrappers were introduced to refresh the environment automatically but have historically been a significant source of bugs and performance issues. So we decided to remove them and instead rely on messaging to refresh the environment when needed. In the future, we think we can use shell hooks (like direnv does) to refresh the environment automatically without having to use bin wrappers at all. This change is currently in a PR.

Rodrigo

Last week I worked on deployments, and finished making the dashboard and the webhook listener read from the database. This integration means we can remove any hardcoded data on the webhook listener. Users can now edit deployment settings for their project in the dashboard. Lastly, we started testing deployments internally by migrating our Nixhub search-service to deploy on every merge to the main branch.

The next step is to integrate the deployments product with envsec, so that a project's secrets get pulled into the service at deployment time.