There are some functionalities in server side that are necessary to be exposed to mobile and desktop interface What should we do?
Should we create a new operation in the API with more data that we can use in both interfaces?
No, it is not a good idea.
Because of the nature of this interface is different, the experience to mobile user and web user is different.
In mobile interfaces there is less space in screen, so we should expose less data.
Opening lots of connections to server-side resources can drain battery life and limit data plans.
Therefore, our mobile devices will want to do different calls, less calls, and maybe show different data summarized those desktop devices.
Another problem is that just one backend API, can become a bottleneck to release new versions, because it can have many changes in the same API to many consumers and to detect possible bugs or errors could be a problem.
The tendency to API in general is to have multiples responsibilities, so it required much work, and sometimes is necessary creating teams to care this base code.
This can become a problem worse, front-end team and back-end team have to interact with different team to get changes, to expose operations and to consume operations, now there are three different teams to align the same priorities.
Backend for Frontend Pattern definition:
The application should be returned to user with two different components, one to mobile device other to desktop devices, and should be keeping with specific team, mobile team should keep their API and desktop should keep their API.
If this way is easier adjust to kind of client.
Release time can be diferent:
It was created to care to several consumers that we have nowadays to the same system, where each one have a requirement.
BFF is focused in a just only user interface, and that it.This allows that to be exclusive consequently will be less.
When it is delivered the same user experience to different platforms, there are two ways.
it can be utilized with call aggregator to parallelize calls, and it could reduce battery and band to mobile interfaces.
Working with failures on services:
In this example if inventory is down, it is not necessary interrupt the user actions, when service is available again, the users can consult the product inventory that was selected.
The same possibilities in above BFFs diferentes, in this case we can use an aggregator to call the common services
Where do we want to go? Evolution of the BFF
We can limit the numbers of consumers according to the device.
This can work with changes.
Helping development teams to become more focused to his costumer, giving more autonomy to each team.
Each team can control their future, providing specialty for your type of consumer.
Basically the idea of SOFEA is, we should stop do downloading from the server side, and send this responsibility to client side.
Propose removing all the logical presentation of the service side, and move these logical to Java Script and to client side.
Because with the SOA (Service Oriented Architecture) maturity and browsers evolution, we can change some ways that we work in the front-end side, and utilize more the client machine.
This architecture style is precisely to application web in SOA and Cloud environments.
It is intended to revolution that was brought from SOA on back-end to the front-end.
We treat all communication server with web service by way of REST or SOAP for example, is possible the server-side to focus just in business, and being exposed in format of service.
SOFEA can be synonym of Single Page Application, and should not be confused with Framework or implementation, is style architecture.
What is Single page Application (SPA) in this story?
Why should we underuse the client side and overload the server side?
Why not balance this load?
Is is possible to improve the user experience with these techniques?
Why just now appears SOFEA?
Because the Java Script engines to browser and AJAX toolkit has a great development in recent years.
The client-side frameworks had a great evolution as well.
Simplicity in client-side.
More heterogeneous team.
Mobile client are growing every day.
In the picture below it is possible to see where living the older web frameworks.
Life cycle in the older architectures.
SOFEA life cycle:
Where the components living in SOFEA?
Some frameworks that implements Single Page Application are:
Scalability, because service has less work, and just process the business logic.
Better user response, low latency, because after app download, just data travels.
Organized programming model,it is possible have a team just for client-side and other to server-side
Interoperability, easy integration with many platforms, clients doesn't matters for the service language
Higher ROI, is possible reuse more services
This architecture style impulse the web 2.0, this is the one of the many techniques, movements, culture that offers a new perspective to client-side, so, is important to know them instead of just use and choose the fashion frameworks.
Docker Cloud is a hosted service for Docker container.
With Docker Cloud is possible to do management,orchestration and deployment of the container in some Cloud Providers. These type of product is classified with as CAAS, Container-as-a-Service.
It was acquired by Docker in the ends of 2015, and this project was called tutum.
Some features available in the Docker Cloud:
Provision Docker Installed Infrastructure
Manage node clusters
Pull images from Docker Hub
Deploy containers across nodes
Monitor and scale applications
Client : HTTP, Command Line Interface,Go,Python,UI DashBoard
It is possible to create, deploy and managing applications as well as start, restart, destroy containers.
These service are free for just one private repository and one parallel build.
The could providers available are:
Amazon Web Service
To use Docker Cloud for the first time is very easy, they have a tour that shows step-by-step what it should do like, link a cloud provider, deploy a node, create a service, create a stack and use image repository from docker hub. All these steps are itemized with hint on each label.
How does work?
In my test I used a cloud provider AWS.
When clicked "create", was showed the Stack that I choose appeared listing the container that will be deployed.
After that the next step was creating the Node Cluster. This node cluster is a one EC2 in AWS, in this EC2 will be installed Docker machine, and in this Docker machine the containers will be deployed .
When this step concluded, this Node Cluster, will be showed with State running in Docker Cloud Node panel and Running in AWS Console.
Be careful , because the Security Group by default blank, it means in AWS connection TCP inbound , opened in all ports.
At this moment it is possible to start the container available the Stack Panel.
If you click in the container with web it is possible to click to see the application web running.
Another option to deploy,or manage containers is by command line interface.
The steps for these are:
1. install docker-cloud - Mac OS: brew install docker-cloud - Unix: pip install docker-cloud 2. docker login // docker hub account 3. mkdir devops-cafe //create dir to DockerFile and code 4. main.go // code that produce hello world in por 80
5. create DockerFile
6. create Docker Compose
7. docker build -t devops-cafe . 8. docker tag devops-cafe rafaelsalerno/devops-cafe 9. docker push rafaelsalerno/devops-cafe 10. docker-cloud service run -p --name web rafaelsalerno/devops-cafe // after this command the container should be running
11. docker-cloud container ps --no-trunc --service web //check containers running
12.docker-cloud service scale web 2 // deploy more 2 container with the same application
In this brief contact with the Docker Cloud, I could see that this tool makes life easier when we want work with Docker integrated with AWS.
The command line is powerful, the Dashboard is simple and objective to work.