Веб-фреймворки: введение для новичков


The PHP micro-framework based on the Symfony Components

Silex is a bit interesting. Written in PHP and based on Symfony, Silex is scalable in every sense of the word — the design concept from the very beginning was to make the framework as lightweight as you need it to be, enabling additional functionality through base extensions.

As such, Silex currently exists in two forms. There is the “fat” version, which includes a template engine, Symfony components, database abstraction, a Twig wrapper, and more, and then there is the “slim” version, which contains just the basic routing engine and the various methods of tying in additional functionality through extensions.


Judging Silex is very hard to do in a general sense when we discuss lightweight frameworks, because so much of it depends entirely on which version you use.

With the fat version, the integration of Symfony’s HttpKernel to abstract requests and responses aids drastically in application testing, which can speed up time to market by leaps and bounds. The use of Pimple for dependency injection makes for Application classes which can be used as if they were arrays, making Silex classes extremely flexible.

Some of that is ported to the slim version as well, but slim is more about the speed of its routing. With less overhead and features, Silex slim is predictably very fast, which is attractive to smaller services or services depending on basic processing of large amounts of data.

There is something to be said for having a choice in terms of how large you want your framework to be, though. Having the choice between a fat or slim version of the codebase and the option to later expand upon it in an officially sanctioned way is really powerful, and opens a lot of options up for developers.

A great argument for Silex is that it’s so very extensible. Pimple is functionally a microservice container, allowing third party libraries the ability to tie in, making it both feature-empty and feature-rich in some sort of awesome superstate of quantum feature availability.


With all of that being said, the double choice is somewhat of an issue as much as it’s a feature. Depending on which version you get, Silex might not actually do what you want it to do out of the box, and discovering this only after a long process of attempting to get it to do what you want is perhaps one of the most frustrating things a developer can experience.

Even ignoring that, which is not so much an issue of the framework and more an issue of the developer, there is the obvious issue of speed. Yes, Silex is very fast — in its slim mode. As you add additional functionality, the speed can drop off, making it harder to scale with greater amounts of data. Since we’re talking about being lightweight, this becomes a serious issue.

All that being said, the real issue here lies in poor planning of the microservice itself — if the developer plans poorly, they will run into a greater amount of issues in Silex related to their poor planning than in other languages, and at the end of the day, they might run into a situation where the framework they adopted for speed is no longer fast due to their own poor planning.

Also check out: 12+ Frameworks to Build ChatOps Bots


The stunningly fast micro-framework by Laravel

Lumen is intimately related to Laravel, having been developed by Taylor Otwell to quickly build Laravel microservices in a rapidly deployable way. Since 5.2, however, it has moved in a slightly different direction, eschewing a lot of the holdovers to become much sleeker than Laravel.

Notably, Lumen as of version 5.2 no longer includes sessions and views as part of its framework, relegating that to Laravel alone. This results in a much leaner framework than Laravel, and shifts the focus more towards stateless APIs.


Lumen is basically Laravel, but fast. By getting rid of a lot of the extra components that don’t mesh well with stateless APIs, Lumen has managed to slim down considerably, making it an extremely fast and lightweight solution over other frameworks.

Due in large part to this and other design choices, Lumen is a great choice for microservices and optimizing APIs for a quick response time. The framework has been designed from day one to be fast more than anything else, so it’s often quoted as an optimal choice for speed dependent implementations. Additionally, Lumen is simple in its syntax, allowing for ease of deployment.

The intimate relation to Laravel also gives a few benefits to Lumen that other frameworks don’t have. While Laravel’s third party support isn’t as great as other solutions, and it’s community is relatively narrower than others, it still boasts a pre-set range of extensions and appliances that other solutions may not have.

One of the greatest strengths of Lumen is a non-measurable entity — the fact that it was designed by Otwell, who has quite a bit of experience in microservices framework, is something to be mentioned. Additionally, Lumen projects can simply be dropped into a Laravel installation for instant functionality, meaning that anything written for Lumen can function with all the benefits and features in Laravel proper.


Interestingly enough, most of the cons of Lumen are actually derived from the same place its pros are — its intimate relationship with Laravel. While much has diverged in development, there’s still a lot of small hangons from Laravel that make Lumen imperfect.

