A primeira parte do artigo explicou como funciona uma página da Web do lado do cliente.
Agora vamos ver o que acontece no lado do servidor.

Parte II

Lado do servidor: formulários e bancos de dados

1. Formulários

Até agora, falamos apenas sobre a recuperação de dados do servidor. E o envio de dados? Os formulários são o outro lado do HTML: eles nos permitem enviar informações para o servidor. Podemos usar os formulários para atualizar informações existentes ou adicionar novas informações.
Os métodos mais usados em formulários HTML são ENTRE et POST.

Dê uma olhada no código acima :
Temos dois campos de entrada (entrada) onde o usuário pode inserir dados e um botão enviar (enviar).
Após o usuário clicar neste botão, o navegador envia os valores dos dados inseridos nos dois campos para um script PHP chamado criarproduto.php.
Em nosso exemplo, é PHP, mas pode ser JSP, Python ou qualquer outra linguagem de script do lado do servidor. O script do lado do servidor pode ler os valores enviados pelo navegador através do método POST, processe-os ou armazene-os em um arquivo ou banco de dados. Em poucas palavras, é como os dados são enviados ao servidor antes de serem armazenados.

O que é PHP?

PHP para Pré-processador de hipertexto, é uma linguagem de script do lado do servidor para criar sites e aplicativos dinâmicos. Em outras palavras: é uma linguagem que permite acessar e ler um banco de dados e depois transcrever suas informações dentro de uma página HTML.
Nota: Digamos que queremos adicionar validações antes de enviar os dados — por exemplo, o nome do produto deve conter pelo menos 5 caracteres ou o campo “SKU” não deve estar vazio. Podemos usar JavaScript para essas validações. Teremos então que reagir ao evento click do botão submit, e verificar se os elementos web possuem os dados que desejamos. Se algo estiver faltando, podemos exibir uma mensagem de erro e parar de enviar dados para o servidor.

2. Bancos de dados

Assim que a quantidade de informações começa a crescer, recuperá-las de arquivos pode se tornar muito complicado e muito lento. Por exemplo, vamos pegar o arquivo da lista de preços, suponha que a empresa tenha milhares de produtos e queremos saber as informações do último produto da lista - o que significa que precisamos ler todos os produtos até o que encontramos. procurando por. Essa não é uma maneira ideal de recuperar informações. É para resolver esse problema que os bancos de dados foram criados.
Em um banco de dados (DB), armazenamos dados em tabelas (um conjunto estruturado de dados). Assim, podemos facilmente realizar uma pesquisa, classificar dados ou realizar qualquer outra operação.

3. Linguagens e estruturas de script do lado do servidor

Precisamos de linguagens de script do lado do servidor para :

armazenar e ler informações de um banco de dados ou arquivo;
obter (ENTRE) informações de um servidor executando determinadas operações;
leia as informações enviadas pelo cliente (POST) e armazená-los ou distribuí-los realizando determinadas operações de processamento.

Linguagens de programação típicas, como C e Java, podem ler e gravar em bancos de dados, mas não podem ser executadas diretamente no navegador da web (cliente). Isso deu origem às linguagens de script do lado do servidor.
As linguagens de script do lado do servidor podem fazer todo o processamento de dados usual, comunicar-se com bancos de dados e rodar em um servidor web. As linguagens de script do lado do servidor mais comuns são PHP, Perl, JSP, Ruby on Rails, etc.
Os desenvolvedores começaram a usar essas linguagens e logo perceberam que estavam escrevendo o mesmo código clichê para todos os projetos, o que levou ao desenvolvimento de enquadramentos que facilitam e aceleram o desenvolvimento de aplicações web.
Alguns frameworks conhecidos :

PHP: Zend, YII, Symfony, CakePHP, Laravel;
CMS PHP (também usado como frameworks): Drupal, Joomla, SugarCRM, WordPress;
Java : J2EE, Hibernate, Struts, Spring;
JavaScript : Node.js.

4. Arquitetura e sessões MVC

A arquitetura MVC ajuda-nos a dividir o código em vários ficheiros e permite-nos separar a lógica de negócio da apresentação, de forma a facilitar a sua modificação posterior.
Tomando o exemplo de uma plataforma de blog, voltaremos a todos os tópicos explicados anteriormente para ver como podemos codificar usando a arquitetura MVC.
Uma plataforma de blog gerencia conteúdo dinâmico e pode conter vários módulos como :

Comercial (usuários);
Itens (postagens no blog);
Palavras-chave / tags (Tag);
Categorias (Categorias).

