Where to configure what part gets rendered on server-side and what renders on client-side while using Rendr.js?
The documentation and blogs everywhere mention that it's main purpose is to make a common way to write client and server code.
Rendr is a small library that allows you to run your Backbone.js apps seamlessly on both the client and the server. Allow your web server to serve fully-formed HTML pages to any deep link of your app, while preserving the snappy feel of a traditional Backbone.js client-side MVC app.
But how to configure when server side rendering happens? Or does Rendr decide on it's own?
What I want to do is decide which part gets rendered on server side since I am trying to develop a single page application.
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.
Sometimes when I create basic web tools, I will start with a nodeJS backend, typically creating an API server with ExpressJS. When certain routes are hit, the server responds by rendering the HTML from EJS using the live state of the connection and then sends it over to the browser.
This app will typically expose a directory for the public static resources and will serve those as well. I imagine this creates a lot of overhead for this form of web app, but I'm not sure.
Other times I will start with an API (which could be the exact same nodeJS structure, with no HTML rendering, just state management and API exposure) and I will build an Angular2 or other HTML web page that will connect to the API, load in information on load, and populate the data in the page.
These pages tend to rely on a lot of AJAX calls and jQuery in order to refresh angular components after a bunch of async callbacks get triggered. In this structure, I'll use a web server like Apache to serve all the files and define the routes, and the JS in the web pages will do the rest.
What are the overall strengths and weaknesses of both? And why should I use one strategy versus the other? Are they both viable and dependent upon scale and use? I imagine horizontal scaling with load balancers could work in both situations.
There is no good or bad approach you could choose. Each of the approaches you described above have some advantages and you need to decide which one suits best to your project.
Some points that you might consider:
Server-side processing
Security - You dont have to expose sensitive information (API tokens, logins etc).
More control - You will have more control over what you do with your resources
"Better" client support - Some clients (IE) do not support same things as the others. Rendering HTML on the server rather than manipulating it on client will give you more support for clients.
It can be simpler to pre-render your resources on server rather than dealing with asynchronous approach on client.
SEO, social sharing etc. - How your server sends resources, thats how bots see them. If you pre-render everything on the server bot will be able to scrape your site, tag it etc. If you do it on the client, it will just see non-processed page. That being said, there are ways to work around that.
Client-side processing
Waiting times. Doing stuff on the client-side will improve your load times. But be careful not to do too many things since JS is single-threaded and heavy stuff will block your UI.
CDN - you can serve static resources (HTML, CSS, JS etc) from CDN which will be much faster than serving them from your server app directly
Testing - It is easy to mock backend server when testing your UI.
Client is a front-end for particular application/device etc. The more logic you put into client, the more code you will have to replicate across different clients. Therefore if you plan to have mobile app, it will be better to have collection of APIs to call rather than including your logic in the client.
Security - Whatever runs on the client can be fully read by the client. No matter how much you minify, compress, encrypt everything a resourceful person will always be able to do whatever he wants with your code
I did not mark pro/con on each point on purpose because it is up to you to decide which it is.
This list could go on and on, I didn't want to think about more points because it is very subjective, and in the end it depends on the developer and the application.
I personally tend to choose "client making ajax requests" approach or blend of both - pre-render something on the server and client takes care of rest. Be careful with the latter though as it will break your automated tests, IDE integration etc. if not implemented correctly.
Last note - You should always do crucial validations on the server. Never rely on data from client.
Hi I am developing a widget module in my existing Angular 1 based UI project. This widget is supposed to contain real time information.
As per my design, I want to send html view to client from node server(maybe using express js) when the first request is made. But as the data needs to be real time, I cant afford to send the complete html every minute(will be duplicate template transfer each time).
So is it possible that I send a template to client along with a set of java-script functions so that when ever client wants that data to be refreshed, he will just invoke the sent javascript function and internally my javascript function will make a rest call, get the json response from server and again repopulate the html sent initially.
This way I am planning to have initial rendering at server side and subsequent rendering at client using the logic provided by server. Here client will not be aware of which widget it is rendering and what functionalities it has. All those will be controlled by js sent from server.
Please do let me know how to achieve this as I find ejs not serving this purpose. With ejs, I need to have all logic to server side only. Whereas I plan to transfer logic from server to client at run time.
Also if my design is having some serious problems, do suggest some other alternatives. Thanks
Angular1 is not server side rendering friendly as it needs browser DOM. Use of any templating engines wouldnt help either as the html generated by them are not picked up by the angular app.
Use a phantomjs headless browser instance to generate html by running ur angular1 app code and then angular will run in client side when scripts have loaded.
I would recommend switching to Angular2 or React as they are server side rendering friendly
I'm working on a Parse web app and have run into some problems using the backbone.js based client side javascript sdk. I noticed the way I have things set up, the client can view all of my source code by simply using the dev tools to view source files and can also run code against the database (within the limits of the ACL's I've set). I've started working on rebuilding the app in cloud code using the Express.js module Parse provides so that all of my code is stored server side, but I was wondering how those using client side frameworks get around this obvious problem.
That's the issue with client-side code. Assume any code you send to the client is hacked, broken, and tampered with.
With JavaScript, your best bet is to use either Cloud Code and send AJAX or streaming data calls to the server, retrieve the data from the server at runtime (not super secure, but would fool some people), or accept that your code is vulnerable.
I typically work with frameworks in the MVC format, so I only expose a limited subset of the actual model via a REST API. I use both a client-side framework and a server-side framework. Any thing sensitive goes on the server.
I have asked this quesion few days before here and no one answered it.
I had asked it in forum.javascriptMVC.com too and now I have a answer, however I need a a bit more idea.
Question:
I read javascriptMVC's documents and I loved it.
But I don't know how to use it in a large scale project.
I think on the server-side a MVC framework is needed or can help so much. And I've worked with server side PHP frameworks.
I am confused, my understanding of JavascriptMVC projects is that they handle client side events on the browser capture events, execute AJAX requests, manage the responses/data from the server and also show them to user in a graphical interface.
I know that in PHP MVC projects we also have controllers (and actions) that any of them is a separate page with a single entry point, my point is that these pages are whole HTTP requests.
I think the combination of these two frameworks would be in a form of a single or few heavy files (including js , css , imgs etc) that loads and managed by another Javascript libary such as steal.js.
Now user can work with site and its actions (as events) that result in running js functions that may change something in the UI or cause a AJAX request, as in Yahoo Mail where most things happens in one page.
So how will this affect the design of controllers and actions in PHP ? I mean normally in PHP MVC frameworks a lot of controllers and actions means a lot of pages. I think because of AJAX the number of controllers and actions should be actually less. I also think because of JMVC most controllers (and actions) should turn to AJAX responders, however how are layouts and views to be handled in this context?
Finally
I want to know about different aspects of using this method(JMVC+MVC). (I am using Yii as my server-side MVC framework and JavascriptMVC as my client-side MVC).
I also want to know about management of data on the client-side.
I would like to understand how AJAX and web-sockets could be used, where we can use AJAX and where we can use websockets?.
I want to understand about local-storage how we can use it for simulated page data management and maybe caching, how we can cache data coming from server as JSON in a form of a page? I am working on a very large project and I want to build its foundation very strong.
Say that you jave a JMVC framework where
The model gets data from the server using AJAX request - expecting JSON results.
The view does not rely on the server, for more that providing the raw HTML.
The Controllers do not rely on the server, for more that serving the JS files.
Essentially you use the server what it "should" be used for, data storage and processing, while you let your client browser handle all the tedious stuff.
Now, lets see how to define a server-side framework. As I see it we have several options, all of them fairly similar, albeit somewhat different (all returning someing in JSON format):
A fully fledged MVC such as cakePHP
Custom implementation
WebService implementation
Personally I would use a WebService, and I already have. Or rather, I used a WebSocket based JSON-RPC WebService.
Using a fully fledged MVC will have it's drawbacks in maintainability and, not insignificantly, server load. But it is very possible, just implement a view which formats the page as JSON...
Making a JMVC client does not, in my view, mean that it cannot request new HTML from the server. But it does mean that that requested HTML should be free of data, other than meta-data the Java-View needs to know where to put data recieved from, for example, the WebService.
So a main page in the JMVC could just contain a single
<div id=content></div>
and menu clicks can fetch a subpage from the server and load the content into content. Then that loaded content can contain some more javascript which starts WebService requests to get data from the server, to display in the empty placefolders it in turn contains.
First check https://stackoverflow.com/a/4458566/718224 after that you can move forward.
Try this (from https://stackoverflow.com/a/8424768/718224)
No, you don't need to use it server-side, but it will help with organization / separation of application and business logic. Depending on the scale of your application, that could help tremendously in the future.
The key is just making sure you organize your backend code well, otherwise you will end up with a monolithic and/or difficult-to-maintain codebase.
Server-side views would contain your HTML and any JavaScript that may or may not make requests to the server. This assumes that you are actually using PHP to build the pages that a user navigates to.
If you have a static html page that builds itself using AJAX requests, then you may not need to use server-side views at all. Your controllers would more than likely be outputting JSON data. If this is the case, it doesn't make models and controllers any less useful.
Try this (from https://stackoverflow.com/a/8424760/718224)
If you are using any of the major PHP frameworks (CakePHP, Code Igniter, Symfony, etc.) then you ARE using MVC already. If your server side logic is more complex than just a few really simple scripts than you probably should be using one of those frameworks listed, using MVC on the server and the client.
Many (most?) larger web apps being built today are moving towards using an MVC framework for both client-side and server-side application code. It's a fantastic pattern for separating concerns for many large applications, especially request/response server apps and event-driven browser apps.
Try this (from https://stackoverflow.com/a/8427063/718224)
Backbone.js connects your application over a RESTful JSON interface. I honestly find that it works wonderfully in conjunction with the MVC framework. If you build a RESTful API, you can let you server manage CRUD updates quite easily. All your server side code will be responsible is saving and sending back JSON objects to Backbone.js. Then let most of your logic and magic happen within the Backbone.js framework.
Try this (from https://stackoverflow.com/a/8078282/718224)
First, a client-side MVC framework like Backbone isn't just for single-paged apps. You can also use it to add some rich interaction to one or many views of a more traditional app. They simply provide structure and data abstractions on the client.
Next, these client-side frameworks are designed specifically to work with your back-end MVC frameworks. Backbone.js (since you tagged it specifically) models and collections work with REST services. They will talk via GET/POST/PUT/DELETE verbs and will ultimately communicate with your controllers on the back-end when they make asynchronous requests.
In the case of Backbone, it talks JSON instead of HTML. In the case of Rails, this is really easily handled in the controller. If the request is an HTML one, then you return a view as HTML. If it is a JSON request (*.json or Content-type) then the controller returns a JSON representation of the data. I am assuming that it is as easy in Django as it is in Rails to have the same controller respond to multiple content requests (HTML, XML, JSON, etc)
may this help you.
client side web apps and rich client side web pages often use jmvc backbones and etc. and with that kind if js libraries and HTML5 technologies like webstorage you can have a more applocation like websites that all things happens in client side like templating management and etc. and just we have ajax request/response to servers to get/set data or update status. and abput first section they are right a jmvc site are more like a single pages websites. ie hotmail yahoo , etc.