A big point here is that if you dislike Laravel’s syntax or approach to database querying, you’re going to dislike Lumen just as much, as much of its practices are similar. That being said, Laravel is slower than Lumen by a wide mile, so this might be a non-issue when weighed against the possible benefits.

However fast Lumen is, it’s not the fastest on the block, as is often claimed. As such, if developers dislike the syntax or approach and merely wish to adopt for the speed, this should be somewhat tempered with the knowledge that there are other, even faster frameworks with which to work.

Особенности и архитектура

Несмотря на то, что все фреймворки отличаются друг от друга и выбрать какой-нибудь из них может быть очень сложно, есть несколько вещей, общих для них всех. Речь идёт об архитектуре и особенностях, которые так же важны, как и функции.


Архитектура почти всех фреймворков основана на декомпозиции нескольких отдельных слоёв (приложения, модули и т.д.), что означает, что вы можете расширять функциональность исходя из своих потребностей и использовать изменённую версию вместе с кодом фреймворка или использовать сторонние приложения. Такая гибкость является ещё одним ключевым преимуществом фреймворков. Существует множество open-source сообществ и коммерческих организаций, которые создают приложения или расширения для популярных фреймворков, например, Django REST Framework, ng-bootstrap и т.д.

MVC — Модель, Представление и Контроллер (Model-View-Controller) — три составляющих каждого веб-фреймворка.

Модель содержит все данные и уровни бизнес-логики, её правила и функции.

Представление отвечает за визуальное отображение данных, например, диаграммы, графики и т.д.

Контроллер просто трансформирует данные для команд предыдущих двух составляющих.

Они неотделимы друг от друга, поэтому важно как следует во всём разобраться, чтобы избежать ошибок во время работы приложения


Теперь давайте посмотрим на некоторые общие особенности, которые делают фреймворки многофункциональными и удобными на практике.


Кэширование просто помогает хранить разные документы и позволяет избежать надоедливой перегрузки сервера. Пользователи могут использовать его в разных системах при определённых условиях. Также оно работает на серверной стороне. Например, вы могли заметить кэшированные веб-страницы на странице результатов поисковой выдачи Google.


Это ещё одна технология, поддерживаемая некоторыми MVC-фреймворками, о которой следует знать. Фреймворк может автоматически сгенерировать типичные части приложения или даже всю струкутру проекта (если речь идёт о инициализации). Это позволяет существенно увеличить скорость разработки и стандартизирует кодовую базу.

Система веб-шаблонов

Система веб-шаблонов представляет собой набор разных методологий и программного обеспечения, реализованных для создания и развёртывания веб-страниц. Для обработки веб-шаблонов используются шаблонизаторы. Они являются инструментом фреймворка, отвечающим за веб-публикацию.

Сопоставление URL

Если вы хотите упростить индексацию вашего сайта поисковыми движками, в то же время создавая привлекательное название для сайта, то эта функция фреймворков — то, что вам нужно. Также сопоставление URL может облегчить доступ к страницам вашего сайта.


Множество типов веб-приложений поддерживаются веб-фреймворками. В основном они применяются для создания таких приложений, как блоги, форумы, CMS и т.д.

Вся эта функциональность свойственна всем фреймворкам. Однако, как ни парадоксально, с таким широким ассортиментом разработчик теряется и не может ничего выбрать. Поэтому вам нужно придумать критерии, согласно которым можно выбрать лучший инструмент, облегчающий разработку. Например, ваш выбор может зависеть от предпочитаемого языка программирования. Как было упомянуто ранее, фреймворки можно найти на всех языках

Кроме того, нужно обратить внимание на круг возможностей набора инструментов фреймворка. Если он покрывает ваши потребности, то вы на верном пути

Говоря о предпочтениях, стоит отметить, что они могут служить как во благо, так и во вред. Конечно, лучше использовать фреймворки, которые проще изучить, однако порой написанные по правилам старой школы и редко используемые, но подходящие фреймворки, могут привести вас к успеху.

Добавление зависимостей

Большинство приложений будут иметь некоторые зависимости, а Slim прекрасно их имитирует, используя DIC (Container Injection Container), построенный на Pimple. В этом примере будут использоваться как Monolog так и PDO соединение с MySQL.

