In the previous article we finished one Polymer Web Component. It contained a form that could be used to add, update and remove books by sending HTTP requests to the back-end server. We also explored few different ways to interact with the component from outside by calling its functions.
In this article we’ll create the second component that will be used to list all the books and send custom events to open an existing or a new book. Those events will not be sent directly to the component we built earlier but to the document the component will reside on. We’ll get to that part in time…
In the previous article we created our first Polymer Web Component using Test-Driven Development approach. While all the specifications we wrote were implemented, there are still few things we should do to polish this component. The tc-book-form currently has the form with all the input fields required by the back-end. It also has buttons to add or update and delete a book. Those buttons are calling iron-ajax Polymer element that sends requests to the back-end. Both front-end (in form of Web Component) and back-end are developed as a single microservice.
The next task in front of us is to polish the component. Later on in this series we’ll create another component that will list all books. We’ll also develop the code that will enable us to establish communication between those two components. Once we’re done with both, we’ll explore ways to integrate the microservices we developed into a separate Web Application.
In this article series we’ll go through Web Components development in context of microservices. We’ll use Polymer as the library that will help us out. The objective is to create a microservice that will handle full functionality. The service will contain not only back-end API (as is the case with most microservices) but also front-end in form of Web Components. Later on, when the time comes to use the service we’re creating, we’ll simply import Web Components. That is quite a different approach than what you might be used to. We won’t create a Web Application that calls APIs handled by microservices. We’ll import parts of the front-end from microservices. Our objective is to have a microservice that contains everything; from front-end to back-end. Please refer to the Including Front-End Web Components Into Microservices article for more information that lead to this decision.
I am a huge fan of Test-Driven Development so we’ll write all the code using test first approach. We’ll write a test, run all tests and confirm that the last one fails, write implementation, run all tests and confirm that all passed. Tests will act as executable specifications. We’ll use them to define what should be implemented. If you are new to TDD and the concept of executable documentation, please read the article Tests As Documentation.
A programming kata is an exercise which helps a programmer hone his skills through practice and repetition.
Tests that prove that the solution is correct are displayed below. Recommended way to solve this kata is to write the implementation for the first test, confirm that it passes and move to the next. Once all of the tests pass, the kata can be considered solved. Continue reading →
There’s a lot of discussion related to server vs client side application rendering. While there is no “one choice fits all” solution, I’ll try to argue in favor of client side (specifically AngularJS) from different points of view. First of them is architecture.
In the previous article we developed the back-end solution for our books application. This article will continue where we stopped.
We’ll develop a front-end solution that can be used with any back-end (Web, mobiles…). You can build on top of the back-end from the previous article (Java, Jersey, Grizzly…) or on top of any other as long as supported services are the same.
The goal of the application is to be able to administer books. In particular, we’ll develop the front-end solution for that application that should be able to: