#rant that none asked for.
I came across this whitepaper on testing micro services. I clicked on this link because I am writing microservices now but I am fairly new to microservices.
I did a mistake that I have repeated 1593 times in the past. The said link was a resource by one of the big IT service providers.
While the work indeed is commendable - automating 4000 test cases is no joke, the content and approach for highlighting the “best practice” leave much to be desired.
...
While we love to have production-like environments for user testing, managing data and the test environments can present unique challenges.
In today’s enterprises it is fairly common to have multiple test environments including staging, system / user testing environments and so on. These environments expect production-like features but only for specified users.
For example -
Validations have to work as they are in production Document templates and document merge has to work Email and SMS communications have to work for select users Logins have to work for select users A few staging environments may need data in volume - what better data can you find outside of your own production environment? As is the norm for typical enterprise applications, I tend to -
...
Why do I use GraphQL? Also, the case for not using GraphQL.
You must have seen the previous post where I waxed eloquent about how I mess up my Rest APIs. There was no way I would be satisfied doing that to a single technology stack.
Ergo, GraphQL.
What is the need for GraphQL? Google GraphQL and refer docs- there are smarter people with better answers than me.
But, since the Internet can be a scary place and I love to write about things that I am not an expert in - here’s a gist about what I think.
...
How not to design Rest services?
This is not a theoritical introduction to Rest - there’s something called the ‘Great Internet’ for that. But, what I do want to (cautiously) write about is how I mess up the design principles carefully laid out by smarter people.
Practice 1: Use verbs in resource names We typically use the following API names -
GET https://api.com/contact PATCH https://api.com/contact This is not a problem in the normal course of designing services. But, when it is time to get some complex queries - I always do a rain dance and come up with stupid names.
...
I have this annoying behaviour to force as many things as I can through the business layer. This can be a boon and bane at the same time.
What do I mean by business layer? Let’s say I have an application running on AdonisJS. For every operation (CRUD) -
I try to go through controllers/services Almost all of them through APIs when called from front-end Almost all of the operations through Lucid with exceptions through Database statements Use Tasks or equivalent for batches Everyone does this, why is it a point of discussion? Going through business layer is good. You can control what gets read or updated when routing through the server layers.
...
I was a MeteorJS fan.
MeteorJS was an excellent tool to quickly create universal apps. I was not quite a professional developer back in the day (circa 2016-17) but I could recognize the power of Meteor in developing complex web applications that could potentially deployed for multiple devices.
There was a time when I was flabbergasted as I, rather alarmingly, saw people moving from Meteor to different platforms. I could not quite understand why.
...
Most of my coding a few years back consisted of the following actions -
Type slowly Type (a lot of) mistakes Use spaces and tabs to format. Get confused about loops and add ad-hoc spaces and tabs Curse my typing skills and the soul who invented spaces and tabs While formatting code was also becoming an interim ’thought provoker’, it was simply too much typing.
Enter prettier.
Although my typing is only half as bad, I now have far less stuff to worry about.
...