We Keep Coding

Reactjs and data on server

I'm new to Javascript frameworks and looking for framework for my new projects. Until now i created simple apps using MVC framework Django with Bootstrap frontend. Thanks framework i got everything in one package with best-practice well know. For Javascript i used some jQuery libraries without understanding, just configured with doc help.
When i tried to write some Javascript on my own and found there are big changes in JS world (like ES6, TypeScript) i found it very usefull. When i found JS frameworks, i felt in love.
I have read about frameworks, watched some tutorials. As many other, i found React nice. But what i'm completely missing, is the server part. Especially React tutorials creates components or functions, nice UI, but don't cover what happens with data next. I know that React is ment as "V" in MVC. But what is the best-practice or wide-used extension for server part? Are there tutorials or book to take me further than just creating actions and UI?
Thanks for any links, i just need to point best direction. Or is React ment for just specific project parts and better to look elsewhere?

As you said, yes there are quite a number of tutorials and most of them don't cover how do you deploy node apps on the servers. I'll assume you have some server admin knowledge so I'll skip straight to the meat of the setup.
The Server Setup
Regardless of it being a simple static page, a single page API or a react app, you will need to have Node.js installed on any server you will want it to run. Second you will need a production process manager for Node.js. My personal favourite is PM2. The process manages makes sure your app is always on and restarts it if it goes down for whatever reason. You will also need a reverse proxy server (you need this for security and SEO purposes). Again, a go-to for it is Nginx (it's a competitor of Apache)
Two very good tutorials for setting up your server are
Tut #1
Tut #2
The App Setup
Apart from all the server setup you need to handle routing for your app (what happens when you to go to /blog or /login). A stable standard right now is Express.js. You can do without but then you will need to write a lot of the manual routing by hand in Node.js You will set up Express to server back your Index file and any others you may need.
A good tutorial for configuring your Express for a React app is Video Tut.
He does show a bit more but that is on later videos. You can stop once you get the gist of it.
Advanced Stuff
There's also the matter if you want the JavaScript to be rendered on the server or on the client side. For that you will need to make some more configuration for you app. The video tutorial I linked above should show you how to set that up as well if you are interested.

Social network architecture decision

As I can't orientate freely in the topic of building dynamic sites, it is quite hard to me to google this. So I'll try to explain the problem to you.
I'm developing a simple social network. I've built a basic PHP API represented by the files like "get_profile.php", "add_post.php", etc. with the POST method that is used to pass some data. Then I try to get the data using JS AJAX (php functions return it by JSON), which means I get all the data that I need to show on a page after the page is loaded. That causes decreasing of a page loading speed and I feel like this structure is really wrong.
I hope you'll explain me how to build a proper structure or at least give me some links to read. Thanks.

Populate the HTML with the (minimum) required data on the server side and load all other necessary data on the client side using AJAX (as you already do).
In any case, I would profile your application to find the most important bottle necks. Do you parallelize AJAX requests?
Facebook, for example, doesn't populate its HTML with the actual data on the server side, but provides the rough structure, which is later filled using AJAX requests.

If I understood your architecture right, it sounds ok.
Advices
Making your architecture similar to this allows you to deliver templates for the page structure that you then populate with data from your ajax request. This makes your server faster also since it doesn't have to render the HTML also.
Be careful with the amount of requests you make though, if each client makes a lot of them you will have a problem.
Try and break your application into different major pieces and treat each one in turn. This will allow you to separate them into modules later on. This practice is also referred as micro-services architecture.
After you broke them down try and figure user interaction and patterns. This will help you design your database and model in a way in which you can easily optimise for most frequest use-cases.
The way of the pros.
You should study how facebook is doing things. They are quite open about it.
For example, the BigPipe method is the fastest I have seen for loading a page.
Also, I think you should read a bit about RESTful applications and SOA type architectures.

What is best way to save data with appengine/HTML5/JavaScript/Python combo?

I want to build an application with an HTML5 interface that persists data using google-app-engine and could do with some some advice to avoid spending a ton of time going down the wrong path.
What is puzzling me is the interaction between HTML5, Javascript/JQuery and Python.
Let's say, I have designed an HTML5 site. I believeetc I can use prompts and forms to collect data entered by users. I also know that I can use Javascript to grab that data and keep it in the form of objects...I need objects for reasons I'll not go into.
But when I look at the app-engine example, it has HTML form information embedded in the Python code which is what is used to store the data in the cloud Datastore.
This raises the following questions in my mind:
do I simply use Python to get user entered information?
how does python interact with a separately described HTML5/CSS2 forms and prompts?
does Javascript/Jquery play any role with respect to data?
are forms and prompts the best way to capture use data? (Is there a better alternative)
As background:
It is a while since I programmed but have used HTML and CSS a fair bit
I did the Javascript and Jquery courses at Codeacademy
I was considering using Go which looks funky but "experimental" worries me and I cannot find a good IDE such as devTable
I can do the Python course at Codeacademy pretty quickly if I need it? I think I may need to understand there objects syntax
I appreciate this is basic basic stuff but if I can get my plumbing sorted, I doubt that I'll have to ask too man more really stupid questsions
Gary

Q1 : Udacity has an excellent course web development, which is making use of app engine, webapp2, jinja, python 2.7 and HTML forms.
Q2: You can use the Python packages jinja and wtforms or use django or others to interact with users.
Q3: Only if you need it. You do not need it for basic form IO.
Q4: You can also process forms with javascript and jquery / ajax.

App engine supports python 2.7, it gives you access to several tools and libraries.
You have tutorials in app engine documentation to get started with python and all you need to know but it is not a sufficient source.
Getting started with app engine(Python)
https://developers.google.com/appengine/docs/python/gettingstartedpython27/introduction
To send your forms you can to use AJAX with JQuery framwork, check out this tutorial:
http://pythoughts.com/ajax-with-google-app-engine/
And forms processing can be handled by webapp2 framework
Handling forms with webapp2:
https://developers.google.com/appengine/training/py101_1/lesson3
Explaining the webapp2 Framework
https://developers.google.com/appengine/docs/python/gettingstartedpython27/usingwebapp

You question is too complex but I will answer simply to help you. I use all what you want use.
Google App Engine is web server.
Html page is web request.
When user click "submit" Html page (web request) is send to Google App Engine (server) and it is routed by url to handler.
Handler can read all params from form.
self.request.params.get('something')
You can stored some data in models and retrive it later.
SomeForm(db.Model):
userName = db.StringProperty()
form = SomeForm()
form.userName = self.request.params.get('userName')
form.put()
When user click "button" with some jquery/ajax action it send to to Google App Engine (server) and it is routed by url to handler.
Again all is the same apart that you can use json to communicate and send back result to page and update content with jquery again.
I am using Eclipse 3.8 (support dual monitors - 4.x not do it) + pyDev + javascript + HTML5 + Css3 plugins + git ... - It will allow you very stable programing with debugging.
I am using pure GAE + django (support internationalization better than Jinja) + jquery + ...
Questions are basic but not stupid. Please vote on answer.

My thanks to all of you for taking time to respond. Each response was useful it it's own way.
The AJAX/JQuery looks a promising route for me, so many thanks for the link on that. I'll stop equivocating and stick with Python rather than try Go and start working through the tutorials and courses.
Gary

Mobile Web Apps - Multiple pages or AJAX?

I'm about to embark on a large project based around mobile web apps. I am going to create a mobile web app that will have multiple screens, a search system and a few other features.
I need to establish a primary framework for this application. It seems I have two options; multiple separate HTML pages, or alternatively, use AJAX to download the contents and move divs in and out of the viewport.
I don't have to worry about SEO. I'm primarily looking for good performance. I understand Stack Overflow is a site about questions and answers and this does somewhat involve opinion, but I feel that based on my criteria there should be a solid answer to this question.
I'd highly appreciate it if somebody could share what they think the best option would be for me on this project.

What I believe you're referring to by using AJAX to download the contents is commonly known as a single-page web app. These generally involve rendering data using templates on the client side and sending and receiving the data via AJAX.
For these, there are plenty of excellent JavaScript framework options, including:
Backbone.js
Knockout.js
Angular.js
Ember.js
Of these, Knockout is probably the easiest to learn (seriously, the tutorial is brilliant), but the lack of routing lets it down somewhat. I tend to use Backbone for this type of thing myself, although if I were starting over I would probably go for Angular as it's made by Google and seems to have more momentum. But try a few tutorials and see which one works best for you!
All of these offer a lot of very handy functionality for your use case, as they enable you to load data via AJAX and render it on the client side quite easily. There is a learning curve for all of them, but they result in a much more maintainable and testable client-side application. Believe me, I have tried to build such an application with just jQuery, and I would recommend you avoid it as it gets very painful, very quickly!
Your mileage may vary, but by and large a single-page web app like this should perform better than a more traditional web page because once the application has loaded, all the communication with the server is just sending and receiving JSON. It will also likely be simpler as you can use a lightweight REST framework like Slim, Sinatra, Express or Flask on the server side, and just serve up the static content on the home page, then do everything else via AJAX.

rails and backbone working together

I am just starting to look at MVC structure, first i looked at how backbone.js worked, and now I have just completed rails for zombies, by Code School. I know that I haven't delved too far into any of this, but I had a question to begin with.
Can you use these libraries together?
I have learned how to create models, views, etc in both, but when creating a real application do you use both backbone and rails?
If so...
When do you use a backbone.js model vs. a rails model?
Maybe I am just getting ahead of myself and need to keep practicing and doing tutorials but I couldn't seem to find anything directly on this.
Thanks!

Before anything else I'd suggest taking a look at thoughtbot's Backbone.js on Rails book, which is a great starting point, although aimed at an intermediate to advanced audience. I bought this book having already worked with rails but as a total backbone.js beginner and it has served me very well.
Beyond that, there are some fundamental issues with combining these frameworks which go beyond the details covered in this book and other books. Below are some things I'd suggest you think about, from my own experiences pairing RoR and backbone.js. This is a long answer and strays a bit from the specifics of your question, but I hope it might help you out in the "big picture" sense of understanding the problem you're facing.
Rails: Web Framework vs API
The first thing you confront when using backbone.js on top of a rails application is what to do about views, but this is really just the surface of a much deeper issue. The problem goes to the very heart of what it means to create a RESTful web service.
Rails is set up out of the box to encourage its users to create RESTful services, by structuring routing in terms of a set of resources accessed at uniform URIs (defined in your routes.rb file) through standard HTTP actions. So if you have a Post model, you can:
Get all posts by sending GET request to /posts
Create a new post by sending a GET request to /posts/new, filling out the form and sending it (a POST request) to /posts
Update a post with id 123 by sending a GET request to /posts/123/edit, filling out the form and sending it (a PUT request) to posts/123
Destroy a post with id 123 by sending a DELETE request to /posts/123
The key thing to remember about this aspect of Rails is that it is fundamentally stateless: regardless of what I was doing previously, I can create a new Post simply by sending a POST request with a valid form data to the correct URI, say /posts. Of course there are caveats: I may need to be logged in (have a session cookie identifying me), but in essence Rails doesn't really care what I was doing before I sent that request. I could follow it up by updating another post, or by sending a valid action to whatever other resources are made available to me.
This aspect of how Rails is designed makes it relatively easy to turn a (Javascript-light) Rails web application into an API: the resources will be similar or the same, the web framework returning HTML pages while the API (typically) returns data in JSON or XML format.
Backbone.js: A new stateful layer
Backbone is also based on RESTful resources. Whenever you create, update or destroy a backbone.js model, you do so via the standard HTTP actions sent to URIs which assume a RESTful architecture of the kind described above. This makes it ideal for integrating with RESTful services like RoR.
But there is a subtle point to be stressed here: backbone.js integrates seamlessly with Rails as an API. That is to say, if you strip away the HTML views and just use Rails for serving RESTful resources, integrating with the database, performing session management, etc., then it integrates very nicely with the structure that backbone.js provides for client-side code. Many people argue that there's nothing wrong with using rails this way, and I think in many ways they are right.
The complications arise though from the issue of what to do with that other part of Rails that we've just thrown away: the views and what they represent.
Stateful humans, stateless machines
This is actually more important than it may initially seem. HTML views represent the stateless interface that humans use for accessing the RESTful resources your service provides. Doing away with them leaves you with two access points:
For humans: a rich, client-side interface provided by the backbone.js layer (stateful)
For machines: a resource-oriented RESTful API provided by the rails layer (stateless)
Notice that there is no longer a stateless (RESTful) interface for humans. In contrast, in a traditional rails app with an API, we had something closer to this:
HTML resources for humans (stateless)
JSON/XML resources (API) for machines (stateless)
The latter two interfaces for accessing resources are much closer in nature to each other than the previous two. Just think for example of rails' respond_with, which takes advantage of the similarities to wrap various RESTful responders in a unified method.
Working together
This might all seem very abstract and beside the point, I know. To try to make it more concrete, consider the following problem, which gets back to your question about getting rails and backbone.js to work together. In this problem, you want to:
Create a web service with a rich client-side experience using backbone.js, with rails as the back end serving resources in JSON format.
Use pushState to give each page in the app a URL (e.g. /posts/123) which can be accessed directly (by entering it into the browser bar).
For each of these URLs, also serve an HTML page for clients without javascript.
These are not unusual demands for a modern web service, but they create a complex challenge. To make a long story short, you now have to create two "human-oriented" layers:
Stateful client-side interface (backbone.js templates and views)
Stateless HTML resources (Rails HTML views)
The complexity of actually doing this leads many nowadays to abandon the latter of these two and just offer a rich client-side interface. What you decide to do depends on your goals and what you want to achieve, but it's worth thinking about this problem carefully.
As another possible reference for doing that, I'd suggest having a look at O'Reilly's RESTful Web Services. It might seem odd to be recommending a book on REST in a question about Rails and Backbone.js, but actually I think this is the key piece that fits these very different frameworks together, and understanding it more fully will help you take advantage of the strengths of both.

Yes, you can use both side by side. Backbone is for storing and manipulating data within the client browser. It generally needs a server to talk to and fetch the data from. This is where Rails comes in. You can have a web application without heavy client-side code. Backbone is for building out sites that feel more like apps--think of Gmail or Pandora.
I advise just learning Rails first. Once you can get static pages loading and styled as you wish, then understanding Backbone's place will make more sense

I've used rails as a backend server to serve a fairly large website, which included a few one-page apps (built in backbone).
I'd suggest the backbone-on-rails gem. The idea is that your rails server will serve up the backbone app as a script tag in one of your views. You keep your backbone app itself in the rails app/assets folder.
Backbone understands rails routing conventions, and you just need to give it a path to a json api that rails can almost generate for you with rails generate resource.
Other than the syncing between the models, your backbone apps and rails apps are fairly separate. Backbone and Rails don't have quite the same MVC model, but getting them to cooperate is pretty easy.