NgSysV2-5.3: A Young Person's Introduction to the Google Cloud Shell

This post series is indexed at NgateSystems.com. You'll find a super-useful keyword search facility there too.

Last reviewed: Jan '25

1. Introduction

Would you like a free computer? How about one loaded with useful tools and lots of memory, one that is geared specifically to doing the sort of jobs you've been working on in this series? Interested? If so, please read on.

This series has recommended the use of Microsoft's VSCode IDE (Interactive Development Environment) as a general-purpose development "hub". As you know, this is the "Swiss army knife" of software that lets you:

• create and edit source code
• run terminal session to install libraries, start local servers and make deployments
• use Git to commit changes to both local and remote repositories

But, while you've probably found this all perfectly satisfactory, let me remind you that nothing stands still for long in IT. A fresh wind of change is now blowing through the world of Interactive Development Environments.

Because your code is designed to deliver applications running out in the "Cloud," people have started to wonder why development source code isn't in the Cloud as well.

All three major cloud platforms—Google, Amazon, and Microsoft—now offer "Shell" products, which consist essentially of VSCode clones that run in your browser. The development code base is now stored remotely, and build/deployment workflows are closely integrated with their target server platforms.

Before you panic about learning a whole new set of editing procedures, let me assure you that these new IDEs look startlingly familiar—they just run in the browser rather than as independent local apps. You'll also be interested to hear that the services are free of charge.

This post describes, specifically, the Google Cloud Shell (GCS). Here's a list of its advantages:

• No VSCode installation
• No npm, Node.js or Git installation either - these tools are built into the GCS (along with many others)
• Svelte projects can be deployed to services like Firebase Hosting or Google App Engine directly from the shell
• You can work on your code, without any preliminary preparation, using any device that has a browser and network connection

If the GCS lives up to these claims, I imagine you'll easily see how it would have saved you a ton of time and trouble when you were working on your first webapp project. I'm also wondering why I ever bothered telling you anything different. Let's build a Svelte project with the GCS and see if the reality is as good as the hype:

2. Building a Svelte Project with the Google Cloud Shell (GCS)

You start the GCS in the browser by clicking its URL at ide.cloud.google.com. Actually, let me qualify that - in practice, it seems best to use a right click and select "open in a new window". This then lets you use the F11 function key to switch the new window into full-screen mode. As you'll know by now, every bit of screen space is precious in an IDE. You won't want to waste any of this on a browser menu.

What happens now is rather magical. Assuming that you're logged into a Gmail account, Google now sets about creating a virtual computer for you somewhere up in the Cloud. This has up to 5GB of file storage for your code and configuration files (Firestore storage and CPU for a deployed webapp would be billed separately, as normal). Once activated, this "computer" remains permanently associated with your account. Sure, if you leave it unattended for 20 minutes or so, it will quietly close itself down, But once re-reference, your working environment is magically recovered like a desert rose after a shower of rain.

Naturally, the initial reference takes a little time - 20 seconds or so - and while this is going on, Google takes the opportunity to give you some background information about the GCS and then displays a Welcome screen headed "Learn the Essentials".

This offers opportunities for some initial configuration, too, but I think that you're likely to find that this just adds to your understandable confusion as a first-time user. My suggestion is that you leave everything alone here for now. There'll be plenty of opportunities to explore later.

Once things settle down, this is what you should see:

I hope you'll agree that this looks surprisingly VSCode-like. Down the left-hand side of the screen are all the familiar Explorer, Search, Source-control, Debug and Extensions tools. The Edit window itself is still open in the strange Welcome utility, but you can easily imagine this will become the panel in which you edit files. Below this, a terminal session has opened on your Gmail id.

Things will become even more familiar if you accept the Welcome panel's offer to "Open a Home Directory". This triggers another wave of GCS initialisation, after which (once you've clicked on the Explorer tool), the screen should look like this:

You've now got the beginnings of a working directory in the familiar column adjacent to the tools menu. A README.txt file is open in the editor panel, and you might like to edit this and confirm you can update and save it. The familiar main IDE menu bar is displayed at the top of the screen, too, so take the opportunity to use this to open a terminal panel. Once you've sized things to suit your usual working arrangement, I hope you'll agree that this looks very much like the familiar old VSCode arrangement.

The next job, I suggest is to see whether you can use this to install, test and deploy a Svelte webapp. If you have read posts 2.1 and 3.6 in this series you'll remember that this was quite a procedure. Your new GCS system makes the job almost trivial!

The first task is to create a folder for the webapp. Open a terminal on the project root and enter the following commands:

mkdir my-svelte-app
cd my-svelte-app

Now install Svelte into this:

npm create vite@latest .

