In this chapter, we will see an overview of what we are going to build through this book, a social network. Also, we will cover the technical solution chosen to build it from scratch and thereby getting the most out of Zend Framework 2.
By the end of this chapter, you should have a good understanding of how the API-centric approach works and a clear picture of the project that we will build through this book.
Zend Framework 2, as you might know, is a framework that allows you to build applications using the components provided. The framework uses the best practices of the industry and the components are extensively tested and proven to be good. This means that you will build your application on top of a robust base.
The benefits of using a Zend framework against using your own framework is that you benefit from the knowledge of all the contributors of the project. Also, it will be easier to get more developers on board as it's a known framework with the documentation available online, and there are a lot of people who already know it or have worked with it.
The objective of this book is to show you as many components of Zend Framework 2 (ZF2) as possible. In order to achieve this, we will build a basic social network that will allow the user to post text, pictures, links, comments, and so on. This will cover all the basics of the framework and also demonstrate the usage of the majority of the components in common real-life scenarios.
Let's see all the functionalities and sections this social network will offer to the users.
The user wall will be the main section where users can share content. Users will be able to post text, images, and URLs.
By building this section, we will experiment with the first request and building blocks of ZF2, and in the meantime we are going to see the technical approach chosen for the project in action.
Users will be able to post text on their wall and also on their friends' walls using a simple form. To accomplish this, we will have a look at how forms work and how to use filters and validators to ensure that the data is secure and correct.
Pictures are one of the forms of media shared extensively by users of social networks. In our case, we will give users the opportunity to do this. On implementing this functionality, we will see how the new Zend\Form element handles the upload of files, and how to process them.
URLs are the last thing users will be able to share on the profile. A description will appear automatically with the link. This functionality will allow us to discover how to crawl contents from remote websites, filter them, and store them.
People also enjoy commenting on the content of others people and we will give the user a way to do this on our social network. An interesting part of ZF2 will be used in this section to fight spam. We will see how to use third-party services using Akismet.
Building news reader is a big section on the project. From here, the user will be able to add, remove, read, and organize RSS feeds. We will use Zend\Feed to do basic RSS actions and provide the frontend with data.
A basic action that users should be able to do is register and login to the social network. We will provide them with the forms to do this. We are going to integrate the session handling through Zend\Session and the login functionality using Zend\Authentication on this project.
Another functionality that social networks provide is keeping the user updated about what is happening while he/she is away. We will implement a notification system and also a way to recover the password if you lose it. On building this section of the project, we will see the Zend\Mail component in action and how to use it to send e-mails.
The last functionality we will provide in our project is the ability to integrate our data and functionalities in other projects. In order to accomplish this, we will expose our API to the outside world using OAuth 2.0. Here, we will learn how to put an OAuth 2.0 authentication mechanism with ZF2 in place.
To build the social network, we will use an approach called API-centric. First of all, for those who are unfamiliar with the term API, it is an interface that we build to expose functionality. By doing this, we allow other applications to interact with us. For example, a news website can expose an API to allow people to retrieve articles from their archive by specifying the date of the article, the author, and so on.
An API-centric application is an application that executes all functionality that make calls to an internal API. For example, if a user on our social network is going to post a picture, our app will pass the image and details of the user to the API to execute the actual steps needed to store the image and publish it on the user profile.
The API-centric architecture looks like the following figure:
As you can see, API is the central point and everything else is built around it. The web app, the mac app, and so on are the clients that consume API. Now, let's compare the lifecycle of a request between an app-centric approach and a traditional model.
As you can see, in the traditional model you made requests directly to the server. The server in this case contains the logic of the client and also the business logic. In the API-centric model, the request is made from the browse to the client app; this application can be on the same server as the API or on a separate machine. Then, the client app will issue a request to the API. After this, the request will go back to the client app and finally to the user. In this case, we are separating the code of the client app from the code of the API. The client app acts as a proxy for the API that has the business logic. Note that the image doesn't represent the time spent on the request.
Since the explosive increase in the usage of smartphones, an increasing number of web applications have ended up with an application on the phone. Some of themjust adapt the website to the phone screen size by removing or redesigning the interface, while others choose to build a native application that will run on the phone of the visitor.
The first benefit of this approach for our social network is that the core of the application is just an API and all the related clients will rely on it to use the functionality. This means we have a good separation of concerns, and we will have separated the business logic from the client logic. This will allow us to create a website to access the service and the possibility of building a native application for mobile phones or even a desktop program using the same API in future.
The second benefit is that the API is stateless; this means that the calls made to the API will not include anything about the session, and there is no session handling/management involved. This sounds wrong at the beginning but allows the developer to build a RESTful API that will not rely on the state of the user session or data stored on the session.
Note
RESTful is the application of the REST architecture in web services. REST is an architectural style for designing networked applications. The idea behind it is to avoid complex mechanisms and use plain HTTP. A typical RESTful web service will use HTTP to do the four CRUD (Create, Retrieve, Update, and Delete) operations.
Another benefit is that the code can be tested further as you don't have to recreate the whole user session in order to test a functionality.
If we take a look at this approach from the server-side point of view, we can see some benefits; as we are separating the responsibilities of every component, we can assign different machines and resources to each of them. This way of organizing the servers allows us also to scale the components we need independent of the others.
One downside of the approach we can easily see is that if the API goes down, everything will go down and the clients will not be able to do anything.
In this chapter we saw the concept of the project that we are going to build throughout this book. We also described in detail each part of the social network, the functionalities that will be available to the user, and the components that we will learn on building each section.
We also introduced the technical approach that we will use to build the social network, how it works, the benefits and downsides of using it, and why we choose this option instead of a more conventional one.