Antes de falar sobre outros recursos, vamos imaginar o design do banco de dados para a tabela de Artigos (tbl_blog_post). Campos importantes seriam :

Como você pode ver, armazenamos informações duplicadas do usuário: nome (Nome) e último nome (Sobrenome) repita o conteúdo do campo Criado por. Se tivermos 10 postagens no blog, armazenaremos essas informações duplicadas do usuário em cada uma das 000 postagens. E pode haver outras informações sobre o usuário para salvar, como sua função, sua última data de login etc.
A alternativa, como você já deve ter adivinhado, é armazenar essas informações do usuário em outra tabela Utilisateur (usuário_tbl) e vinculá-lo ao dos artigos (tbl_blog_post) por um id como abaixo :

Essa separação de dados em várias tabelas é um dos muitos princípios da normalização de dados.
A próxima parte importante é permitir que o usuário insira dados nessas tabelas por meio de um formulário HTML. Lembre-se de que detalhamos essas etapas para entender os conceitos — este não é de forma alguma um tutorial de programação completo.

Criação de uma nova postagem no blog por um usuário autenticado

Para isso precisamos de um formulário HTML com dois campos de entrada (Título, Conteúdo) com o qual o usuário pode criar um artigo.
Assim que o usuário insere as informações e clica no botão enviar, “Criar artigo”, os valores do formulário são enviados para o servidor web através do método POST. Os valores enviados POST pode ser lido por qualquer linguagem de script do lado do servidor. O script do servidor (PHP, Ruby on Rails, Python, etc.) lê o valor do formulário e o passa para o banco de dados.
O script também pode processar informações, que podem ser para recuperar a data e hora do servidor ou para realizar determinados cálculos com base em valores extraídos de outra tabela do banco de dados ou de outro serviço.web.
Outro ponto a ser observado: o script também pode realizar validações, também chamadas de validações do lado do servidor, para garantir que os dados sejam válidos. Somente se os dados forem válidos eles são salvos na tabela tbl_blog_post. Caso contrário, uma mensagem de erro é enviada ao cliente para inserir as informações ausentes.
Visualmente, o formulário para recuperar dados de nossa tabela tbl_blog_post pode se parecer com a interface de criação de postagens do WordPress :

Existe um campo para inserir o título (Título), em seguida, uma caixa de entrada para o conteúdo (Conteúdo).
A data de criação (Criado em), por sua vez, é recuperado dinamicamente pela linguagem de script (aqui, PHP) e corresponderá ao momento exato de criação do artigo (ano, mês, dia, hora, minuto e até segundo).
Outros dados que não são necessários inserir: o identificador do artigo (ID). Ele é gerado automaticamente pelo banco de dados, o que garante que seja único dentro da mesma tabela.
Na nossa mesa tbl_blog_post, além de título e conteúdo, também temos um campo chamado criado por.
Como obtemos o valor para preencher este campo?

Usuário conectado/autenticado

Geralmente, a maioria dos aplicativos da Web tem funcionalidade de login. Cada vez que um usuário autentica com sucesso, as informações desse usuário são armazenadas em sessões para que as informações possam ser reutilizadas posteriormente.

O que é uma sessão?

HTTP é um protocolo sem estado, o que significa que nenhuma solicitação ENTRE ou POST enviado pelo cliente para o servidor web não é rastreado. Se o cliente (o navegador) fizer duas solicitações, o servidor web não saberá se elas vêm do mesmo usuário. Isso também significa que, por exemplo, se você estiver conectado a um site de comércio eletrônico e adicionar produtos à sua cesta, o servidor não saberá que são para o mesmo usuário.
Para superar essa ausência de estado, os clientes precisam enviar informações adicionais em cada uma de suas solicitações para reter as informações da sessão pela duração de várias solicitações. Essas informações adicionais são armazenadas no lado do cliente em cookies e no lado do servidor em sessões.
Uma sessão é um array de variáveis, no qual as informações são armazenadas para serem utilizadas em várias páginas. As sessões são identificadas por um ID único cujo nome depende do idioma — em PHP é chamado de “Código de sessão PHP”. Esse mesmo ID de sessão deve ser armazenado em um cookie no navegador para ser associado ao usuário.

Mostrar um único item

A próxima etapa é exibir as postagens do blog individualmente. Precisamos ler os dados do banco de dados com base no post id (ID) do artigo solicitado, depois exiba os valores dos campos Título (Título) e Conteúdo (Conteúdo).
Aqui está o pseudocódigo para exibir um único post :

Leia os dados do banco de dados associados ao ID do item.
Insira esses dados em uma página HTML contendo CSS e JS.

