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).
Related
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 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 8 years ago.
Improve this question
I want to make a poll for my website.The poll I want should look like the poll on http://www.premierleague.com/en-gb.html.I am not sure if I should use PHP,Javascript or etc to make a poll.Can anyone help me in this? Thanks...
You're going to need to create a form and receive the data on the server side using PHP. Then you're going to put that information into a database.
I hope I do not come across as too mean but, the decision on which language to use is pretty simple when compared to actually coding it. I'm betting you are not entirely experienced with web-based programming languages. I would strongly suggest you look for some pre-made scripts in the interim:
Here is a simple tutorial on creating polls: http://code.tutsplus.com/articles/creating-a-web-poll-with-php--net-14257
If you are OK with the idea of using a CMS, Here is a WordPress Plugin that should do the trick: http://code.tutsplus.com/articles/creating-a-web-poll-with-php--net-14257
Otherwise, it's important to understand the flow of data:
Display the poll to the end user (use HTML forms and CSS to style)
Client submits data (either built in submit functionality or Ajax)
Server Receives data and stores it into database (php)
Page is re-loaded and results are displayed (read with php, then displayed using html/css)
In other words, you are going to use many of the available languages and tools to create a polling script.
Start with a pre-built one and look up other resources to learn to make/customize your own.
If you need to save poll values, than PHP/MySql + JS for live effects, animations + CSS for styling.
Create database tables.
Create HTML form.
Style form to fit your needs (maybe jQuery UI).
Use Ajax to submit form.
Use PHP to gather information form user, validate it and save to database.
Reload user poll view to see changes.
Sell this masterpiece to Google/MS/Apple (or any other company).
Take big cup of hot chocolate.
Rule rest of the world.
Good luck.
Yes, you can use PHP or any server side scripting for validating, storing, processing poll, and use HTML/CSS/JS for client side, this is the main whole web page. You should also have DBMS (Database Management System) like mySQL, msSQL, etc., for storing poll answers.
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 9 years ago.
Improve this question
There are a lots of new frameworks, technologies coming up. And it's becoming so hard to follow up all of them. One of the thing that confuses me is client side frameworks. I heard that Angularjs,Backbone,Knockout,jsviews,knockback, SPA... are the most popular right now.But I can't understand how does the security concept applies? If we take an example of querying a table form database it's now possible to make queries from client side database, by specifying table name and fields and etc... So if it works that way, than everyone else can write another query and get all other information. I am pretty sure that I am missing something very important here, and it doesn't click my mind. So please can anybody explain me where can I start learning those primitives.
I really appreciate, and I am really eager to learn but I am searching it wrong way I guess.
Whatever the framework used, the security matter will still the same, and very similar to mobile apps:
which data can you afford to be handled in an untrusted environnement
which treatment can be applied in an untrusted environnement
By "untrusted environnement" I mean the browser itself. You have to understand that any code executed in the browser can be corrupted by a medium/good JS developper.
Data security suffer the same threat: giving access to data from your client means that you do not control anymore who is using it.
Once you've dealt with this simple matter, it became easier to decide what must stay on server side, and what can be deported to client.
That said, there are various ways to make data/algorithm steal more difficult:
Obfuscation that comes with minification
Double data validation (forms for example): both client and server side
Authentication protocols, like OAuth
Binary over webSockets, instead of plain json and ajax call...
The browser sandbox imposes some limitations, but mainly to protect the local computer from damages due to malicious JS code. It does not protect your code nor your data from being seen and manipulated by the user itself.
I am using angular for some of my projects. I haven't used other frameworks , but in angular you usually consume an API to get the data. You don't query your database directly. So, the responsability of securing your data is more in you API (Backend) than in your angular client.
You can use OAUTH, or other security method that you want to make your api safe.
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 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.