Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I'm trying to understand this concept better. Is the whole point of server side programming is to allow us to communicate with others? Whether it is to get new ideas or to get data that can't be stored locally on the client because it would be way too much information?
There are several typical software architectures:
Non-networked application (does not communicate, client-only)
Server-client application (has typically one or more central servers, and multiple clients that contact the server(s))
Peer-to-peer application (only has clients that communicate with each other).
Here, client is typically the part of the application that is executing on the user's computer, which the user is interacting with. Server is defined as the part of the application that user is not interacting directly, and is not on his computer but somewhere else. This separation can be for any of a number of reasons: data size, data security, data availability, or simply coordination.
For example, when you go to Google on your web browser, the web browser is a client. Google is the server. Your computer does not know where everything on the Web is; but Google has a pretty good idea.
For another example, if you play MMORPGs like World of Warcraft, your game is the client, and Blizzard's computers are the server; you tell the server what you are doing, and the server tells you the results, just like a pen-and-paper gamemaster. Without the server, you couldn't know what everyone else is doing.
Or, if you want to consult the atomic clock at the U.S. Naval Observatory, again, you are the client, the clock is the server; you contact it because, obviously, you don't know the correct time, and it does.
Now, for example, you might say that server might not be needed in some cases. For example, in the MMORPG case, couldn't the players contact each other directly? The first problem is discoverability: how would they find each other on the Internet? There has to be some central location to tell everyone everyone else's address. But if that is all the server did, you would have to contact all of the online players (and there are a lot of them) to ask them where they are, and if they are on the same map ask them the same question very very often; your internet connection would not be able to do it. There is also security to consider: a server makes sure (or should make sure) that you are not teleporting around on the map by changing the game's code and telling other player bogus values. For example, if client was responsible for remembering how much gold a player has, it would be trivial to become very rich very quickly: just lie about it to others.
When you go to a website on the internet, your browser is the interpreter that reads HTML/CSS/JavaScript. To read these, your browser must first download the code, then interpret it, then display it to you. Since your web-browser downloads the code, it is really easy for you to see it. (as seen below).
This is great for small projects like blogs, informational websites, project-pages, etc. But say you worked really hard on a big project, and you don't want people to see your code. In client-side programming, the webbrowser reads code, and displays it. If you right click and save a static (HTML, CSS, JavaScript only) website, you'll be able to view it even if you shut off your internet. In server side programming, your web-browser can't read the code because the code will not be the usual HTML/CSS/JavaScript. Since your web-browser can't read the code, it looks to the server (which is a giant computer in a data center far, far away). The server does everything for the web browser, and just returns results. The web browser has the results, but doesn't know how the server processed them, so it displays the results, but doesn't display the code behind it.
This is great because for one, all your code logic is happening privately, which is essential for security and privacy. And, it's happening really fast. Since the server is some huge computer that is much much faster than yours, all your logic for your website is processed really quickly. Also, you get to communicate with databases, and store data, whereas in client-side programming, everything is happening on your machine and your machine only. Basically your code gets the ability to remember.
In essence, you would use client-side programming for information, styling, and small projects. Client-side is usually referred to as front-end development because it's what the user see's (the front). Back-end development (server-side) is the background logic, and is everything that happens behind the scenes, which the user doesn't, and shouldn't see. If you were making some big website, and you had user accounts in it, you can't just store their user/pass in a javascript variable because a) everyone would be able to see the code, and thus, the user info and b) their user/pass would be gone as soon as they closed the page. Server-side communication opens a bunch of more doors for us.
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 2 years ago.
Improve this question
I am a new programmer and I saw that Google is written in python. I know that HTML, CSS, and JS are used to make websites, so how is python "linked" to this. This is probably a very basic question but I am new to all this.
So your code in browser is called front-end (FE). Sometimes it's all you need. However, sometimes you need to store some data on the server and/or retrieve it from there. That is where back-end (BE) comes into play.
BE is basically an app on some computer (maybe a server, maybe a Raspberry Pi, anything really) that listens to requests from the network. Let's say your code needs some data from the server. Your code on the front end makes an AJAX request to the network address of this server on some specific port. The BE, which may be written in Python, or any other language, receives the request and does something with it.
It can fetch data from the DB or anything really. Then it send a response to your FE back, sending some data, or confirmation that everything was done successfully, or an error if something went wrong.
Python is used for backend development. Backend is the part of your website that runs on your server, not browser. Backend is used for authentication and communicating with database and many more. There are some popular frameworks in python like django and flask.
Google in front of you is called front end which is written in HTML, CSS, and JS and usually interpreted by browsers. In the end, HTML, CSS, and JS are all codes, thus, string (or binary).
Python is used to generate those strings, the codes, in back end.
According to the Mozilla Developer Network (MDN),
HTML — Structuring the web
HTML is the language that we use to structure the different parts of our content and define what their meaning or purpose is. This topic teaches HTML in detail.
CSS — Styling the web
CSS is the language that we can use to style and layout our web content, as well as adding behavior like animation. This topic provides comprehensive coverage of CSS.
JavaScript — Dynamic client-side scripting
JavaScript is the scripting language used to add dynamic functionality to web pages. This topic teaches all the essentials needed to become comfortable with writing and understanding JavaScript.
Below is where you will find how Python is linked to HTML, CSS, and JS.
Server-side website programming
Even if you are concentrating on client-side web development, it is still useful to know how servers and server-side code features work. This topic provides a general introduction to how the server-side works and detailed tutorials showing how to build up a server-side app using two popular frameworks: Django (Python) and Express (Node.js).
(Ref.: https://developer.mozilla.org/en-US/docs/Learn)
Below, you can read more about
what clients and servers are,
how they are linked, and
how and what the clients request to the servers and the servers respond to the clients
Some of the useful keywords are HTTP verbs (HTTP request methods), Uniform Resource Identifier (URI), and HTTP status code.
An article about Back-End Web Architecture from Codecademy
Note: As someone who just started programming, it could be really overwhelming to look for satisfying/precise answers across the web. You could also start from some reliable learning sources and search for the keywords to get a specific result. Happy learning!
The old way to to do this is with cgi-bin, which is an interface between the web-server and a program installed on the same machine.
When a user requests a static page, the web-server returns the contents a file, with some headers prefixed. cgi-bin allows for dynamic pages. Here the web-server runs a local program, passing it the URL and any headers from the client (web-browser). The program then generates the headers and body of the reply, and the web-server passes them back to the client. The program then exits.
The program can be written in any language. Perl was traditional, however Python or a compiled program is frequently used nowadays.
It was common to have cgi-bin at the start of URL to denote this to the server, but it isn't really needed - the server can be told that any specific (or all) URLs are to be fetched via cgi-bin.
So, suppose there was a game which consisted of a website, and a client that you can launch from said website. I've looked a bit and a relatable example would be Habbo Hotel.
What I'm asking is, what are all the different parts that would make such a game work: for the website part, I'd imagine a server, a database, and some HTML, CSS and PhP coding would be required, but how would the client side operate?
More specifically, how would the client-to-server (and vice versa) real-time communications happen?
Suppose the client be coded in C, how would the integration of C into a (I suppose PhP-framed) browser window be executed?
Note that the client is never downloaded on the user's PC, so where would it reside?
I'm sorry if these are a lot of questions, if the answers were to be too tedious to compose, feel free to just leave some documentation or tutorials (which I've looked for but haven't really been able to find), I'll happily read them on my own. Thanks in advance.
On one side your question is too broad but on the other side I can give you some pointers of how to do this in a modern way:
don't have a client, just a page in a browser
use HTML5 canvas, you may also want to look into SPA (single page application)
connect via websocket, there are HTML5 javascript implementations and PHP or node.js for the server-side
best is, use node.js on the server, PHP would be way too cumbersome
via websocket, send and receive JSON objects
host node.js on its native platform (Linux)
you may want to look into phaser as an HTML5 client-side canvas rendering framework, but it lacks many functionality and is mainly oriented towards twitch-based action games, which don't work well with this architecture because of lag
this will lead you to one conclusion: javascript is at the center of this system. you'll encounter several roadblocks, such as:
security on websockets with SSL for login
avoid SSL for real-time data (above 1 Hz)
UI on the client inside the canvas is not easy to implement, you'll have to re-invent the wheel or find a UI library for that
expect lag, the network code will take some 20%-30% overhead in respect to native C/C# code using TCP/IP or UDP (Lidgren?) and protobuf (Lidgren+protobuf) is what high-frequency AAA titles use (MMORPG or FPS alike)
From the questions you asked I sense a great lack of understanding and knowledge about the field. I guess you'll have to study some 6-12+ months beforehand. This is what I recommend, because if you start right away you'll make a lot of errors and waste your time. If above are any names you don't know about, search them and study them well. And don't start to code, there is a very steep learning curve ahead of you!
EDIT: more about server-side
If you want to implement an action-based interactive game (like an FPS or 2D shooter) I have to tell you this.
You may want to look into Unity 3D, using directly TCP/IP connections and binary messages (no HTTP, no websocket, instead protobuf).
C# (client-side) and node.js (server-side) are a good combination. For horizontal scaling you may want to look into cloud computing, docker, provisioning and a lot of server security.
But this is hostile terrain, it leads you into DevOps territory, which is way off game development. More like an architect's job. Imagine that 3-tier system (client + server + database) has a bottleneck on the server.
You want to spawn more nodes to handle more clients. This is what EVERY lobby-based game does (LoL, Overwatch, WoT, WoW instances, and so on) and what you do for partitioned maps (e.G. the "maps" in LOTRO, RIFT, many more MMORPGS). Also, to mirror (which means multiple instances of the same map to accomodate an overpopulated crowd).
To have this kind of horizontal scaling your servers must go online/offline on their own without you clicking around on command and control (e.G. puppet and similar software).
While this is the ultimate approach, it also has the most steep learning curve, especially because of security (advert DDOS, flooding, slow-loris, fake clients, and the list goes on). A new node must be "provisioned" on the fly (e.G. cloud-config) before it attaches to the cluster and goes online, so there's a whole new world of pain and learning.
The center-piece of such an elastic cloud-based server system is SSO (single sign-on).
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 7 years ago.
Improve this question
when i use asp.net to coding for website. Asp.net in server call sql server (ado.net, linq or entities framework) and get back data, send for clientside. i use some control as girdview to show data. actually, i do web optimization ( sql server - store procedure, create index, partition => faster, acceleration for get data. Website: UI simple, do not use too many effects)
but why in client-side, when server return data for client, many people always are going to use script (such as javascript, jquery, node js, angular js, bootstrap, react, google o/i....) to show in webpage.
so, it slower or faster when we use girdview?
And when User (people in clientsite) stop scrip in browser, it's mean, Manufacturers allow user or offer to stop script on browser in clientside., so why do we user them ( *.js), when User can stop script?
Even many people use asp.net (new version - 2013) in server, they also use script in there. so asp.net + script in server is faster or slow when we only use asp.net?
please, help me answer.
(I'm apologize because my English is not good.)
Thank you so much.
In the early years of Web development, Javascript on the client side provided for considerable enhancement of the client's "user experience" that static HTML delivered from the server did not. This includes such things as the enabling or disabling of certain interface features based on user input, the appearance or hiding of certain regions of a display based on user input, or combination of other pieces of data.
As web development evolved, the need for even more robust client-side interaction with back-end web servers became evident, and the "frameworks" you mentioned all work in various ways to improve the design, responsiveness, and behavior of a web-based application in ways beyond just enabling or disabling a button. This amounts to complex data binding, callbacks to web services, reducing server round-trips, and creating rich client interfaces, to name only a few.
They're all tools, each with their own role, each working to make web applications a bit more robust than those of the generation before them.
If I understand your question right, the answer comes down to speed and preference.
Firstly, if you disable client-side javascript, your asp.net controls aren't going to really work anyway. You'll find few places that still disable this so it's not really a concern people have anymore.
Secondly, it comes down to where you want to focus development effort and what kind of developers you have. If you have a lot of people used to working backend (C#) and want to stay there, then using asp.net controls and the like make development easier.
If you have javascript developers or people who want to use it, then you have more options that allow you to more decouple your server-side code from your front-end code. This can work out well for maintenance purposes.
The real point is that if you can utilize ajax (http://www.w3schools.com/ajax/default.asp) within your web application, you can make it a lot more responsive. ASP.NET Controls can often cause your page to refresh and cause unnecessary server-side computing to get the data and re-render the entire page (or partial page with asp.net mvc). Using new technologies like angular and others you listed, you can focus data computation and network traffic only on what's important.
For example, if you need a table to change what data is loaded, you can make an ajax request JUST for the data you need to load and then just render that portion on the client.
First of all, every "script" you mentioned (jQuery, AngularJS, Bootstrap, React) is a library written in JavaScript. Except node, which isn't even front-end. And I'm not sure what did you mean by google o/i... JavaScript is currently the only language which works in all browsers.
Initial purpose of JavaScript was to check form values before sending data to servers. It quickly evolved past that, although the usage was throttled by browser adoption, which is still a problem today.
Nowadays we can use JavaScript to render whole webpages. First when opening the page, it can help with rendering, meaning that server doesn't have to do all the work, but can just send plain data, usually in JSON. It's also used to add content to page later, without reloading the page (AJAX). Most well-known examples are real-time chat systems, like the one on facebook. This greatly improves user experience, I can't imagine how terrible it would be if whole page would reload to display a single new message.
Although user can disable JavaScript in their browsers and this would mean the page probably won't work, except if there is fallback design for such cases, I do not know why would someone disable it. And to be honest, probably most of the regular users don't even know this can be done and where is the setting to disable JavaScript.
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
On my website users have some images stored. I want to build a system where they can edit those images on website and save them. Edits are very basic like rotate, crop, enhance brightness add filters etc. I'm trying to figure out how I can implement this.
My understanding so far is that there are multiple ways in which I can do this. I can write all my image editing code(using libraries) on server side and then call this service API from my website.
I can also make all the changes on client side. I found PicMonkey library which would let me do it (it's flash based though so I don't really want to use it.)
I also checked how flickr does it, they use this library https://developers.aviary.com/ which lets them do all the client side edits.
I'd like to know more about using these client side javascript libraries ( such as aviary ) what are the pros and cons of using them vs server side edits. What service component I need to write, if at all if I'm using something like Avairy. More specifically, do I send image to server for modification or do I modify it on HTML canvas first and then send the modified image to server to save it.
Today browsers have become very strong, so you should probably do the basic edits on the client side itself, so there is not too much burden on your server and also utilize the processing power of the client.
You have few libraries for doing this on the client side
1) https://developers.aviary.com/
2) http://camanjs.com/
3) http://www.pixastic.com/editor-test/
but as you say,
Edits are very basic like rotate, crop, enhance brightness add
filters etc
You can create your own code for these kind of edits, there are lot of tutorials out there, few I found useful are here,
http://www.html5canvastutorials.com/advanced/html5-canvas-grayscale-image-colors-tutorial/
http://www.williammalone.com/articles/create-html5-canvas-javascript-drawing-app/
there are few things which if you try to do on the client side they will crash your app completely, for ex. a photo bucket tool.
Here is a tutorial as well for creating a photo bucket tool which uses a flood fill algorithm.
http://www.williammalone.com/articles/html5-canvas-javascript-paint-bucket-tool/
But you should keep these kind of heavy algorithms on your server so your app doesn't crash.
If you are good in server side programming my spontaneuos thought was "Why not using the raw PHP GD library or the PHP add-on imagemagick?"
http://www.imagemagick.org/
Photo editing in php
It depends on what server load you are expecting - up to 10 people simultaneously working on it would be OK, but 100 to 1000 people at once? For the second case a client side editing is really the better option, or your server will overload. Naeem-Shaikh gave you some links for that.
I recommed to make it client side.
JavaScript will give you everything you need for basic editing and you ll be able to organize your code in a clean way.
A client side app won t force you to deal with XHR, wait, send, http, all of those you have to master for the same server side app to always display the current draft. Server side you will need servers with available ressources to do the job.
User will be able to continue editing even if they lost connection, and trust me this alone should be enough of a pro to do it client side. Also the editing will feel more fluid.
So why would even hesitate ? Well, server side also has advantages.
There are many (10+) librairies tested, documented, enhanced ready to be used. Perhaps you don t have time or energy to learn JavaScript. Maybe in the future, you ll want to expand your app with new, heavy, editing features that takes more CPU than client have, ...
Assume we have a client-server application communicating over the net, with client side written in javascript (so pretty much opensource). Let's say for example that we want to run multiplayer in-browser game and gather some revenue from ads. We want to stay in business, so we keep secured the server part, which handles most of the logic, and we accept that frontend/UI handling client is thrown into the wild and might be messed with by anyone.
Question is: how to detect and prevent the situation where someone copies all public facing content of web app, including JS client, puts it on his/her own server with his/her own advertisements, potentially malware etc, while the 'hijacked' client still talks to our original server?
Or perhaps that's just silly and there is some obvious reason why such behaviour would not work (that might be why I haven't found anyone mentioning it)? I'm feeling like I'm missing something there, but nothing in my experience so far tells me that hypothetical situation from the paragraph above would not be possible or even profitable for a highjacker.
You can't really prevent people from using your client to connect to their own server. It's been done with MMORPGS for a long time, even when they have compiled fat clients. Of course, in those cases, people had to re-write the server code from scratch.
To prevent people from blocking your ads, you could set a timestamp per client whenever you serve an ad. If the client is still connected but hasn't requested a new ad from the server for some time, all kinds of things could go wrong - for example, your server might modify dice rolls against that player so he'd die a horrible death on all but the easiest monsters. This is in your server code, so can't be messed with, and the guy who copied your code would run out of a playerbase quite quickly.
The important thing about this approach is to NOT give the client a clue that and why it's on the rogue list. Not knowing what to fix makes it much harder for the attacker to "fix" the changed code.
I will turn my comment into an answer. The request has a referrer, you validate against the referrer. That is what happens when you request api keys from different services.