Neovim

There are sssssooooo many good options for deploying a web service to production, there is really no space here (or probably anywhere outside a dedicated year-long course) to learn all the necessary technologies for even a part of this huge space. So instead - lets start with the easiest one (IMHO, others may disagree): AWS Fargate.

AWS Fargate is a simple container runtime - there are others, but Fargate excels in that it is very simple to create and manage (you basically let AWS manage it for you) and you don't need to worry about servers and control nodes and proxies and other things other container runtimes (such as Kubernetes) will have you worry about. On the other hand, it does not skimp on performance and if you ever want to go Kubernetes (which is all the hotness these days) - there is a clear and simple "upgrade" path.

How do you get there? First learn what a "container" is - the concept was popularized by the Docker product and it is pretty much an industry standard (there are other container formats, but the Cloud Native Foundation's format is basically the Docker format) - a container allows you to bundle an application in an lightweight operating system image and run it as an application. A container runtime can then take a container and run it, scaling it up as needed, without you needing to manage deployment scripts, process management and stuff like that.

To deploy your Java web service on AWS Fargate you need to do the following:

1. Package your Java web service in a JAR file. Maven is the common tool to do that, though gradle is also very popular. There are other build tools for Java but you probably want to choose one of these two and learn it. Gradle is somewhat simpler to start with but it gets complicated pretty fast (it is basically a scripting language for building with a lot of "magic" - which often implies a stiff learning curve). Maven looks more daunting at first - with all that messy XML to read and write - but its internal complexity peeks really fast and then adding new functionality is basically just using (or creating) new plugins with the same simple configuration language.

2. Create a container image from your JAR file that can run it as a container: You obviously need to learn Docker and how to write Dockerfile scripts - this is pretty easy and straightforward, then look for examples how to run your specific application in a container - depending on which Java framework you're using. My weapon of choice is Vert.x and here's the documentation for that on Docker: https://vertx.io/docs/4.3.7/vertx-docker/. If you are using Maven then you can use a plugin to automate building the container image for you - but you should still learn how to do it yourself to understand what's going on. I use com.spotify:dockerfile-maven-plugin (it is very simple and stable but also have stopped development) or you can use io.fabric8:docker-maven-plugin which is newer and more capable but also more complex. You may be able to use these with Gradle as well - I don't have any experience with that.

3. Create an AWS account and learn about setting AWS Fargate and AWS Application Load Balancer (you should use an AWS load balancer to expose your Fargate service to the public internet - the alternative is at best much more complicated and at worst unreliable). AWS has a lot of good documentation on the subject. You can start by setting everything up in the AWS console, but you should really learn how to do it with the AWS CLI tool and also recommended to use an automated provisioning tool such as AWS CloudFormation or Terraform. The advantage of using Terraform is that it is not AWS specific and if you ever want to move to a different provider, you can take Terraform with you, OTOH it is more complex to learn and operate.

4. Set up a continuous integration (CI) pipeline to automatically build and deploy your service. There are many good options, but you should probably stick with what your source control service provides: Github Actions, Gitlab CI, Bitbucket Pipelines, Azure DevOps or maybe even AWS CodePipeline (if you already use AWS you might want to go full in). AWS also has a full git repository hosting (AWS CodeCommit) and integrated CI/CD (AWS CodeStar) so you can keep all your eggs in one basket - they do make it very simple and easy to maintain and control, but the standard caveats about eggs and baskets apply.

5. Deploy your service and then monitor it - this is a completely different huge ecosystem that you'd need to know about when you actually need to maintain a "real" production service. I use StatusCake (for external status monitoring), AWS CloudWatch (internal status monitoring and alerts) and OpsGenie (on-call management, alerting and escalation).

Hello,

As for hosting the front-end, the choice would be Vercel. Super straight-forward non-nonsense deployment. As for Java, I'd package it in a Docker container, and deploy it this way.

There are multiple options for deploying Docker containers: Azure, GCP, and AWS will have them, and there's very little to no difference between them. From some tests I have seen, Azure and AWS are faster than GCP.

Neovim can basically do everything Vim can with one major advantage - the number of contributors to the code base is just so much wider (Vim is ~100% maintained only by B. Mooleanaar). Whatever you learn for Neovim you can also apply to Vim and vice versa. And of course there is the never ending Vim vs Emacs controversy - but better not get into that war.

Actually, the biggest advantage with Neovim (as a VS user) is that you can embed REAL Neovim as the editor UI, rather than using a "Vim emulation", you're using actual NVIM, embedded in VS!

"asvetliakov.vscode-neovim" is the extension you are looking for:

1. Install the 'vscode-neovim; extension (https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-neovim)
2. Install Neovim version 0.5+ nightly
3. Start winning.

(You can install neovim-nightly separately for just vscode, I usually build and install it to /opt/nvim - it's enough enough to do - let me know if you need help).

Works wonderfully. It might not work out of the box if you have some 100K epic nvim initialization file, but the plugin documents a workaround for having an embedding/VS specific configuration.