Идея контейнера для инъекций зависимостей заключается в том, что вы настраиваете контейнер для загрузки зависимостей, которые необходимы вашему приложению, когда они им нужны. После того, как DIC создал / собрал зависимости, он сохраняет их и может предоставить их позже, если это необходимо.

Чтобы получить контейнер, мы можем добавить следующее после строки, в которой мы создаем, и до того, как мы начнем регистрировать маршруты в нашем приложении:

Теперь у нас есть объект, мы можем добавить к нему наши сервисы.

использование Monolog в вашем приложении

Если вы еще не знакомы с Monolog, это отличный framework логирования для PHP-приложений, поэтому собираюсь использовать его здесь. Во-первых, подключите библиотеку Monolog через composer:

Зависимость называется , а код для добавления выглядит следующим образом:

Мы добавляем элемент в контейнер, который сам является анонимной функцией ( параметр передается в самом контейнере, поэтому вы можете использовать другие зависимости, если это вам нужно). Это будет вызвано, когда мы попытаемся получить доступ к этой зависимости в первый раз; здесь код устанавливает настройку зависимости. В следующий раз, когда мы попытаемся получить доступ к той же зависимости, тот же самый объект, который был создан в первый раз, будет использоваться в следующий раз.

Мой Monolog конфиг здесь довольно прозрачен, только настройки приложения для регистрации всех ошибок в файл (помните, это путь с точки зрения того, где работает скрипт, в нашем случае это ).

С помощью logger на месте я могу использовать его изнутри кода роута с помощью строки, подобной этой:

Хорошее логирование приложения — действительно важная основа для любого приложения, поэтому я всегда рекомендую поместить что-то подобное на место. Это позволяет вам добавить столько или меньше отладки, сколько захотите, и с помощью соответствующих уровней журнала с каждым сообщением вы можете иметь столько же или немного деталей, сколько подходит для того, что вы делаете в любой момент.

Добавить соединение с базой данных

Существует множество библиотек баз данных, доступных для PHP, но в этом примере используется PDO — это доступно в PHP в качестве стандарта, поэтому оно, вероятно, полезно в каждом проекте или вы можете использовать свои собственные библиотеки, адаптировав приведенные ниже примеры.

Точно так же, как мы сделали для добавления Monolog to the DIC, мы добавим анонимную функцию, которая устанавливает зависимость, в этом случае называется :

Помните конфиг, который мы добавили в наше приложение раньше? Ну, вот где мы его используем — контейнер знает, как получить доступ к нашим настройкам, и поэтому мы можем легко получить нашу конфигурацию отсюда. С помощью config мы создаем объект (помните, что это приведет к отказу, если он сработает, и вы можете обработать это здесь) чтобы мы могли подключиться к базе данных. Я включил два вызова, которые действительно не нужны, но я нахожу, что эти два параметра делают PDO более удобным для использования в качестве библиотеки, поэтому я оставил настройки в этом примере, чтобы вы могли их использовать! Наконец, мы возвращаем наш объект соединения.

Опять, мы можем получить доступ к нашим зависимостям с помощью только, и затем имя требуемой зависимости, которая в этом случае есть , по этому в моем случае приложении есть код, который выглядит примерно так:

Это приведет к dependency зависимости от DIC, создав его, если это необходимо, и в этом примере просто позволяет мне передать объект прямо в мой класс сопоставления.

В чем смысл?

Slim — это идеальный инструмент для создания API-интерфейсов, которые используют, обрабатывают или публикуют данные. Также Slim отлично подходит для быстрого прототипирования. Черт, вы даже можете создать полнофункциональный веб приложения с пользовательскими интерфейсами

Что еще более важно, Слим очень быстрый и имеет очень мало кода. Фактически, вы можете читать и понимать его исходный код всего за день!

Вам не всегда нужен кухонный комбайн вроде Symfony или Laravel. Это несомненно отличные инструменты, но они сликом переполнены излишним функционалом. Slim же, наоборот, предоставляет минимальный набор нужных инструментов, и не более того.

Views и Шаблоны

