Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
A colleague of mine at work proposed a challenge the other day. The problem: Solve one of our common problems human resource management ie. assigning ppl to projects. The one caveat was we had to do so using a technology that neither of us had used. So we set out building this project using the MEAN stack. Its been a fun learning experience thus far, but it has me wondering.
At what point do we decide that server side MVC rendering trumps client side MVC rendering. Most of the customers we work with already have an instance of IIS running somewhere, so we would using use asp.net MVC, which obviously will do most of the HTML rendering on the server side. Even when using angular in combination with node the HTML rendering is server side.
But if we couple angular with IIS we can do full client side HTML rendering. At what point have others made the decision to use Client vs Server HTML Rendering? Are there concerns of slowness on mobile platforms?
What does the community say are the pros and cons of each scenario?
Thanks for the thoughts!
I've gone with a pure separation between the client and server. My server stack relies on PHP (using PDO and ph-pass) and MySQL for persistence. The major advantage in my view is the complete decoupling of the view/presentation from the server side logic. It is absolutely clear in my application that the PHP generates data and returns it formatted as JSON and accepts JSON formatted parameters but has nothing to do with the display (it just creates data structures that are easily parsed on the front-end).
On the front end I'm using AngularJS, UI Bootstrap (angular wrapper for bootstrap), Google Maps V3 Javascript api (wrapped in an angular directive), and D3js (again wrapped in an angular directive).
The few sites I've worked on haven't really encountered any issues on mobile... even when doing some pretty heavy data processing on the front end... I do all my filtering and some aggregation in the client side code for displaying filterable markers on a map and to draw some charts. Unfortunately the app I'm currently referring to is about a week from being made live so I can't show a link ATM.
Here's my main site though, this one isn't dependent on any PHP so all Angular:
http://www.intellectual-tech.com
You can also check out the portfolio sites and http://www.shanklandfinancial.com I did all of these with just AngularJS and no server side code. The site that does rely on a database but is still WIP is http://www.eat-data.org
The longest delay is still in fetching the initial data which is in the 60kb range after gzipping. On mobile the google maps drags things down quite a bit and CSS animation isn't smooth/fast, but everything is still useable.
Another plus is if at some point I decide AngularJS isn't the way to go, or the client wants a native app, the server side code is all entirely re-useable without modification.
The only down side I see really is if the client wants to export the views I don't really have a good means to do that... I've recently used the PHPExcel library to output the data as XLSX files but in terms of charts etc. nothing in my server code is so fancy and would require overhaul if this was required. That said I don't think this is real problem that having printer friendly pages to be "printed to PDF" can't solve.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am developing a Django application for a school project and it is essentially one page that takes user input and another page that responds to the user input by displaying various alerts/data.
The end goal is to have the application launch on a tablet and display the user input page while having the summary data page displayed on the monitor. The issue is that as of now, these two are communicating via localStorage values. Obviously this will need to be changed down the line.
I am extremely new to Django and web dev so I was wondering if this is even a feasible task and what the right approach would be?
In short, yes this is something Django can do.
Fundamentally right now your application is just a client. You need a server to both:
A) use a database to store your data (whatever you currently store in local storage), and
B) share that data with your two clients
Django is a web framework designed to create such servers, so it's a great option. However, Django also requires knowing Python. If you don't know Python, and aren't learning it in a class, you may instead find it easier to use a different tool: Node.js
Node lets you use Javascript the same as other languages (eg. Python). It also has frameworks (eg. instead of Django it has Express.js). But again, if you don't mind Python, Django is a great choice.
Whatever your choice of framework, your first step will be to understand how it sets up "routes" or "endpoints" to talk to your client (you'll also have to learn how to have that client "talk" using fetch or $.ajax).
Once you master that, you can then learn to use a database to store the information you need, and finally you just "connect the dots" between those routes and your database to create your server.
I should warn you though that this is a sizable project, involving several complex technologies (servers, databases, AJAX, etc.) I actually teach a college class on server-side development, so please understand I speak from experience when I say that ... even to make a simple server with a little bit of data ... you'll have to learn a lot (with Django or any other tool).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a few questions which I'd appreciate to have some answers on.
So I've created a backend node server with express & mongo which is running specific tasks on the net and saves it in the database in a loop. I've also added an admin page with express & bootstrap. And that works fine. What I needed then was a frontend page - for this I chose VueJS. I started that project seperate for multiple reasons. I felt that this would be easier to get started, since I didn't have any frontend framework experience before and the backend project was written in typescript and I'd rather use normal es6 JS for now.
Right now - the site has already made some pretty decent progress and is at the point where I need to establish connection with the database and also use some of the already implemented functions in the backend project.
And this created the question:
Should I create new functions and/or create and use API's? Would there be any problem with the mongodb in the form of accessing and writing to it by two different processes? Would there be security issues if I'd create "public" apis from my already existing backend logic? (Haven't written any apis yet.)
Or should I use the time and import the frontend project into the backend (meaning also either translating new to typescript or switching to normal ES6 JS)? Would this be a security risk since I'd rather not have the backend logic in my frontend site.
I appreciate any answer to that!
Thank you :)
This is a question of can you afford to run two servers? separating your front end from your back end is actually a good move considering all things microservices since it allows you to scale these things separately for future purposes. Like your backend needing more resources once you start catering to mobile user as well or once you get more api calls, while your front end server need only serve the ui and assets, nothing more. Though the clear downside is the increase in costs since you do need to run two servers instead of one, something that is difficult when you are just starting out
Should I create new functions and/or create and use API's?
For your backend? Yes. APIs are the way to do things now in the webspace as it future proofs you and allows a more controlled and uniform way to access your backend(everything goes through the api). So if your front end isnt accessing your database through the APIs yet, i suggest you refactor them to do so.
For your concerns about mongo, im pretty sure mongo already has features in place to avoid deadlocks.
As for security of your API, I suggest checking out JWT.
should I use the time and import the frontend project into the backend
should you go this path instead due to cost concerns, i would suggest rewriting one of the codebase to comply with the other for uniformity's sake, though do that at your leisure(we can't have you wasting all your precious time rewriting code that already works just fine). this isnt really that much of a security issue since backend code isnt being sent to the front end for all your users to see
Let me start by saying I've never used Vue. However, whenever I use react, I always make separate projects for the front end and the back end. I find it's 'cleaner' to keep the two separate.
I see no reason for you to transcribe your entire project from typescript. Simply have your frontend make requests to your backend.
If you're looking to brush up on your web security, I recommend you look into the Open Web Application Security Project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Hopefully this question is not off topic, personally I feel like this is a perfectly valid programming question that I have as a programmer looking towards the future.
Guys, I'm failing to understand why I want to involve my websites with client side frameworks like Angular, Backbone, Ember, React, this, that or the other.
The fact of the matter is why learn something like Angular when they're pretty much pulling the rug out from under people and companies who've invested millions into Angular 1.0 in order to make a new framework which they will call angular 2.0?
If I want some basic dom manipulation why learn a framework at all. For instance, on the home page of my movies site www.noobmovies.com you'll notice some pagination, this is entirely done by grabbing JSON passed back from a Django Server View and using the client to parse the Data. Say I need to update a movie etc... why not just pass some data via Ajax and send the response back?
The bottom line is much of what AngularJS and the like does, aims to replace mature frameworks like Django, Ruby on Rails etc... but why make life harder at the moment to jump on these buzzword projects that don't seem to do anything more than what these entrenched frameworks are more than capable of doing at the present?
To me, I've played with React, Angular and Backbone. I don't like having to learn an entire framework to do something I may be better off doing myself. It seems like all of these client side frameworks are not production ready to begin with, change way to frequently and make things harder than they need to be for many mundane tasks.
To me it just seems like everybody coming out of school is like, Dude, I have to build something with Angular to like keep up with the in crowd. I see no reason why Angular projects are any better than Django or Ruby on Rails, in fact for the most part I see many cases of them being worse.
As already mentioned in the comments, of the question, what client / server architectures to use should be considered on a case by case basis and will always have so e kind of personal bias to it.
I cannot speak to the push for client framework as a whole by at my place of business there was a push for client framework for the simple yet important reason of having a clearly defined separation of client and server responsabilities. The server is responsible for only responding to client requests and sending raw data, In our case we use REST. The client is then only responsible for presenting the data to the user.
The power of doing this is because in 5 years or so when the next big client framework comes out that we choose to use not a single line of code would need to be changed on the server side.
To personal preference though I love angular because of the clear seperation the code that handles the DOM manipulation and how clean it is to use HTML to run the directives. Even with the additional Angular markup in the DOM you know exactly what will be rendered.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Similar to this question; When to use JavaScript template engines? but not quite.
Is it practical to make full sites (e.g. skip static HTML and PHP processing and just send JavaScript with HTML templates for client side rendering) in client-side JavaScript with a template engine such as handlebars? Or, are template engines only useful when it comes to re-usable template sections?
You have half of the the answer, which is re-use, but you can get that on the server-side. To me the other half is as follows:
Allow front-end developers to handle all the interactive development in JS and HTML, almost without knowing JS for simple templating needs.
For web applications the UI rendering on the server slows or limits the interactions/experiences one can design, or at least limit performance. Why does the server have to know and understand the User button clicks? The browser is powerful enough to handle the button clicks.
It pairs nicely with REST services. The browser knows how to request the data and determine the user context.
More complex web server side design. State is a very complex thing to manage across clusters and nodes. Not that you can't but why should you? Especially as for most modern web applications (web 2.0 and all that jazz) the whole point is the browser doing more, handling button clicks, sorting data, etc. Guess what all that is user state. So the browser already has a lot. So why distribute that state across a cluster of servers adding latency, dependencies, etc. I have a no HTML in the application server policy.
Change control. When you write PHP and embed HTML snips in everything things end up tightly coupled. It reduces flexibility of use case changes.
Separation of concerns, forcefully. Many developers are tempted to do business logic in the view. Simple templates help reduce the likelihood of this. One could easily construct an argument against all non-templating based approaches, JS or server-side but that is not the question at hand.
If you are going to build a mobile app you want and need services that avoid presentation markup. So never generate HTML in the application server or else your app will only speak one language. People might shout server side MVC will help, but not for off-line, different access patterns, etc.
There are some performance, device detection, 'dumb phone' reasons to generate html server-side, but then write it off of the services which your JS web app use. Let that be the exception. Even better write it in JS on the server-side and re-use the business functions and logic on both.
I use a JavaScript template engine when I make one-page web-apps (with backbone.js for example).
In any other case, I would not use a JavaScript template engine.
The reason for this is, that if I create an application in anything other than JavaScript-only (PHP, Rails etc.), I like having the templates done on the server rather than at the client.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I have a website hosted in justhost.com. So far it is only HTML/CSS/JS done all from scratch. Recently I have been learning about Server Side Java Script (SSJS) using nodejs and I would like to add some JS backend processing to my site. The problem is that justhost.com does not seem to support nodejs applications, so now I am kind of stuck.
Is there a way to keep all the front end of my site (HTML, CSS and front end JS) hosted in justhost.com and then build the backend in nodejs SSJS and keep that part hosted in another service or server and somehow make it all work together?
Right not it is not a commercial application, so I can play around and break things, so I am open to any suggestion.
Thanks in advance.
The complete answer is "probably, but it's complicated" due to restrictions built into the web itself like cross-origin isolation as well as hosting provider restrictions. However, since you are asking this, my suggestion is just host your entire application (server side code, HTML, CSS, browser JS, images, etc) on a node.js hosting service since they all support that and it's trivial to do. No reason to complicate your architecture to stick with a static web host. It takes a handful of lines of "code" in your node app to have a fully functional static web site served along with any custom server-side logic your application may also need. (consider the static middleware bundled with the express.js application server, for example).
I agree with Peter Lyons answer but in case you really want to do this, the way I would do this is to treat your nodejs server as a rest api (or even SOAP api) and your front end server would treat your nodejs server as a database where it would require information from it like backendserver.com/users which would return your front end the users.. Or even better is your front end would have the UI code with the link to backendserver and then they would be loaded from the browser.. That's typically how your set up is handled