Existence of V1 (the very first version of our solution) actually shows our hope that one day we will be “allowed” to be working on V2!<\/p>\n
Tech debt<\/strong><\/p>\n https:\/\/en.wikipedia.org\/wiki\/Technical_debt<\/a><\/p>\n There are ugly parts, we know, we deliver something quickly under pressure – but it works (for now). Most of us don’t “see” them. It is usually because of lack of sufficient experience in the field.<\/p>\n Most managers don’t “understand” technology; never mind the technical debt!<\/p>\n If they are not willing to give us time, we have to (sneakily) over-estimate the new features requested in order to be able to resolve technical debt gradually. In the worst case, we may be required to shut the “business” for maintenance!<\/p>\n Don’t be naive!<\/strong><\/p>\n Long time ago, I caught a “naive” looking SQL bug in a system I was working on:<\/p>\n When I printed it on a MS Word document, the team was shocked: it was over 100 pages long! The query was over 2MBs. MySQL server was not happy: it rejected the query because it was configured<\/a> to reject payloads over 2MB!<\/p>\n Once I crashed a MySQL server when I tried to add a column to a table!<\/p>\n In the past, MySQL server developers were also naive: they did not check the disk requirements of DDL commands before executing them.<\/p>\n Refactor<\/strong><\/p>\n Another time, a system we developed almost stopped working after I went on holiday! I had to spent 2 weeks in & out of an internet cafe trying to find and fix the issue. Firebird SQL database server struggled with the load when there were “many” records in a table. We were using triggers<\/a> inefficiently! A trigger can work perfectly for a single row but it may not work as expected for many rows. We had to move the logic to the application server and optimise the business logic.<\/p>\n A database is usually the bottleneck in a classic 3-tier architecture: App, API, DB. Take advantage of using multiple API server instances and use their computational power.<\/p>\n Test, test, test! … and automate! … but moderate!<\/strong><\/p>\n When a solution works for most of our test scenarios, it does not mean that it will work 100% of the time: one day it will need to handle a case that could happen 0.1% of the time.<\/p>\n It’s about considering moderation: we can not automate every task. We should keep an eye on upgrade operations – i.e. software releases in production environments.<\/p>\n Don’t be a fanatic!<\/strong><\/p>\n We must see the imperfections of our stuff! We should know about the pros & cons (or limitations) of our solutions; the software libraries, frameworks, systems that we rely on. We should be able to talk about them without twitching!<\/p>\n GraphQL<\/a> is the best way we can create an API these days.<\/p>\n Pros<\/strong><\/p>\n Cons<\/strong><\/p>\n ol><\/p>\n BTW, there is NO V1 in GraphQL world \ud83d\ude09<\/p>\n
\nSELECT *
\nFROM [a-table]
\nWHERE id IN (...[parameters])
\n<\/code><\/p>\n
\nALTER TABLE [a-table]
\nADD COLUMN [a-column] VARCHAR(100);
\n<\/code><\/p>\n\n