У Slim нет мнения о мнениях, которые вы должны использовать, хотя есть некоторые варианты, которые готовы подключить. Ваш лучший выбор — это Twig или простой старый PHP. У обоих вариантов есть плюсы и минусы: если вы уже знакомы с Twig, тогда он предлагает множество отличных фичи и функциональность, таких как разметка, но если вы еще не используете Twig, это может быть большой накладной кривой обучения, чтобы добавить в проект микрофрейворка. Если вы ищете простое, то PHP-представления могут быть для вас! Я выбрал PHP для этого примера проекта, но если вы знакомы с Twig, тогда не стесняйтесь использовать это; основы в основном одинаковые.

Поскольку мы будем использовать представления PHP, нам нужно будет добавить эту зависимость в наш проект через Composer. Команда выглядит так (аналогично тому, что вы уже видели):

Чтобы иметь возможность отображать представление, нам сначала нужно создать представление и сделать его доступным для нашего приложения; мы делаем это, добавляя его в DIC. Код, который нам нужен, связан с другими дополнениями DIC в верхней части и выглядит следующим образом:

Теперь у нас есть элемент в DIC, и по умолчанию он будет искать его шаблоны в каталоге. Мы можем использовать его для визуализации шаблонов в наших действиях — вот маршрут списка билетов снова, на этот раз включая вызов для передачи данных в шаблон и его рендеринга:

Единственная новая часть здесь — предпоследняя линия, где мы устанавливаем переменную. Теперь, когда находится в DIC, мы можем ссылаться на него как . Вызов требует, чтобы мы предоставили три аргумента: , файл шаблона (внутри каталога шаблонов по умолчанию), и любые данные, которые мы хотим передать. Объекты ответа (неизменяемы) immutable что означает, что вызов не будет обновлять объект ответа; вместо этого он вернет нам новый объект, поэтому он должен быть захвачен таким образом. Это всегда верно, когда вы работаете с объектом ответа.

При передаче данных в шаблоны вы можете добавить столько элементов в массив, сколько хотите сделать доступными в шаблоне. Ключи массива — это переменные, которые будут существовать в момент, когда мы перейдем к самому шаблону.

Например, вот фрагмент из шаблона, который отображает список билетов (т.е. код из — который использует Pure.css чтобы помочь покрыть мои недостатки навыков фронтенда):

В этом случае на самом деле это класс с геттерами и сеттерами, но если вы пройдете в массиве, вы сможете получить к нему доступ, используя здесь массив, а не объектную нотацию.

Вы заметили, что что-то интересное происходит в конце примера? Давайте поговорим о названных роутерах далее 🙂

Простое создание URL с именованными роутерами

Когда мы создаем маршрут, мы можем присвоить ему имя, вызвав объект маршрута. В этом случае я добавляю имя на маршрут, который позволяет мне просматривать отдельный ticket, чтобы я мог быстро создать правильный URL-адрес для ticket, просто указав имя маршрута, поэтому мой код теперь выглядит примерно так (просто изменен кусок кода, показанный здесь):

Чтобы использовать это в своем шаблоне, мне нужно сделать маршрутизатор доступным в шаблоне, который захочет создать этот URL-адрес, поэтому я изменил маршрут, чтобы передать маршрутизатор в шаблон, изменив строку визуализации, чтобы выглядеть так:

Поскольку маршрут имеет дружественное имя и маршрутизатор, который теперь доступен в нашем шаблоне, э то то, что делает вызов в нашем шаблоне. Поставляя , он используется как именованный заполнитель в шаблоне URL-адреса, и создается правильный URL-адрес для привязки к этому маршруту с этими значениями. Эта функция блестящая для читаемых URL-адресов шаблонов и даже лучше, если вам когда-либо понадобится изменить формат URL по любой причине — не нужно grep шаблонов, чтобы увидеть, где они используются. Этот подход определенно рекомендуется, особенно для ссылок, которые вы будете использовать много.

Запрос и ответ

Когда вы создаете приложение Slim, вы часто работаете непосредственно с объектами запроса и ответа. Эти объекты представляют собой фактический HTTP-запрос, полученный веб-сервером, и возможный HTTP-ответ, возвращаемый клиенту.

