Architecture of psbFinances

Every time you start a new application, you ask yourself: what should I use to build it. Should you stick to what you know or use something new. I’ve made a few decisions about the architecture of psbFinances. For the last 9 years I’ve been working with node.js, React and MySql. I’ve built platforms for 6 startups with this stack. That’s what I used for psbFinances. But there was a couple of decisions I’ve made “inside” this stack.

Note that React is becoming less obvious choice for me these days, but that’s another topic.

TypeScript (TS)

I am big fan of Anders Hejlsberg. I was working with C# since he introduced its first beta. Even before that I’ve used his Borland Delhi. When he announced TypeScript in 2012 I was very interested. He gave many reasons why TypeScript was developed. Great tooling support (like IntelliSence, code completion) was one of them. Since then I was checking the growth of it and was asking myself whether I should use it for my projects. I’ve asked the same question many teams that I’ve lead: “should we go with pure JavaScript or with TypeScript”. Interesting situation. JavaScript developers wanted to have static typing. At the same time more C# developers were asking for dynamics.

9 years ago most of the JavaScript IDE didn’t have a good support for it. But the situation has changed a lot since then. I use WebStorm. It has a very good support for pure JavaScript development, especially in combination with JSDoc. Visual Studio Code has a great support for it too. For me using JSDoc makes code less verbose and cleaner compare to the type annotations in TS.

As for the static code analysis. Incorrect types add only a minor number of bugs that I discover in my and my teams code. Most of the bugs are in the logical flow. Type validation is also address as part of unit tests.

TypeScript allows to use the latest features of JavaScript. Browsers and node.js may not support these features yet. But you probably use Babel and that solves this issue.

That’s why I’ve decided against TypeScript for psbFinance. I don’t see enough benefits to use another “super” language on top of JavaScript.

Some developers say that “you can’t build large-scale application without TypeScript”. That’s not true. Large scale application can be built using any language. I’ve seen quite enough of them built with different languages. It’s not about language. It’s all about the skills and discipline of developers.


That was another tool I decided not to use. I use REST API. A debate of REST API vs GraphQL reminds me a lot about the discussion between backend developers and DBAs. DBA didn’t trust developers to be “gentle” with their databases. They insisted that database should be accessed via stored procedures only. That make sense. To some extend. “With great power there must also come great responsibility”. That debate was won by developers who now can write direct SQL statements or use some ORM helpers. I was never in the DBAs’ camp, even though I’ve done a lot of DBA work. For developers that power of accessing database with pure SQL is great. But some of them didn’t accept the responsibility. Many times I’ve seen lazy SQL code that degraded performance and introduced security issues.

That’s why it looks the same for me with GraphQL If you built multiple applications with REST API then you know how to address some challenges.

I am not saying that GraphQL is bad or that it should not be used. Far from that. What I am saying is that based on my experience and skills it doesn’t give me any significant benefits while introducing some complexity. It also means that the potential pool of developers who can contribute to psbFinances becomes smaller – not everybody know it.


TypeScript and GraphQL are great tools. They can be very useful in the right hands. But for me they don’t have enough benefits to use in this project. Check the code and you can see that it’s ok to live without them.

So you want to be a software architect. Part 3

In the second post I’ve shared my thoughts about the most important skill that architect needs if he wants to see the materialization of the design. Today we will go over the ability to identify the risk and commitment to the priorities.

Identify risk

As you design the application or subsystem, it’s important to see what the risky parts are. Before you hand the design over to the development team, you must be sure that risk and unknowns were investigated and resolved.

Let’s take a look at an example. In order to speed up the development of the new versions of the product, you need to transition from a monolithic architecture to a Service-Oriented Architecture (SOA). You know how to split your business functionality into multiple independent services. You addressed the issue of internal routing and load balancing. But what method should be used to communicate among the services? There are many approaches. SOAP will be an obvious choice. But this will require your team to learn new skills of building SOAP-based services and operation team to deploy & maintain them. Maybe it’s not a big deal, of course. But you consider to build internal SOA using AJAX/Json services because your team is already familiar with this approach building Web application and operation knows how to deploy and operate them. But what about the performance? It can be slower than other SOAP approaches. Unless you measure and compare performance of both approaches, and than agree with the team that the performance “penalties” are acceptable because of the advantages that the team will utilize the existing skills, you will be risking the transition to the new architecture and delivering it on-time and with high quality. In this case you should measure first and build then, not build first and then test and measure:

  1. Identify the risk
  2. Investigate it
  3. Find alternatives
  4. Agree with the team about the approach
  5. Do it

Risk may present itself in many areas – team skills, complexity or stability of the 3rd party components that you plan to use, performance of the algorithms, scalability path and so on. By “realizing’ the new architecture in your head, identifying the risk as part of the design and addressing it in the earlier stages, you will be able to deliver the design that will be successfully implemented by the team. 

Commitment to priorities

Each new project or release has priorities, Usually they are:

  • time
  • quality
  • scope
  • resources

