Develop Reference

Javascript server-render libraries with non-JS REST APIs

Are server-rendered frameworks/libraries (such as Nextjs for React, Nuxt for Vue) and non-JS REST API backends (i.e. Java, Django, Go etc.) mutually exclusive or can they be used alongside?
Specifically, I am using Go for building a REST API at the backend and I wonder if I have to give it up for having the pages server-rendered.

It's encouraged to use a separate API server with next.js even if you're using JavaScript for both. It's common to have the api on api.example.com, and to have the next.js app talk to it whether it's doing server-side or browser rendering.
If you want to have them on the same domain so you can cookies directly, you can use path aliases in now.sh, a Heroku-like PaaS from Zeit, the developers of Next.js. These can be set up in development with now-server. This can also be done with reverse proxies in nginx, apache, netlify, and CloudFront, or using path-based routing in AWS's Application Load Balancer.

These are two different concerns, really: Vue and React are JavaScript frameworks. They wouldn't run on your Go-based server application.
There's nothing to stop you from rendering HTML in a Go application, but a Go server is not going to run a JavaScript framework. If it did, it would likely require extra scaffolding, and at that point you might as well set up a NodeJS server to handle rendering those routes.

Single Page Application (SPA) vs Full Stack Applications. Constraints and Advantages.

Currently I am in the process of upgrading our web application from a traditional Spring MVC web application to a single page app with REST endpoints. Our current front-end MVC application does not use REST calls to communicate with the backend, but rather communicates with the backend (written in JAVA) by calling the necessary facades directly. Both JAR files and WAR files are being packaged in a single ear file, and deployed on our production server (currently using JBoss EAP 6).
Since we are now shifting to a single page application, and upgrading our system with a new set of APIs, I am questioning, should the Single Page Application, and the rest of the backend written in JAVA, be hosted on the same server (JBoss EAP 6)? Or should they be split onto separate servers, one to serve the SPA content and one to run the backend? In the latter case, which production server is most appropriate to host the content of the Single Page Application (JS,HTML,and CSS)? ( our backend will still be hosted on JBoss EAP 6 )
Also what are the advantages of separating the front end and backend on different servers?
I tried to search for best practices for deploying Single Page Applications with a JAVA REST endpoint but I haven't found any helpful articles applicable for our needs.
Thanks a lot in advance! :)

To answer your first query:
Yes you can absolutely separate them, and ideally you should so you can deploy the front end without dependency on web-service back-end.
You can deploy your SPA static files with any of the popular web servers like Apache, Nginx, or even on cloud hosting like S3 (behind cloud front CDN).
Assuming your REST endpoints are still going to be in Java, those would need to reside in Java application server like jBOSS, tomcat or glass fish.
Constraints/Gotchas :
Cross domain:
You can either put your JBOSS behind same Apache/Nginx reverse proxy that runs your static files.
Or you can enable CORS on web services if your domains are separate.
Lastly, jsonp is always an option if your web-services are JSON.
Authentication and Security:
Typically when you go with a full stack web framework like Spring you get a lot of security and authentication out of box. You can protect your site using sessions and CSRF etc. However with REST you typically have to use Token based authentication for your front end to speak with REST services. This is not necessarily difficult, but a different approach, and is hence listed under constraints.
Advantages:
Easier to scale the back end and front-end separately, with static SPA on a service like amazon S3 and CloudFront CDN you can infinite scaling on that part.
The back-end web services can now be easily put behind a load balancer-cluster model because your services are REST.
Its way easier to take care of deployments now because of separation of concerns.
Lesser regression issues when pushing just front-end changes. You don't have to replace entire WAR file any more.
Separate Servers or not
Depends on what kind of traffic your application is expected to handle. Let me lay down three scenarios.
Low traffic: You can put it one server with Java App server behind that Web server's reverse proxy. The web server will also serve the SPA some directory.
Moderate traffic: You should separate the fronted and Web Server on one web server and have REST services hosted on Separate machine. Technically this setup won't be much different from option 1, but your App Server will not compete with Web server for CPU cycles to respond to requests.
High traffic: Same as option 2, but now you can have multiple App servers and SPA Web servers and have one Apache/Nginx to load balance on the top.
Insane traffic over wide geographic region: You don't want to host those SAP your self in this case. It would be better to go with a a service like Amazon S3 behind CloudFront CDN, so your static content is replicated across the world for optimal response times. This would also reduce that load on your servers. Now about the App server for hosting the REST endpoints. You can either go with your own servers in cloud that host your cluster or go with PAAS like Heroku or amazon to host your WAR files and scale on demand.
Note: these scaling scenarios don't account for database, as you would need more information about your database to figure how to scale it in the above scenarios.
Hope that helps, please let me know if you need more specifics on any of the things mentioned.