Todo o código acima pode ser escrito em um único arquivo. Na verdade, foi assim que foi feito no início, mas a comunidade de desenvolvimento percebeu que não era o ideal. De fato, para cada novo recurso a ser adicionado, todo o código tinha que ser modificado e não era fácil trabalhar em um ambiente de vários desenvolvedores.
Isso fez com que os desenvolvedores da Web adotassem a arquitetura MVC, que essencialmente divide o código em três componentes :

O modelo : esta é a lógica de negócios, independente da interface do usuário. Em nosso exemplo, este é o código que recupera os artigos do banco de dados.
La Vue : uma visualização de uma representação visual dos dados. Em nosso exemplo, é o código HTML que exibe os artigos. Assim, os dados vêm do Model e o HTML é a View.
O controlador : Chama-se ao clicar no link “Ver artigo”. O Controller recupera dados do banco de dados usando o Model e os exibe na View.

Vejamos uma URL típica para um aplicativo usando a arquitetura MVC.
http://www.abc.com/blogpost/id/1
aqui blogpost é o nome do controlador e a visão é uma ação (método) deste controlador. id é o identificador do item. Se inserirmos esta URL em um navegador, a requisição irá para a ação “View” do controller “BlogPost”, e chamará o model lá para obter o conteúdo do artigo com ID “1”, na forma de 'an objeto. Este objeto é então passado para a “View” a ser exibida.
Mais concretamente: o seguinte URL https://www.ux-republic.com/blog/page/2 exibe a segunda página da lista de todas as postagens do blog UX-Republic.
Decompondo o URL, temos :

blog, o controlador
página, o identificador que designa o número da página
2, o número da página

Toda vez que a paginação é clicada, é o mesmo método do controlador blog que é executado e que é responsável por recuperar o conteúdo correspondente ao página selecionado.

Ajax e aplicativos de página única (SPA)

Se você nasceu no último milênio, deve se lembrar dos provedores de webmail Hotmail e Yahoo!, muito populares nas décadas de 1990 e 2000. Quando você clicava na caixa de entrada ou em um e-mail, a página inteira era atualizada. Por volta de 2004, o Gmail chegou com um recurso importante: o Ajax. Com o Ajax, a página inteira não é atualizada – apenas as partes que precisam são. Portanto, se você receber um novo e-mail, basta vê-lo aparecer no topo da página, sem precisar recarregá-lo. Isso ajudou a oferecer aos usuários uma melhor experiência de navegação, e o Ajax se tornou uma maneira muito popular de criar aplicativos.

O que é Ajax?

Os banhos Ajax representa um grande grupo de tecnologias web que podem ser implementadas em uma aplicação que se comunica com um servidor em segundo plano, sem interferir no estado atual da página.
Com o Ajax, você envia uma solicitação por ENTRE para o servidor, e o servidor envia sua resposta sem bloquear a página web, o que significa que o usuário pode continuar navegando sem qualquer interrupção. A resposta do servidor é inserida ou anexada à página da Web atual.
Em sites que não usam Ajax, cada ação do usuário requer um recarregamento completo da página do servidor. Esse processo é ineficiente e cria uma experiência ruim para o usuário porque todo o conteúdo da página desaparece antes de reaparecer.
Ajax é uma das técnicas usadas para construir aplicativos de página única (Aplicativos de página única ou SPA). Como o nome sugere, todo o aplicativo cabe em uma única página e todo o seu conteúdo é carregado dinamicamente. Estruturas JavaScript como Angular, React e Backbone.js podem ser usadas para fazer SPA.

Servidores e navegadores

Os navegadores são os intérpretes da web. Eles solicitam dados de servidores web, que processam a solicitação e enviam uma resposta ao navegador em HTML (com CSS, JS, imagens etc.), e essa resposta é exibida.
Uma solicitação ao servidor web pode ser feita usando um dos três métodos importantes :

ENTRE : obter o recurso solicitado como resposta;
CABEÇA : igual a ENTRE, mas o recurso é recuperado no cabeçalho da resposta;
POST : envia os dados para o servidor.

Por exemplo, quando você digita “google.com” no navegador, o navegador envia este comando para o servidor google.com em segundo plano:
ACESSE: http://google.com
O servidor da web do Google então examinará seu arquivo principal (índice) e retornará sua resposta ao cliente. Geralmente envia conteúdo HTML e arquivos CSS junto com quaisquer outros arquivos de mídia.

# Tradução do artigo Entenda o desenvolvimento da Web em menos de 1 horaPor Shaik Ismael

Entenda o desenvolvimento web em menos de uma hora [parte 2]