So I have an isomorphic node based application running (with react). The page is rendered on server first and then the client JS takes over. I am having the data populate first on server (via an api endpoint) and then the same api is being accessed on client side. On the server side I am using "request" library and on the client-side I am using AJAX for fetching the data. I observe that there is duplication in the code I am writing for making api calls on server and client side. Is there a way I can unify this (via some library)?
Your best bet would just be to set up your build pipelines properly to allow you to share the code. You could then have a client, server, and common directory, and tell your build tools (Webpack, Rollup, Browserify, etc., whatever you may be using) to include everything from client and common for the front-end, and common and server for the backend.
There are lots of other ways to deal with it, but that's one of the cleanest. You might also want to take a look at Meteor, which does a lot of what you're talking about for you out-of-the-box (and allows you to use React as a front-end).
Related
My project currently involves several components using either Javascript and Python
Node.js server
Python flask API server
Python data processing scripts (numpy, pandas, etc)
React.js web client
React Native mobile client
These components share several common config values such as a database connection URI string postgresql://admin:password#localhost:5432/foobar used by server-side components and the API server url https://api.example.com/v1 used by client-side components.
Question: Is there a best practice for sharing config files across components that uses different languages?
For example,
Should all components (server and client side) access the same config file? If so, which format should it be in, JSON, YAML, etc?
Should all components share a common config file (where only common config values are stored in), but also have a second config file specific to that component?
Should all server side components share the same config file, while client side components have their own individual config files?
Thank you for your advices :)
I’d recommend using TOML. It’s supported by all major languages and allows the use of comments which JSON does not.
In my mind there are two main approaches you'll see in the wild.
Config file. As nc. mentioned, you could make a TOML file that all of the different tools and applications can access. This is nice since there is only one source of truth and TOML is very human readable. The cons are having to find a TOML parser for your language (imo not that difficult), and making sure the file is there when a script/service/whatever expects it. I've gone this route and its not that bad, you can even put the file in "the cloud" (NAS, shared data store, folder with broad read permissions), and have it easily accessible if you need to spin up more than one instance of a service.
Environment variables. I've liked this approach lately as it is always the minimal amount of config you could possibly do and pretty much any language has facilities for accessing environment variables. Also, you don't have possibly sensitive information hanging around in a publicly accessible plain text file.
For python you would call os.environ[MY_CONFIG_NAME] and presto, you have the config info.
Both approaches are common and have plenty of support in almost every language.
As far as client, server separation. I tend to make my clients as "dumb" as possible and my servers as "smart" as possible.
I'm currently working on a project that involves parsing through a user-supplied file, doing computations with that data, and visualizing the results using graphing utilities. Right now, I'm stuck with using Python as the back-end because it has scientific libraries unavailable in JavaScript, but I want to move the entire tool to a web server, where I can do much slicker visualizations using D3.js.
The workflow would be something like: obtain the file contents from the browser, execute the Python script with the contents, return jsonified objects of computed values, and plot those objects using D3. I already have the back-end and front-end working by themselves, but want to know: How can I go about bridging the two? From what I've gathered, I need to do something along the lines of launching a server, sending AJAX requests to the server, and retrieving data from the server. But with the number of frameworks out there (Flask, cgi, apache, websockets, etc.), I'm not really sure where to start. This will likely only be a very simple web app with just a file submit page and a data visualization page. Any help is appreciated!
Apache is a web server, flask is a web framework in python, websockets are a protocol, and cgi is something totally different, and none of them help you on the front end.
You could deploy a simple backend in flask or django or pylons or any other python web framework. I like django, but it may be a little heavy for your purpose, flask is a bit more lightweight. You deploy them to a server with a web server installed and use something like apache to distribute.
Then you need a front end and a way of delivering your front end. Flask / Django are both fully capable of doing so in conjunction with a web server, or you could use a static file server like Amazon S3.
On your front end, you need to load D3 and probably some kind of utility like jQuery to load and parse your data from the back end, then use D3 however you like to present it on screen.
Flask is easy to get up and running and is Python based. It works well with REST APIs and data sent by JSON (or JSON API).
This is one solution with which I have some experience and which seems to work well and is not hard to get up and running (and natural to work with Python). I can't tell you whether it is the best solution for your needs, but it should work.
If you are overwhelmed and don't know where to start, you can pick one of the options and google search for a tutorial. With a decent tutorial, you should have an example up and running by the end of the tutorial, and then you will know if you are comfortable working with it and have an idea whether it will meet your needs.
Then you could do a proof-of-concept; make a small app that just handles one small part (the one you are most concerned about handling, perhaps) and write something which will do it.
By then, you can be pretty sure you have a good tool for the purpose (unless you were convinced otherwise by the proof-of-concept -- in which case, try again with another option :-))
I'm starting a project that basically is a single-page app that downloads and shows a bunch of stats (using d3.js). The data layer is Mongo-powered, served through a RESTful API, and the client app will be coded in Ember.js. We want all data to be exchanged through the API, since we also have some mobile apps in the back burner that will hook to the same API.
I'm debating on whether write the API (using Express.js or other server-side MVC framework), or just serve the API use Deployd and not using a server-side framework at all, besides Deployd. I'll provide some hints about the project characteristics:
The main feature is basically a dashboard that shows aggregated stats that are already computed and stored in the Mongo database.
User interaction is minimal, enough only to allow users to customize their dashboards, but users never upload data (other that customization preferences).
Most of the app is a lot of d3.js to create and render a bunch of graphs, which can customized in many ways.
It requires a very rich and responsive user interface.
I proposed skipping completely the server-side framework, and simply go with a bunch of static HTML+CSS and do all the heavy lifting with a client-side MVC such as Ember.js. Since all data download and upload can be handled by Deployd, a pure static site would load much faster and is also easier to scale. Also, (I think) all user-related data and validation can be done with Deployd itself.
The thing is, some of my colleagues had a heart-stroke when I mentioned this idea. So I'd like a reality check: do I really need a server-side framework besides Deployd to cope with problems I cannot foresee yet? Are the benefits of having a pure static site a good enough tradeoff versus having, say, Express.js just in case?
I haven't worked with Deployd before, but from a quick skim of its docs, it is a server-side framework. It accepts requests and respond with json. It's just oriented to APIs and json and neglects html, unlike, say, default Ruby on Rails.
The main issues I can think of that might arise due to a lack of a traditional server-side framework are things like auth, CORS, and XSS/CSRF/other common security issues. You could cater for this through Deployd if it's built in or easily added, but that may be difficult.
Looking further into Deployd's docs, I see there's a guide for users and CORS. I can't find anything about XSS or CSRF.
I'm thinking of switching from PHP to using Node.js for developing my website. However, after researching Node.js for a little while, I can't seem to find exactly how to write a webpage with Node. I see that you use response.write() in Node to write html to your webpage, but that seems like a tedious thing to do, having your entire webpage as a string literal in your node file. How does web development work in Node as opposed to PHP's method of embedding the script into the HTML file?
You don't necessarily need to use response.write for each line of the view, you can use template engines as well. Search for "node.js template engines". At first impression it could seem tedious, but a similar approach prevents you from writing bad code.
PHP is a scripting language, node is a platform built on javascript.
To start web development using node.js, at first you have to understand what makes node different. Node gives you a way to make async calls to your database (which is a very simplified explanation), which you can then wrap in nice html and send (route) it to the browser. Alternatively, you can use something like angular.js in the frontend and use node.js to make db requests and response which is picked up by angular.js which updates the front html. If you like the idea of Single page app with async calls to fetch data, use node with angular. The tutorial that I like is https://scotch.io/tutorials/creating-a-single-page-todo-app-with-node-and-angular Hope this helps!
As others have answered, there exist templating engines for Node. With the current trends in web development, most modern web frameworks encourage the separation of code from the view (or the HTML you deliver to the client). For instance, Ruby's ERB templates, Jinja2 in Python, Handlebars/Jade for Node, and now a lot of modern PHP frameworks support this as well (Zend/Slim).
Another main difference is in how they work and how the languages are designed. PHP is an object oriented language supporting classes, inheritance, member visibility, interfaces, etc. Node.js is Javascript, so using prototypical inheritance.
The communities and ecosystems are different as well. Modern PHP tends to embrace the use of the Composer package manager, and that came after PEAR. However, npm is the official node package manager and it is deeply integrated with the platform. It is trivial to search for new packages and then use them in your projects.
The main architectural difference is that Node is also asynchronous by design, meaning it runs in a single thread and can potentially handle much more connections than PHP on systems with limited memory. When a request comes in to a PHP application, all the services/controllers and everything you defined have to be reinstatiated, you define PHP files and let Apache/Nginx process them. In Node you have a node process which you can proxy outside requests to.
Node.js Provides so many modules to do these things there is framework called express for node.js http://expressjs.com/ You can use a templating engine and create views. some examples are like ejs or jade. It doesnt have to be a string.
PHP is very strongly orientated towards creating web pages from a template, while Node.js is lower-level and broader in scope. A very rough overview of the differences between PHP and Node.js:
In PHP, you'd start a web server (almost certainly Apache), and then put a PHP file in a directory where you want to serve something from. You might use some fancy .htaccess directives to make URLs nicer, etc.
In Node.js you create a script, in which you use the http module to start a web server, and then you supply a callback for whenever a request is made to your server. Deciding which page to respond to the request with, etc, is all your work to do.
In PHP, things like routing a request to a particular PHP file, compression, decoding POST and GET variables, are all done by using Apache - your PHP files are sort of just like templates which Apache runs whenever a request is received. In Node.js, everything, from starting the server to sending HTML, is all done within your Node.js script - you have to do everything.
HTML isn't the first class citizen in Node.js that it is PHP. Generally, in Node.js you are just sending strings to the client. There are plenty of third party templating tools for Node.js - but they will be dependencies, not builtin functions.
Some javascript frameworks like Dust.js claim that they ALSO support server-side rendering (in addition to client side rendering) as well. Can someone explain how does this work? My understanding is that the JS is always executed in the browser runtime.
JavaScript can be run on servers using systems like Node.js.
With regard to Dust.js, a templating engine, it can generate hypertext and HTML on the server and send that content directly to the client's browser. This is typically used to avoid a flash of temporarily empty templates, caused by the browser requiring a split second to populate a view's templates via a framework like Dust.js. The downside is that the page will take slightly longer to load because more work has to be done on the server before sending data to the client.
Check out this question for the pros and cons of server-side rending. One must choose between slow post-processing (requiring the user's browser to do the work) or slow pre-processing (making the server do the work before the user sees anything).
Server side rendering is converting JavaScript into static html and css.
Earlier JS tended to load last to optimise website performance.
But the problem was it affected SEO.
So server side rendering became the solution to resolve this issue.
The 3 main renders methods are:
Client Side Rendering (CSR)
Is the default rendering process of modern frontend frameworks like ReactJS, the server just returns an almost empty index.html file, and then the user browser using Javascript loads and builds everything.
Server Side Rendering (SSR):
Refers to the process of generating in the server, the HTML content, on-demand for each request.
Usually, you’ll accomplish this by setting up a server running something like Express or Next.js (which use NodeJS) that renders your React app with each request — just as with a more traditional PHP or Rails based website.
Static Site Generator (SSG):
Both Server Side Rendering and Static Site Generator involve generating HTML for each of your site’s URLs. The difference is that Static rendering happens once at build time, while server rendering happens on-demand, as the user requests each file.
With static rendering, you need to generate responses for every possible request ahead of time. But what if you’re building something where you can’t predict all possible requests, like a search page? Or what if you have a lot of user generated content, and the response changes on every request? In that case, you’ll need Server Side Rendering.
*** So which should you use? ***
It depends.
if SEO is irrelevant — e.g. an app that lives behind a login screen — then CSR is fine and you just need something like ReactJS
If you need a good SEO:
a) If you can predict the content (to generate it in build time) then you need SSG and should choose something like NextJS
b) If you can’t predict the content/possible request, the server will need to generate the pages on demand, so you need SSR and should choose something like NextJS.
Note: NextJS allows you to selectively mix in the same project the 3 main rendering forms. They are also other good solutions like Gatsby on the market.
Server-Side Rendering (SSR) is executing JavaScript [SPA application] on the server-side.
Opposite to Client-Side Rendering when JavaScript is executed on the client-side.
Server-Side Rendering is a relatively new technology/therm that allows SPA frameworks like React or Angular to become more SEO-friendly.
Technology is rather inefficient, because of additional work put on the server.
Instead, of creating SPA (single-page application) and then executing it on the server, someone should consider creating the multi-page application in the first place.
SSR term is somehow ambiguous and confusing as some people use it referring to traditional multi-page websites like those built on Wordpress, for example, or any PHP or Java backends where HTML pages are generated by the server, and some use it only for SPA rendered on the server.
The latter, IMHO, is "more correct" as it produces less confusion.