Каждому маршруту Slim-приложения присваиваются текущие объекты запроса и ответа в качестве аргументов его обработчика. Эти объекты реализуют популярные интерфейсы PSR-7. Маршрут Slim-приложения может проверять или манипулировать этими объектами по мере необходимости. В конечном счете, каждый маршрут приложения Slim ДОЛЖЕН вернуть объект PSR-7 совместимого ответа.

How do I add middleware?

You may add middleware to a Slim application, to an individual Slim application route or to a route group. All scenarios accept the same middleware and implement the same middleware interface.

Application middleware

Application middleware is invoked for every incoming HTTP request. Add application middleware with the Slim application instance’s add() method. This example adds the Closure middleware example above:

This would output this HTTP response body:

Route middleware

Route middleware is invoked only if its route matches the current HTTP request method and URI. Route middleware is specified immediately after you invoke any of the Slim application’s routing methods (e.g., get() or post()). Each routing method returns an instance of \Slim\Route, and this class provides the same middleware interface as the Slim application instance. Add middleware to a Route with the Route instance’s add() method. This example adds the Closure middleware example above:

This would output this HTTP response body:

Group middleware

In addition to the overall application, and standard routes being able to accept middleware, the group() multi-route definition functionality, also allows individual routes internally. Route group middleware is invoked only if its route matches one of the defined HTTP request methods and URIs from the group. To add middleware within the callback, and entire-group middleware to be set by chaining add() after the group() method.

Sample Application, making use of callback middleware on a group of url-handlers

When calling the /utils/date method, this would output a string similar to the below

Visiting /utils/time would output a string similar to the below

But visiting (domain-root), would be expected to generate the following output as no middleware has been assigned

Passing variables from middleware

The easiest way to pass attributes from middleware is to use the request’s attributes.

Setting the variable in the middleware:

Getting the variable in the route callback:

Other Frameworks

That’s not to say these five entries are the only PHP frameworks available for microservices/API development. There are many, many frameworks the average developer has access to. Some are more fully featured than others, and some are specific in functionality to a given use case, but the wide range of frameworks available to developers is simply dizzying:

  • API Platform (PHP): The self-defined “ultimate PHP framework to build modern web APIs.” Includes support for a wide variety of Symfony bundles. Slim
  • Apigility: Developed using Zend Framework 2, and thus runs on top of the Zend Framework MVC stack.
  • Flight: designed first and foremost to be extensible and simple. Great for rapid development and deployment cycles.
  • Bullet: Utilizes nested routing callbacks, and offers a Composer for package management and autoloading. Automatically conforms to the HTTP specification requirements.
  • Phalcon: Full-stack framework designed as a C-extension. Built upon the model-view-controller pattern, and designed specifically to be “high-performance.”
  • Frapi: Frapi is designed to not be a “general purpose framework,” and is instead, according to their documentation, aiming “at removing the whole front end layer complexity that handling REST calls can bring.”
  • Recess: Rather than focusing on speed or optimization, Recess is designed to be “fun.” While it still is just as fast as its contemporaries, it’s specifically designed to do more with less code, with the idea of taking the developer out of the command line and deploy loop.
  • Slim: A PHP microframework with a fast HTTP router, PSR-7 Support, and dependency injection support that can be used to “quickly write simple yet powerful web applications and APIs.”
  • EBHub SPA Framework: A Back-End (PHP) and Front-End (Javascript) compound platform used in creating Single-Page Application including non-SPA and API projects on the web without sitting on top of another framework but easily integrates with 3rd party PHP & Javascript libraries.

The Request URI

Every HTTP request has a URI that identifies the requested application resource. The HTTP request URI has several parts:

  • Scheme (e.g. or )
  • Host (e.g. )
  • Port (e.g. or )
  • Path (e.g. )
  • Query string (e.g. )

You can fetch the PSR-7 Request object’s with its method:

The PSR-7 Request object’s URI is itself an object that provides the following methods to inspect the HTTP request’s URL parts:

  • getScheme()
  • getAuthority()
  • getUserInfo()
  • getHost()
  • getPort()
  • getPath()
  • getBasePath()
  • getQuery() (returns the full query string, e.g. )
  • getFragment()
  • getBaseUrl()

