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.
Related
I have been using SvelteKit casually for a little bit now in my own personal projects. I have used other frameworks like Next.js and Nuxt.js in the past too. It has always confused me when working in these frameworks where the code I am writing is actually run.
For some context in my day job I use the ASP.NET Core platform to create more traditional web applications.
In ASP.NET it is clear to me where the code I write is run. I write frontend markup in Razor pages (just a way to write html but inject C# expressions inside). When the browser requests a page to view from the server, the server grabs the page and any data it needs, generates html from the Razor page markup and sends it back to the browser to render it into a beautiful web page 😁 Also within the same application I can write http handlers that can listen out for form submissions and interact with a database via an ORM.
In JavaScript frameworks such as SvelteKit, Next.js or Nuxt.js however this process has always confused me. I know that each of the frameworks use their respective component frameworks (Svelte, React and Vue) under the hood in some way. I also understand that each framework adds the ability to have file based routing so that files in a specific place in the src code map to a specific route in the browser. e.g. in SvelteKit you can have a svelte file at src/routes/myAmazingPage.svelte that gets rendered in when the browser browses to https://wherevertheappishosted.com/myAmazingPage.
However this is where my understanding becomes a bit clouded. When you browse between pages in SvelteKit it does not cause page reloads in the browser. This tells me that the framework is using some kind of client side routing to handle this behavior as the url at the top of the page and the page contents change without causing a page reload. There are also no network requests being sent to the server to fetch pages at a certain url which tells me that all the data fetching must be being done in JavaScript on component mount or within some other lifecycle hook.
So my question is in that case if there are no http requests being sent out per page request (i.e. when you navigate to a different page) to a server, then where is the code I write in SvelteKit actually run? Is it the case of all the code I write in SvelteKit is compiled and sent over to the browser on initial page load and then all run in the browser? Including code I write to fetch data within lifecycle methods like onMount().
Also if that is true then do these frameworks have any kind of http server running in the background to handle any other web requests? For example can I write a http handler in svelte kit to handle a post request from a form submission to save data to a database? That is the way I would go about handling form submissions in ASP.NET and I have always wondered if it is possible to do in SvelteKit, Next.js or Nuxt.js. The only alternative to this that I have used in the past is writing a separate http server written in node.js and express to handle communicating with a database and other operations, that I send all my requests from my SvelteKit apps towards.
May be a bit of an obvious question to more experienced JavaScript framework developers out there, but since working in a more traditional MVC framework like ASP.NET on a daily basis this subject has always confused me.
SvelteKit applications can be deployed few different ways to production.
In development mode, the request handler is run by Vite development server
In static production deployment mode, there is no request handler and nothing is run on the backend - the visitor just downloads HTML, CSS and JS files from the server
In server-side rendering (SSR) production mode, the requests are run by SvelteKit node adapter (Node.js process). The adapter allows also to write server-side request handlers that are not available in the static deployment mode.
Next.js and Nuxt.js have their respective own web servers written in JavaScript on the top of Node.js V8 virtual machine.
Im starting with Next and I'm kind of confused about how it works the SSR and the API. When should I use the API folder in pages instead of having my own server with a database? Does Next server for SSR will have any conflict if I had my server in Node for example?
The point is to provide a simple, scalable alternative to running your own server.
When you deploy API routes via Vercel, it will provision AWS Lambda functions on the backend to form your API.
These functions are sort of like individual snips of code that get run on demand when you have traffic.
You're right in the sense that there isn't too much difference. Just an alternative way to deploy your API. The main purpose is to make it easy and reduce the management associated with running a server.
For most use cases, it should work well but please note it doesn't have support for Websockets.
You're free to use API routes, or your own server. It doesn't matter and won't impact on the SSR.
I am currently in the process of creating a portfolio website for myself but due to hosting restrictions, I cannot make use of Node.js.
I know Angular can run on any web server, but is it possible to make use of Express.js to create web api's with relying on Node.js to run these web api's using Express.js?
If not, is there an alternative solution to create web api's that I can call using Angular and later for my mobile version of my website?
Please note that my shared hosting runs using cPanel.
As per definition Express.js, or simply Express, is a web application framework for Node.js so you can't do that. Alternatives would be to use a different backend language.
That also depends if your server supports them, for example, you can go with .NET CORE
You cannot use Express without NodeJS by definition so you have to deploy your backend somewhere else in you want to use it.
I suggest giving a look Firebase: you could write your backend using http cloud functions in express without paying anything until a reasonable amount of traffic (after that, is pretty cheap). You could also get rid of cPanel and deploy your frontend there via Firebase hosting.
Maybe you can try to build at first a web application with express. Of course you can create a web app without express if you need it. With express and Node.js I created a MySQL REST API. With HTML and Ajax you can fetch the Data from the API. So you can create two applications. One application where you need to run Node.js because it`s much easier to create a REST API with express. The second one is fully without Node.js.
Maybe there are better solutions, but inside each Web Application you can than but you can then access this API in any web application using jQuery. It doesn't matter if it is written with PHP, ASP.Net Core, Java EE / EE4J. You can also access this API in Ruby, Angular, React, Vue etc. using an AJAX request.
In some scenarios you can't start Node.js as a server because an application is already running on apache2 or nginx. There this would be a workaround to use something like this. For example, one could also integrate applications with HTML+JS in a CMS system that accesses other database tables and thus extend such a system without an iframe.
So can be helpful for few scenarios. Now just doesn't get around the actual goal of doing without Node.js completely or even express. But why are there REST APIs? So that you can query the data and incorporate it somewhere else. Otherwise you would have to build a REST API with another technology. Especially in the example of accessing MySQL with JavaScript, this would not be quickly feasible.
If you are looking for a similar solution to separate the web app and the REST API, but you don't need Node.js, then you should really build a REST API with .Net Core or with another technology, depending on what is possible and installed on your server. It could be Java or PHP behind it or Ruby.
The API that provides the REST access does not have to be written in JavaScript. You only need to be able to access it with JavaScript. So you can use many different approaches to access JSON data. I hope that in the short time with my bad English I have explained the basic idea, how to proceed stylistically and where advantages exist in REST interfaces.
With this, it should be self-explanatory that you don't have to use NodeJS and Express, but with JavaScript it's a pleasant solution. Only you have to ask yourself if a JavaScript application has to provide this interface at all or if in the end only a JavaScript application has to access this interface. Very big difference.
For backend rest api you can use golang with gorilla framework. Golang simple keyword and easy to learn.best important point is performance. If your server support golang you can use golang for backend..
ExpressJS is NodeJS framework so it's impossible to create an API without NodeJS.
Angular is front-end framework so you can host it on web hosting server.
If you need to create back-end APIs, you can use other clouding host servers that support NodeJS.
It's fairly simple to build this with just the net/http package. Set up a router that handles various commands and deal with the response accordingly.
I've developed a web application using React and Redux and then packed it with Webpack, it's hosted using IIS and presumably just runs client-side and makes calls to a Web API (.net for reasons); also hosted on IIS.
How do I make the jump and make this application 'isomorphic' so that the React code runs both client and server side?
You'll need a few things:
1) some way to run node: Really the only things that happen server-side with React are a renderToString call to give you strinigfied HTML you can send to clients (it's just a static HTML rendering of your app w/ React), hydration (see more on that in a bit) to get data into your components, and route-matching.
2) a router (if you have routes): If your app uses multiple routes, you'll need to use React-router to tell node what component(s) should be rendered
3) a good reason to go universal: there are some relatively simple aspects to going universal and there are some relatively complicated ones. Matching the routes isn't all that hard, and it will essentially just be you telling your server what to send down. The harder, more complicated part of universal JS w/ React is fetching data to send down to clients on initial render. This usually involves some server-side data fetching, so you have to have a way to both get the data and pass it into your app to be rendered correctly. There are ways to do this, but it is certainly a significant step up in terms of overall complexity.
This is how I did it, w/o the need for any server-side data fetching: Server side rendering with react, react-router, and express
See also:
https://ifelse.io/2015/08/27/server-side-rendering-with-react-and-react-router/
http://jamesknelson.com/universal-react-youre-doing-it-wrong/
You need Node.js to make an isomorphic web app.
This is because an isomorphic application requires an appropriate server-side runtime to execute the React Javascript code on the server. I don't believe IIS has support for parsing Javascript exactly - only Node has this runtime.
If you aren't using Node, then you should introduce it at some stage in your application. You can use IIS as a reverse proxy: create a Node server for IIS to forward requests to, let Node render the React as static HTML using renderString, and then have Node respond to requests from IIS with the rendered HTML. IIS will act as middleman for all incoming requests and responses.
Reverse proxies add some minor latency to an application, but, as always, premature optimisation is the root of all evil.
One of my team members is working only on client-side (Javascript) development for a web app with a large and complex backend.
I would like to avoid the need for him install and configure a local copy of the backend.
However, I wouldn't want him to need to push every small change to the dev server just so that he can test it.
We thought about getting the client to make the requests directly to the dev server, instead of to the same domain (the localhost) but this doesn't seem practical due to cross-domain request policies and authentication problems (cookies aren't getting sent).
What are some elegant solutions for developing clients without having a local backend?
Depending on how complicated your backend is, you might be able to create a mock backend using a lightweight web framework like Sinatra. I've had some success with this technique, but the services I've been mocking have been fairly simple. In some cases the mock backend mostly serves static JSON files.
I use Charles Proxy to map the URIs of the dev server's web services to localhost (where I run a light weight web server that serves up my static development code).