loading...

Localhost isn't local anymore

lostintangent profile image Jonathan Carter Updated on ใƒป5 min read

Visual Studio Live Share (7 Part Series)

1) In Pursuit of Enjoyable Developer Collaboration 2) Localhost isn't local anymore 3 ... 5 3) Collaboration doesn't come in "One Size Fits All" 4) Collaborative Development Requires a Shared Web Browser 5) You Can't Spell Collaboration Without Communication 6) Providing a Real-Time Complement for Git-Based Collaboration 7) Building a Fully-Extensible Developer Collaboration Platform

In my previous post, I discussed the reasons why we built Visual Studio Live Share, and the various ways it can improve the collaboration experience for developers, regardless of the type of app you're building (e.g. desktop, mobile, games, web). However, in this post, I want to drill into a capability that Live Share provides, which is targeted specifically at web developers: sharing localhost servers.

Image #1

Sharing port 8080, and having that be immediately available to guests (left) in a Live Share session

Collaboration should be easy

When you're collaborating with another developer, it's important that they can visually see the application you're working on. That way, they can repro a bug you're encountering, provide feedback on some UI changes you made and/or verify a fix you did together. However, if the app you're building is a web front-end or API (REST, GraphQL, etc.), and it's running locally on your dev machine, then how do you actually share it with them, so that they can interact with it, independently of you and using their favorite tools (i.e. not a screen share)? You could...

  1. Push your changes to version control, and ask them to pull them down and run the app locally? However, that would require everyone to have their environment setup to run the app, and this workflow wouldn't support iterating on the codebase in real-time (blah!).

  2. Deploy the app to the cloud, and then send everyone the publicly-available URL? However, you might not be ready to deploy yet, and this workflow suffers from the same iteration issue as #1, since you'd have to re-deploy the app on every code change (not cool!).

  3. Configure your router to forward the application port, and then send everyone your IP address? That would support making real-time updates to the code, however, it requires you to expose your machine over the internet, which may be undesirable or even impossible (depending on your network proxy/firewall settings).

  4. Setup a โ€œbastion serverโ€ that is internet-accessible, and you can use to reverse-forward local ports over (illustrated here). This provides a more secure mechanism, but it requires you to pay for/manage a VPS, and itโ€™s somewhat complex to setup.

  5. Use a service like localhost.run, serveo or ngrok, which are free and simple to use. However, they require using a separate tool, in addition to your editor, which adds additional complexity.

So with all these options available, that raises the question: how can you share a running web application, in a way that is not only easy to setup, fully secure, but also enables you and your team to edit the code in real-time, and immediately see the changes? That's where Live Share comes in!

Share all the things

When you connect to a Live Share session, an SSH connection is established between you and the "host", which ensures that all communication (e.g. file edits, debug steps) is end-to-end encrypted. That secure connection can then be used to enable all kinds of collaborative context, including the ability for "guests" to view shared web apps, as if they were running on their own machines. But they're not. It's...kind of magical ๐Ÿ˜Ž

When hosting a Live Share session, you can share a server at any time, by simply clicking the Share server... command within the Live Share view, and then specifying the respective port (e.g. 8080). It will immediately become available to all guests in your session, and they can open it in their favorite browser or API development tool (e.g. Postman).

From there, you can both make edits, and immediately view the changes. Even better, if your web app is setup to use "live reload", then when you or a guest saves a file, everyone's local browser will automatically update, regardless if you're on opposite ends of the world (or on a plane)! ๐Ÿ›ซ

Easy peasy lemon squeezy

While sharing a server enables a powerful form of collaborative web development, it still requires you to perform a manual gesture, which can become a little repetitive over time. Since our goal is for collaboration to feel like a natural extension of your existing developer workflow, we thought we could do better. And so we did.

Image #2

Using the Live Server VS Code extension to serve static HTML, and having the server port automatically shared

Whether you're using the Live Server extension to host static HTML files, running your front-end via a CLI like create-react-app, Django, Phoenix, etc., or pressing F5 in Visual Studio from an ASP.NET project, Live Share will automatically detect the server and share it. That way, you don't need to do anything special to use Live Share. You simply work the way you prefer, and let the tools take care of the rest ๐Ÿ‘

Image #3

Using the create-react-app CLI to spin up a dev server, and having the server port automatically shared

To keep things secure, we only auto-share ports that are commonly used by web frameworks (e.g. 3000, 8080), which prevents us from accidentally sharing something you wouldn't expect. Additionally, if you want to disable the auto-sharing behavior, and stick with manual sharing, you can disable the liveShare.autoShareServers setting as well. This way, we can provide a simple, out-of-the-box experience, while still giving developers the control they need to feel confident.

Screen Shot 2019-03-26 at 8 40 51 AM

Unleash localhost

Now that sharing localhost servers is simply a click away (the Live Share button that is...), we're eager to hear any and all feedback on how we could improve the experience even further. Web and API development is one of the core scenarios for Live Share, and so we look forward to evolving the collaborative development experience, and accommodating the needs of every developer, regardless of their language or platform.

If you run into any issues, or have questions/comments, please don't hesitate to ping our team on GitHub. Additionally, if you'd like to take a quick survey, it would be immensely helpful to our team. Thanks!

Visual Studio Live Share (7 Part Series)

1) In Pursuit of Enjoyable Developer Collaboration 2) Localhost isn't local anymore 3 ... 5 3) Collaboration doesn't come in "One Size Fits All" 4) Collaborative Development Requires a Shared Web Browser 5) You Can't Spell Collaboration Without Communication 6) Providing a Real-Time Complement for Git-Based Collaboration 7) Building a Fully-Extensible Developer Collaboration Platform

Posted on by:

lostintangent profile

Jonathan Carter

@lostintangent

I build developer tools and services at Microsoft (currently VS Online, Live Share, IntelliCode, and Playwright, previously CodePush, IE Dev Tools, Visual Studio, Azure).

Discussion

markdown guide
 

Great title. :)

I've used live sharing with my brother to check out his code. It was not stable enough at that time but still it was cool.

 

Hey! How long ago was this? I'd love to make sure we address any stability issues you ran into (assuming we haven't already ๐Ÿ˜Š).

 

I am bad with dates :) I belive it was near public launching. Maybe during closed beta testing.

As a useful feedback I would suggest you to make a clear visual message what Live Share will share-n-sync to rock-n-roll. I've seen some articles and tweets about it. But still my mental image of what it is capable of is not clear.

Just a small tip & feedback!

In general I'm looking forward for help my bro with new and updated Live Share feature :)

What if I told you that everything was shared? Files, terminals, debugging sessions, language services, workspace tasks, and most extensions state (e.g. GitLens, Test Runner) are all now automatically shared, which alleviates the "host" from having to worry about what is and isn't shared.

Additionally, when someone shares for the first time, we open a "Getting started" page in-tool that explains exactly what is shared. I'd love to hear if you have thoughts on what we could do to make this more clear, since this is definitely something we want to convey accurately to users.

 
 

ngrok is an awesome tool! In general, if you're already collaborating on code, then we wanted to enable sharing a localhost server without needing to rely on a separate tool to do it. But if you just want to share a server, then ngrok is a great option.

 

This is awesome. I really like reading about a project where so much care and concern went into the developer experience of the tool and not just on building something cool. Great post.

 

Very cool!
Will definitely try this out at work this week.

 
 
 

Was this where the idea for Remote came from? :)