Priorities are defined by the management and driven by the business needs. And if they are not defined, then you should ask for them. Very often the resources are fixed – your team has the same number of people. Out of the other 3 you can balance only 2 and have to sacrifice one of them. For example: with limited time, it’s not possible to deliver all the features with high quality. And it’s easy to forget about the priority #1, if let’s say it’s time, by creating a perfect design or design an interesting feature (both take time). You have to deliver according to these priorities, even if you disagree with them sometimes. 

(To be continued)

So you want to be a software architect. Part 2. Important.

Last time I’ve started talking about the skills that I think are required for a software architect. The plan was to go over other skills, leaving the one I consider the most important (as of today) for the last. But I think that this should go first.


Software architect must be able to influence other people, if he wants to see his architecture properly implemented in the final product. The last condition (proper realization of the architecture in the product) is important point whether architect should influence people or not. You see – if architect is only interested in just a set of UML diagrams that she passes to the development team and doesn’t care about the final product, than she should not worry about the influence. Because these diagrams are her final product. If this is how you see your role, than you can skip this post.

Why influence is important? In most companies developers and QA do not report to architect, they report to development/QA managers. And these managers do not report to architect. So, if manager decides to change the way that product should be built than it may be way different than what you have envisioned. And there is not too much that you can do about it. Because even a junior developer will do what he is told by his manager and not by you. This is why the only way for you to see your design in the final product is to “convince” a manager how it should be built. Otherwise you can be very disappointed (if you really care about the final product):

Your vision Actual product
84A613BA-AC7B-4EC0-8ACB-CC426098D71A 9F3C3243-EA51-4DA2-93D9-865CA009C13C

Thus, the most important skill for a software architect has nothing to do with technologies, but rather with their “political” ability to achieve their goal. You have to be a “politician” in order to see the final product the way you’ve envisioned it. And sadly enough it’s even more important than your technical skills to design it. Of course, it depends on your company, but keep this in mind.

(To be continued)

So you want to be a software architect

There are many opinion about what software architect does, what skills are required and whether we need them or not. I’ve been in this role for a long time (20+ years), even before I’ve “acquired” the “official” title. I was lucky because a year after the graduation I’ve build the whole application – gathered requirements, architected, designed, coded, tested, operated the application as well as provided customer support. Since then most of my life I was building the complete application rather than working on its pieces here and there. And that’s how I’ve learned it at the first place.

First, let me be clear – I think that architect is required and important part of any software team or “part” of you if you are a MicroISV. And it doesn’t matter whether this person is called architect or engineer or he-knows-how-to or somehow else. There should be someone who knows how to build the whole building, not just superbly paint a single room.

So, some of my thoughts about the skills that good architect needs as well as pros and cons of this role.


Know how to do it yourself

I think that if you cannot sit down and write the whole application that you are designing yourself, there is a very slim chance that it will be designed properly, because when you design/architect an application, you actually write it in your head.

E2E knowledge

Architect has to know it end to end. From understanding how the business works to the work of customer support and everything in between (requirements, design, development, QA, operation). Without this knowledge it’s difficult to build application that will add value to its users, will be delivered on time, have a reasonable cost and will make the team happy. And this leads to the next required skill.

Side note: why did I put team happiness in this list? Long story short: in a long run happy team makes great product, unhappy team – crap.


Meeting these requirements (value for the customers, time to market, cost and team happiness) during the whole lifecycle of the product is difficult.

  • Should the product quality be sacrificed to ship it on time? 
  • Should additional development effort be allocated to make a tool for operation team which will make operation easy? 
  • Should some components be build in house or purchased?
  • …..

Architect faces these questions every day. And the quality of the final product depends on his ability to find optimal solution – find a win-win path.

Keep it all in your head

You should be able to store the whole application in your head. You may not remember all the details, but overall layers, tiers, components, data and execution flow as well as storage design is a must. Application is a composition of multiple pieces (layers) and without seeing the “whole picture” it is difficult to build well balanced application. E.g.: design of particular database tables may be perfect from a DBA perspective, but will require a lot of unnecessary and badly performant code in data access and business layer.

Review code fast

High software quality is not only guaranties the happiness of your customers (functional quality), but also how fast you can deliver new features (structural quality). If your application has 0 bugs, but code is ugly and architecture resembles Winchester House, then there is no way you can add functionality fast. But how can you ensure high structural quality? Yes you can have all these static code analysis toolsin place and they help. Too some extend. But the only way to guaranty a high structural quality of your application is to review all the code. “I don’t have time to review all the code that is checked in?“. Yes you do. It takes 30 minutes to review regular check-ins of a 10 developers team. If you know how to do it right and if you teach your team to write good code (I’ll share my experience later). 

And don’t fool yourself – sooner or later you will review “that” code, because when it breaks one day badly or prevents your from adding a new functionality without total rework, you will have to review & clean it up. So, better do it daily when it’s easier to spot a small problem and fix it early.

BTW, if you know a better way to ensure high structural quality, please let me know.

(To be continued)