The structural strength of steel

The last article about the discussion of two "black-belted" TOGAF architects about the nature of architecture management finished by the words of "A good building architect needs to know the structural strength of steel before they design in it," Let's see some practical examples of 'steel' together!

In the past years I was working in many different projects, where the team had to decide about different technologies and facing with the issues of deployments, the automated testing. It was also a big question if we would use cloud IaaS or PaaS solutions, what are the challenges and the limitations there.

In the near past I spent some time to actualise my knowledge as an ex-developer, using some modern languages, playing with the Cloud to collect some hands-on experiences, which simplifies to understand the aspects of developers and infra people. And certainly simplifies me to design good solutions and to be 'armoured' for the potential arguments of the future.

The article would not be the final through, I do not want to say that the technologies I tried are the best. The message is, that being an architect you have to be prepared to know enough about 'steel'. One way to get prepared is to make something from 'steel', which certainly not the only way, but this is the approach I personally believe in, better than the classroom-only approaches.

Front-end development

I heard about Angular about two years before, when developers suggested to use it to develop a brand new front-end application. At that time I started a course to learn a bit about it, which was great and gave me enough to approve the suggestion. The project was successful, which Angular as a language had its own values. On the other hand I do not like to left things half made, therefore I rewarmed my training and finished it in the near path. Using what I learned there I built an address selector component, which you can try at asdemo.architectarchers.com. Depending when you will tray this, you may still find some displaying problems (for example using Chrome on Windows), but don't care. The target was to have a responsive, reusable component, which is design to be ready to integrate into any other web front-end. The main target was reached, the known small bugs will be fixed in the future.

The game showed those - I would say certain - problem, that a web development is about the half of CSS magic, what is the same using any kind of languages. Parallel to learn Angular I spent significant amount of time to deepen my CSS practice. There is a great thing, that you can use prepared libraries like Bootstrap, which gives nice looking and responsive classes to format your content.

As I went forward with the development I defined filtered-dropdown component, which is the used for all the fields on the form - again a reusable result. You may feed it with an array, which must have a field called name, what is used to display the array as a list. The filtering, the auto-select in case of single item fits to the filter is implemented in the dropdown component. It was so interesting to reach, that width of the dropdown list must follow the width of the form contain it. It was a superb lesson of learning HTML and DOM behaviour.

To make the UI work, it has to contain a special component called Service, which is responsible to communicate with the server. Originally my service contained hardcoded lists and as the UI was finalised I can turn it to really communicate with a server component, which is another interesting story.

Communicate with the server

Server communication would mean a  REST calls and processing their results. It was so good that there are prepared libraries for this manner, which only should be learned to use... This portion is the Reactive programming part, which is a standalone profession itself if you would go into all of its details. The only tricky part was, that Angular has Reactive (parallel to the Template-driven forms), which has no relation to RxJs library covering the reactive communication capabilities. Bit disturbing but manageable curiosity.

The training I made used http://jsonplaceholder.typicode.com/ which has many APIs you can use for free in the course of developments. In my case I used them to handle REST calls through Observable logic (which is the way of handling asynchronous operations in Reactive programming), while the responses were dropped and the hardcoded lists, which I prepared in the first round was used. Anyway having this approach I accomplished my code to communicate with a real REST component on the Service side and to handle the Observables on the functional side.

Server side component

At this stage I had to start implementing my server side component, which delivers the address data to the my forms. I decided to use Java for this manner, using Spring Boot framework to implement my own REST APIs.

Using Spring, the server side seemed to  be much simpler to implement then the front-end part - no magic: there are no responsive problems, no questions about filed relations, catching UI events, and so. Simple request-response logic to implement. First I copied hardcoded address data from Angular Service to my Java code, no database at this stage. Eat the elephant from bite to bite...

After the database was set up I had to connect and read data from there. As the database I selected is Redis, I used lettuce.io Redis client. In Redis I stored JSON structured data, which I would process in the server component to be prepared to change the data, like filter out fields, which are not necessary on the UI. For this processing another library I have to mention, which is GSON, which is made to serialise and deserialise Java object to (and from) JSON.