This is a matter of taste.
My self prefer creating a SPA using a generator like Yeoman and then create a service with either Spring IO own setup for webservices (example here: spring webservice example) or Jersey here.
When it comes to deployment are there multiple setups.
Apache | Nginx | S3. Here is a great article for deploying an AngularJS application: deploying angular app
You will probably still need to use Tomcat, Glashfish or JBOSS ect when it comes to the Java part.
This is not an answer only my taste of choice

Now a days, front-end is hosted mostly on separate servers and back-end services on cloud like AWS, In your scenario you can use FireBase for front-end (Html, CSS, JS, Angular) and sure you can use separate server for back-end services, it is also feasible to use Spring MVC as your current framework with it as a restful services.
Take a look at this demo

Reading and writing client files from a web application

I need to implement a mechanism in order for a remote web application to communicate with a local desktop (WinForms) application that I cannot modify nor have the source of (except by decompiling). This happens by writing a file to the temporary folder that the desktop application will consume, and waiting for that application to "return" by writing another file into temp folder. Folder has to be temp folder.
Question
Is there a Javascript way to access the file system in a non sandboxed way, even by setting specific browser configuration options?
Environment
The application runs on a private LAN where all computers trust each other within the same AD domain. Plus we are theoretically allowed to map any network drive on any computer. Working in the trust zone, we don't have to care about most security concerns.
Background explanation
I have a PowerBuilder desktop application that I need to "port" to web (using J2EE) and install to a separate server, local to the same LAN. This application (named GP) currently starts a process of the child application (GC) that will not show any UI, instead it will listen for two files on a temporary directory.
When GP needs to open a window from the GC process, it will write two files: GP_to_GC.txt with a syntax I have documentation of, and GP_to_GC.flg that serves as flag file. GC will delete both after retaining and parsing the content of txt file, thus showing the appropriate UI form based on input.
The "return" is exactly the opposite. GC will write a pair of GC_to_GP files to temp and GP will refresh its views.
How can I do this with JavaScript?

Based on what I'm reading, you are porting a Desktop based Java EE application to a web application? If so, then you can continue using Java and access the folder that way; no need to use JavaScript.
What is unclear is that you're saying you can't modify anything, yet you're trying to port an application. Which is it?
If you can't modify anything, and the only thing you can do is drop JavaScript into an existing web application, then your solution is rather simple:
Create an HTTP API application that sits somewhere that has access to those folders, and issue a POST request to that API that will then read and write to the file system. It can be in any server side language you choose: Javascript (Node.js), C#, Java, PHP, whatever. It simply needs the ability to access the file system through the webserver, and most frameworks provide that capability.
I can't give you any code because you haven't mentioned which server side language you want to use to accomplish this approach.

Serving static files with nginx, available through browser?

I have a server set up using nginx to serve static files (used by two apps, one Django and the other AngularJS). My concern is the following:
If someone navigates to Example Domain (or any other static file) they can see its contents. For some reason it feels like bad practice to me that users can find all my stuff (if they know the URL or care enough to figure it out). Is this a legitimate concern or am I just being paranoid?
If this is a legitimate concern, is there a way to make it so that my server can serve my Django and AngularJS apps without the static files being visible through a browser?
Thanks

Nginx (serving html) and Node.js setup

I was thinking of building a web app which would be single page, using only javascript to update the page (no reloads). So I'm confused about what kind of setup to use.
I'm kinda new to both technologies, so I was wondering if you can set up nginx to serve html (+ js, css and other static resources) like a normal web server and then from those pages connect to a node.js websocket server (same host/ip) using something like socket.io?
Is this setup good or bad? What would be a better approach? What advantage would I get if I serve html pages in node.js and get static resources (css, js, images, ...) from nginx?

I dont think serving few images and static htmls from nodejs itself will ever be a bottleneck , ideally a front end proxy like nginx is required if you need to load balance between multiple servers and also for exposing you internal http services as https traffic. If you dont have that requirement it would be a overkill imho.

From various comments in the currently accepted answer, I wanted to note the following.
NodeJS itself does a pretty decent job of delivering static content, as good as nginx in many cases.
Trying to proxy a WebSocket connection is problematic at best currently, as most proxy code simply doesn't support it. Currently, it is best to use Node directly.
If/When you have a need to deliver static content separately, best to use another domain and a CDN at that point.