You can get the query parameters as an associative array on the Request object using .

Base Path If your Slim application’s front-controller lives in a physical subdirectory beneath your document root directory, you can fetch the HTTP request’s physical base path (relative to the document root) with the Uri object’s method. This will be an empty string if the Slim application is installed in the document root’s top-most directory.

Wave Framework

Open Source API-centric PHP Micro-framework

Like Laravel, Wave Framework is a PHP micro framework built upon the model-view-control paradigm. Wave was initially developed to focus on a small footprint and optimized speed, and has since evolved into its current form, providing built in view controllers, a website functional gateway, and a JavaScript controller.

Wave is so much more than it implies in its documentation, however — while it’s true that Wave is small and well-optimized, it has some real internal strengths governing its functionality.


Perhaps the biggest draw of Wave is that it is very, very small, but gets so much done with so little. Wave boasts some pretty impressive support that other frameworks don’t, notably supporting full UTF–8 and jQuery natively. Additionally, Wave supports a wide range of data return types, including XML, CSV, JSON, HTML, native PHP, and more.

For this reason alone, many devs love Wave. There’s an even greater reason to support it, however — Wave utilizes a top-tier security cypher, 256 Rijndael, to encrypt its entire data transmission process. While other frameworks can utilize this through a variety of additional implementations or extensions, Wave does this natively, and does it exceedingly quickly.

Wave Framework also boasts some other great features on its GitHub repo. Firstly, Wave has a great integration for documentation generation, which reduces much of the load of developers when it comes to creating these documents for users. Additionally, Wave Framework has an integrated API testing suite which could help allow rapid development, testing, and iteration of APIs.


The biggest negative, however, is the fact that it’s so different from other implementations. With so many frameworks being based on previous efforts, such as Laravel and Lumen, having a novel approach is both a blessing and a curse, requiring developers to essentially relearn what would otherwise be implied in other frameworks.

Additionally, while it supports an impressive amount of data types and formats, it does lack a lot of additional functionality some developers might expect from their implementation. While this is largely determined by the scope and scale of your project, this does present a problem in terms of long-term scalability. Not every project is designed from the beginning with the end state in mind, and so as development continues and the project scope increases, utilizing this framework might result in a lot of “but the framework doesn’t support this” conversations.

You can certainly get around this by adding additional implementations, extensions, etc., but at a certain point this becomes untenable. This isn’t necessarily a problem with the framework itself, of course, but it’s definitely something to consider. Wave Framework, perhaps more than any other framework on this list, is truly a “micro” framework.

API dev walkthrough: Building APIs on the JVM Using Kotlin and Spark

The Request Body

Every HTTP request has a body. If you are building a Slim application that consumes JSON or XML data, you can use the PSR-7 Request object’s method to parse the HTTP request body into a native PHP format. Note that body parsing differs from one PSR-7 implementation to another.

You may need to implement middleware in order to parse the incoming input depending on the PSR-7 implementation you have installed. Here is an example for parsing incoming input:

Figure 9: Parse HTTP request body into native PHP format

Technically speaking, the PSR-7 Request object represents the HTTP request body as an instance of . You can get the HTTP request body instance with the PSR-7 Request object’s method. The method is preferable if the incoming HTTP request size is unknown or too large for available memory.

Figure 10: Get HTTP request body

The resultant instance provides the following methods to read and iterate its underlying PHP .

  • getSize()
  • tell()
  • eof()
  • isSeekable()
  • seek()
  • rewind()
  • isWritable()
  • write($string)
  • isReadable()
  • read($length)
  • getContents()
  • getMetadata($key = null)

Route strategies

The route callback signature is determined by a route strategy. By default, Slim expects route callbacks to accept the request, response, and an array of route placeholder arguments. This is called the RequestResponse strategy. However, you can change the expected route callback signature by simply using a different strategy. As an example, Slim provides an alternative strategy called that accepts request and response, plus each route placeholder as a separate argument.

Here is an example of using this alternative strategy:

Alternatively you can set a different invocation strategy on a per route basis:

You can provide your own route strategy by implementing the .

Типы веб-фреймворков

У фреймворков есть две основные функции: работа на серверной стороне (бэкенд) и работа на клиентской стороне (фронтенд).

Фронтенд-фреймворки связаны с внешней частью приложения. Простыми словами, они отвечают за внешний вид приложения. Бэкенд отвечает за внутренне устройство приложения. Рассмотрим оба типа поподробнее.

Серверные фреймворки. Правила и архитектура таких фреймворков не даёт возможности создать веб-приложение с богатым интерфейсом. Они ограничены в своей функциональности, однако вы всё равно можете создавать простые страницы и разные формы. Также они могут формировать выходные данные и отвечать за безопасность в случае атак. Всё это определённо может упростить процесс разработки. Серверные фреймворки в основном отвечают за отдельные, но критически важные части приложения, без которых оно не сможет нормально работать. Вот несколько самых популярных фреймворков и языки, с которыми они работают:

  • Django — Python;
  • Zend — PHP;
  • Express.js — JavaScript;
  • Ruby on Rails — Ruby.

Клиентские фреймворки. В отличие от серверных, клиентские фреймворки никак не связаны с логикой приложения. Этот тип фреймворков работает в браузере. С их помощью можно улучшить и внедрить новые пользовательские интерфейсы. Фронтенд-фреймворки позволяют создавать разные анимации и одностраничные приложения. Все клиентские фреймворки отличаются по функциональности и использованию. Вот некоторые из них:

  • Backbone+Marionette;
  • Angular;
  • Ember.js;
  • Vue.js.

Все эти фреймворки используют JavaScript.

Многофункциональные фреймворки. Meteor известен как фулл-стек веб-фреймворк. Это значит, что он удовлетворяет почти все потребности как со стороны клиента, так и со стороны сервера, что делает Meteor чрезвычайно популярным. Вам не нужно тратить время на то, чтобы наладить взаимодействие между двумя фреймворками через REST API — вы можете просто выбрать Meteor и ускорить процесс разработки. Но это не главная особенность этого фреймворка. Обе стороны — серверная и клиентская — работают на одном языке, поэтому вы можете создавать и использовать для них один и тот же код. Следующая особенность — «режим реального времени» — когда вы что-то меняете в одном интерфейсе, изменения происходят и в остальных. В качестве примера можно взять документ или таблицу с общим доступом. Когда вы добавляете комментарии или как-то изменяете содержимое, другие пользователи тоже это видят.

Frontend developer (Vue)

Sportmaster Lab, Липецк, до 130 000 ₽


Вакансии на tproger.ru

На этом о разделении на типы можно закончить, однако масштабы тоже важны. Фреймворки также отличаются по размеру. Существуют такие монструозные фреймворки, которые предлагают решения для всех задач.

Более легковесные варианты специализируются на решении конкретных задач — такие фреймворки называются микрофреймворками. Они не предоставляют «из коробки» всё, что нужно, однако иногда лучше разложить функциональность на несколько подоходов (фреймворки, микрофреймворки, библиотеки). Функциональность микрофреймворков можно расширять с помощью сторонних приложений и создавать небольшие проекты на их основе или совместить микрофреймворк с основным «большим» фреймворком.

Например, если ваше приложение основано на Django и вам нужны веб-сокеты, то вы можете воспользоваться микрофреймворком aiohttp.

Другой пример: если ваше приложение не очень большое и вам нужна только простая маршрутизация URL и шаблоны с несложным контекстом, вы можете использовать Flask с Jinja2 (или другим шаблонизатором) вместо Django.

Route callbacks

Each routing method described above accepts a callback routine as its final argument. This argument can be any PHP callable, and by default it accepts three arguments.

  • The first argument is a object that represents the current HTTP request.
  • The second argument is a object that represents the current HTTP response.
  • The third argument is an associative array that contains values for the current route’s named placeholders.

Writing content to the response

There are two ways you can write content to the HTTP response. First, you can simply content from the route callback. This content will be appended to the current HTTP response object. Second, you can return a object.

Closure binding

If you use a dependency container and a instance as the route callback, the closure’s state is bound to the instance. This means you will have access to the DI container instance inside of the Closure via the keyword:

Heads Up!

Slim does not support closures.

С этим читают