Database

To store and access the data I wnated to play with NoSQL databases, since I did not have enough experiences with them before. Past facts drived me towards Redis, which is a great tool and have a practical web page where you can start learning Redis in practice: redis.io. In Redis I selected the set (for zip code list) and sorted set data types. In case of sorted set the score is used as ID for the city records for example. Speed is great, simple to use, what else to ask for?

I loaded Redis with public zip, city, street data, this is the reason why you will not find house numbers on the form. The loader was a Java program, reading the data from MySQL (to prepare for a live database).

Platform and Infrastructure

For infrastructure and if possible for the platform services I wanted to use cloud solutions anyway. Again to gain some experiences, playing with platform providers. The good news is that there is a wide range of cloud provider, what you can select for. The most important learning was for me, that if they offer a solution, like MySQL instance it is worthwhile to use, instead of build your one on a plain server instance. everything they offer seems to be optimised for their environment, which means you do not have to care too much about. Special cases may happen, but that potentially would not be a cloud story at all. I build one thing up using Amazon S3, and an other environment at Jelastic, Unispace behind.

I enjoyed so much, how simple was to create instances, set up capacity, CPU, memory or to change them) and to manage access control rules between instances and the external world.

From development prospective it makes my life really simple, the either for Angular or for Spring there is local server components, that means you do not have to deploy to servers each build stage. For Angular ng utility (ng serve) helps, while Spring contains SpringMVC, a lightweight Tomcat instance. Both is preconfigured and you do not have to waste time to set them up, except some access control rule on SpringMVC, adding mapping rule to WebMvcConfigurer. 

OpenAPI

Next lesson was about the fabulous microservices era. It is something, everyone discussing about, but only some expert knows practically what they are, or what they would be. One approach for handling modern APIs is to use OpenAPI standard. To start defining APIs there, is again something simple. At the first time. The more you are going into the details the more problems you will face with. One thing is, which version to select? You can decide between 2.0 and 3.0. The latest would be the better selection, but today it is so far to be. The code generators behind are not that stable, and do not support that many languages as you can use for 2.0. On the other hand Swagger (which is the OpenAPI interface editor) is better to use on version 3 but you could use it to edit Open API 2.0 inside. Still Swagger 3 has only one code highlighting schema, while Swagger 2 has so many...

OK, I had an OpenAPI definition prepared, but then we faced a much larger problem with my colleague, who was involved in this "game". The code generator of OpenAPI 2.0 is buggy. THe most painful part is that it generates empty enumerations, what is a show-stopper. The next problem is, that this approach uses dozens of dependency behind and it was impossible (practically we stopped wasting more time...) to build the generated code on other machine...

Finally we changed the direction using swagger, utilising one more thing on Spring framework. There is a library called SpringFox, which generates swagger input from your java code using its given annotations for APIs, parameters and model elements. At the end you will have a ./swagger-ui.html, which shows the swagger documentation of you APIs, including that great part that you can simply test them, using the Try it out function. It still have some limitations, since only those elements of your model will reflect here, which are used by an API, but on the other hand you will have a much simpler code, all in your hands having less dependencies behind.

Development environment

For Angular I used Visual Studio Code, the data loader was implemented in pure Eclipse and the SpringBoot APIs were started in STS (Spring Tool Set), what is an Spring extended Eclipse. The java project were built using Maven. I may write additional article about this topic at all, but I saw that selecting an IDE and a build automation is the field of faith-contest - every single developer has his own best tool and setup. What they all agree that they rather use IDE and build tools than not.

Summary

It was a great journey for me. Really. The most exciting part is that all things I used was Open Source: the IDE tools, the compilers, the databases, the fantastic libraries - and the cloud also, for a given trial period! If you were not sure to start developing something as an architect I suggest you to stop hesitating and jump into the middle.

Log in to comment

Architect Archers

Architect Archers are Enterprise Architect professionals and mentors.

Our mission is to build Your Archers team while defining, aiming and hit your Enterprise Targets.

© 2017 Architect Archers