At first I wanted to build a tool to transfer files to and from a Glitch project, which many posts in the feature requests section confirm I’m not unique in desiring.
I decomposed this into two problems: (i) a way to transport data between a local computer and a Glitch project and (ii) some additional logic and user interface to harness that data transport for file transfer. In this report I focus on (i). That’s all we’ll be discussing–what’s the best way for a project administrator to set up a one-off data communication between a local computer and a Glitch project.
Background: the elemental communications with Glitch
There are a few ways a Glitch project connects to the outside. Let’s review these:
- Anyone (only approved users in the case of private projects) can communicate with the project over HTTP on the project’s
- A project member can view and modify code files through the web editor.
- A project member can open a terminal session.
- A project member can connect to a debugger.
- Anyone (only approved users in the case of private projects) can fetch the project as a Git repository and a project member can push to it.
- A project member can upload assets.
- A project member can view project logs.
- A project member can execute a command and get its output.
I’ve built some cool things with (1), and it’s a highly capable means of communication, but it doesn’t seem right for this job. I’m focusing on public projects because they’re available for free, which means that we’d have to build our own authentication system. It’s also more disruptive in that the tool would somehow have to set something up on the project to intercept whatever data we’re sending.
Option (2) is limited to files that would show up in the editor, and it’s limited to text. I can’t help but imagine that I’d be using a ‘file transfer’ tool to back up and restore binary database files from
.data though–not shown in the editor and not text. I have some experimental scripts to do this already, but for these reasons they don’t live up to my expectations of a ‘file transfer’ tool. It has a nice property that you don’t have to run
refresh afterwards, so I’d like to add this to my snail CLI suite regardless.
Option (3) is built on WeTTY, which is built on a package called
node-pty, which it turns out has a text-based API. There’s also whatever translation terminal devices normally do to make sure, for example that nothing takes effect until you press enter and that line endings get munged up properly.
Option (4) is intriguing, but I see a lot of people complaining that it doesn’t connect right, so I’ve held off on using it for this job. But I’ve recently started looking into it, and I might revisit this.
Option (5) is pretty much meant for transferring files, but it has some limitations. It’s restricted to stuff in the Git repository at
/app. Moreover, if I’m to be a good person, I’d have to restrict myself to things that should go in version control. Furthermore, any file transferred this way would first have to touch down in the most precious
/app mount (i.e. the one limited to 200 MB (some other number for boosted projects)) because that’s where the
.git directory is.
Option (6) can and, in recommendations already on this forum, is paired with a
wget from within the container to achieve a fairly low-hassle one-directional transfer. You could also transfer things from a project by giving the project a copy of Glitch’s upload policy. I want to explore the idea of a project uploading assets on its own sometime. But this approach has drawbacks too. It makes the file public, and you can’t later delete the file from the CDN, which is undesirable from a security standpoint. Maybe you could hide it by uploading under a long unguessable filename and not updating the .glitch-assets file, but I don’t know how secretive Glitch is overall with asset filenames. Also, it’s two separate transfers through two different servers, which feels like it would be inefficient.
Option (7) is too crazy, even for me. Perish the thought.
Number (8) actually exists separately from the terminal, in case you didn’t know. It’s used in things like the editor’s ‘find in all files’ function. You can send a command and get the result back as a string. But that might be a little scary for file transfer, because in several places the file would have to fit in memory.
An unlisted option is that we could build it upon a bug in Glitch that allows us to connect to a project. But we shouldn’t both (i) hope for Glitch to get faster at fixing security vulnerabilities and (ii) hope for the longevity of tools that exploit a vulnerability. And we’d better side with (i), because what good would it be if we could transfer files but those files weren’t safe?
Next post: choosing from these
The options don’t look great, but they’re all we have. In the next post, I’ll discuss which one I went with.