You’ve probably heard a lot of talk around a new buzzword serverless. It’s a pretty confusing name for an awesome technology/technique.

The main reason the word serverless isn’t a very good one is because it implies there aren’t any servers when using this technique. I found a fairly funny CommitStrip about this topic.

https://www.commitstrip.com/en/2017/04/26/servers-there-are-no-servers-here`

But what does the term mean then?

Well, it means you don’t have to worry about servers anymore. You just upload your software to the cloud provider of your choice and it runs on-demand/by-request. As Mark Russinovich said in an interview with InfoWorld _“I don’t have to worry about the servers. The platform gives me the resources as I need them.”. _Of course the hardware, operating system, webserver, firewall, etc. is all still there, but as a developer and operational person you don’t really have to care about it.

Isn’t this the same as PaaS from a couple of years ago?

The answer is: Yes and no!

Yes, there are a lot of similarities and the serverless offerings from each cloud provider are based upon their current PaaS offerings. Therefore, you could call it an evolution of PaaS.

No, because the ideology is a bit different.

For years we (a lot of people I know and myself included) have been using the Unit of Work and Repository pattern combined with each other. This makes quite a lot of sense as, in most cases, they both have something to do with your database calls.

When searching for both of these patterns you’ll often be directed to a popular article on the Microsoft documentation site. The sample code over there has a very detailed implementation on how you can implement both of these patterns for accessing and working with your database. I kind of like this post as it goes in great length to describe both the unit of work- and repository pattern and the advantages of using them. I see a lot of projects/companies having implemented the pattern combo like described in the Microsoft article. I can’t really blame them as it’s one of the top hits when you search for it in any search engine.

There is a downside to this sample though. It violates the Open/Closed principle which states

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

Whenever you need to add a new repository to your database context, you also need to add this repository to your unit of work, therefore violating the open/closed principle.

De afgelopen tijd heb ik het boek Clean Code: A Handbook of Agile Craftmanship gelezen.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Een interessant boek met veel tips over hoe je beter code kunt maken en opleveren. Veel van de punten die hij behandeld zijn wel bekend bij de meeste ontwikkelaars, maar toch is het wel fijn om zo’n dergelijk boek te lezen eens in de zoveel jaar.

Na het lezen van een van de eerste hoofdstukken kun je al gelijk beginnen met het toepassen van de techniek die hij bespreekt. Zo schrijft Robert C. Martin onder andere dat functies (en klassen) klein dienen te zijn. Over het algemeen zou je een functie prima kunnen inkorten naar een regel of 10. Ik heb dit geprobeerd in de praktijk en het blijkt ook nog waar te zijn. Nu kun je je functies wel allemaal kleiner gaan maken, maar de functionaliteit moet er nog steeds in blijven zitten. Dit heeft natuurlijk als gevolg dat er ineens heel veel functies ontstaan. Deze kunnen weer worden ondergebracht in allerlei ‘kleine’ klassen.

Tevens kun je zo vaak al snel zien of je ook een overkoepelende abstracte klasse nodig hebt.

Om nu gelijk ‘clean code’ te maken is wel een beetje ondoenlijk heb ik ervaren. Je kunt beter uitgaan van een slechte situatie en die gaan verbeteren. Ik denk dat ik dat dan ook maar ga doen in de toekomst. Eerst de functionaliteit ontwikkelen in ‘grote’ blokken en daarna refactoren in kleinere stukken die beter en cleaner zijn.