Talking about serverless microservices, functions are the basic building blocks of the service functionality. How to design them from the code and deployment perspektive?
Designing a system architecture is always about making tradeoffs. Microservices resp. serverless architecture has a lot of benefits, but some drawbacks as well. One of them is testing. Testing serverless systems is hard. In this article I will discuss some practices which work for my project.
Based on my question on StackOverflow I did a bit investigation about how (likely) are Node.js functions called in AWS Lambda containers.
In my previous article I showed how to build a simple RESTful microservice. For sake of simplicity I skipped some good practices for building REST APIs and I feel a bit guilty about that. I think that topic deserves its own article. And here we go... we take a look at the previous API and try to do things better.
How difficult is to properly implement the microservices design pattern in PHP? It will definitely need some thinking and maybe to leave some convince behind. At the end of the day we should have an autonomous loosely coupled service with all the benefits (and drawbacks) of microservices.
In this article we do a little walk-through of a development process of a small RESTful microservice in PHP and we take a look at some Domain-Driven Design (DDD) theory as well.
TypeScript application wants tests to be written in TypeScript as well, right?
There is a great library to achive this: jasmine-ts
But how to debug such tests within your IntelliJ IDE?
When one-thread-access is too restrictive and we want to allow more threads to our resource then come semaphores on the stage.
But there is one important difference in these approaches.
It's recommended to avoid any asynchrony within the scope of test, but this is unfortunaly not possible everywhere. In some systems the caller must wait for another thread or transaction to be completed.
Testing asynchrony could be pretty tricky, not always is clear how long must a test wait for a result to be delivered - if it's too little the test fails event when the tested functionality works, if it's too long the test is just wasting time (so expensive especially in the commit stage).
So, how to deal with this problem?
synchronizedof the critical code and this will work... but is it effective as well?