I'm using a Vite install here because it provides a generic tool for selecting Svelte from a long list of alternative Frameworks. You're also invited to add standard libraries, such as Tailwind. This way, you're less likely to forget essential steps in the procedure.

This Vite installation interface is very similar to the Svelte arrangement. The up/down and space keys are used to select items presented as lists, and the return key activates the selection. If you get stuck, be comforted by the knowledge that all you have to do is delete the my-svelte-app folder and start again.

For this particular experiment, you should select Svelte as the Framework and SvelteKit as the Variant. Then choose the SvelteKit minimal template and decline the offer to use Typescript (though it won't be long now before you will know enough about Javascript to appreciate why you will find this useful). I also suggest that you skip the opportunity to add development libraries to this experiment (though in other situations, I myself would certainly have chosen to add "eslint" and "tailwind"). Finally, choose "npm" as your package manager.

After one final "return", Vite completes the installation and invites you to launch the development server. Give it a try:

npm run dev

This should display the familiar terminal output:

> my-svelte-app@0.0.1 dev
> vite dev


  VITE v5.4.11  ready in 787 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

Finally, then, a "ctrl-click" on the http://localhost:5173/ bit of the display should produce the reassuring "Welcome to SvelteKit" output of the barebones Svelte webapp.

So, that was a good start. Svelte is installed in your new Cloud Computer's workspace, and you can run a development server there. But now, can you use this to build and deploy a public version of the barebones webapp onto the web?

This seems quite a big ask, and, in fact, while there's nothing to stop you from launching an npm run build command right now, you'll find this concludes with the following warning message:

> Using @sveltejs/adapter-auto
  Could not detect a supported production environment. See https://svelte.dev/docs/kit/adapters 
to learn how to configure your app to run on the platform of your choosing

This is telling you that you haven't configured an appropriate Svelte adapter for your project. For Google App Engine targets, you need to install the @sveltejs/adapter-node adapter as follows:

@sveltejs/adapter-node

Then you also need to declare your use of "adapter-node" in your project'ssvelte.config.js file as follows:

import adapter from '@sveltejs/adapter-node';

export default {
  kit: {
    adapter: adapter(),
  },
};

A build should now conclude successfully

Just three further points need to be covered before you can deploy your webapp.

First, you need to create an app.yaml file to direct the build. Here it is:

runtime: nodejs20

env_variables:
  NODE_ENV: production

Here, nodejs20 confirms that your webapp will run on Node.js version 20, the version currently recommended for App Engine use. Setting NODE_ENV to production optimizes the Node.js frameworks and libraries for performance and security.

Finally, you need to add the following line to the "scripts" section of package.json

    "start": "node build"

This tells App Engine to start the Node.js server on the content of your build folder.

You're now in a position to deploy your Svelte webapp with a command of the form gcloud app deploy --project=[project-id]

Here, [project-id] is the uniquely qualified ID of a Firebase project that you own. Ah, it's obvious really - how can you deploy to a project in the Google Cloud without telling gcloud which one it should use? But where will you get this from? Well if you've been following this post series from the beginning, Post 2.3 will have created a project name based on the root name "svelte-dev" - "svelte-dev-afbaf", say. Why not reuse this here? There's absolutely no reason why not. So, now deploy with the following command

gcloud app deploy --project=svelte-dev-afbaf

If all goes well, you should now be able to launch your webapp at https://.nw.r.appspot.com and see, once again, the familiar "Welcome to Sveltekit" message from the barebones Svelte webapp.

3. Wind-down

It might be worth sitting back for a moment and reflecting on what you've just done.

With little more than a click on a URL reference, you've just given yourself a top-class editor and a playground to run it in. Then you've used this to build a mini website and launched this onto the web where gentlemen in China could peruse it if they chose. None of this has cost you a penny and, if all went well, probably took you no longer than half an hour. I'd say that was a good morning's work by any standards.

More seriously, while this has been a very superficial introduction to Cloud Shells, I hope it has given you a taste of what is available. Clearly, there are some disadvantages to a browser-based IDE. Startup is noticeably slow and I shall be looking for ways of improving this. On the other hand, the close integration with the Cloud platform itself is likely to pay dividends. Some users are likely to be particularly interested in the possibility of using adapter-node to deploy a webapps to Google Cloud Run, as this has certain advantages over the older App Engine hosting.

For further details on the GCS, check out Google's documentation at Launch Cloud Shell

Footnote

If you've been following this post series closely, you may wonder why the GCS has enabled you to deploy with the official Svelte adapter-node generic node.js library rather than the community-supplied open source svelte-adapter-appengine used in Post 3.6. This is because GCS is tightly integrated with Google Cloud, abstracting many deployment complexities. Locally, you must manage those complexities yourself, and community adapters step in to bridge the gap. While there's absolutely nothing wrong with using the community adapter, some developers might be more comfortable using the official Svelte version.