Gayan's Personal Blog

If you have worked with AWS and GCP, you should have understood that AWS' Elastic Beanstalk and Google's App Engine(GAE) enable deploying our applications without the need to understand how to build or scale the underlying infrastructure. Their promise is great, and for most use cases as there are no servers to maintain. We simply upload our applications and they are ready to go. If everything works as promised Beanstalk or the Google App engine will take care of scaling, load balancing, traffic splitting, logging, versioning, roll out and roll backs, and security scanning etc. Pretty simple , ah? Today I am going to share simple steps to deploy your first Spring boot (with Java and Maven)  application to  Google Cloud App Engine. So let's create s simple create a Spring Boot Java API on Google App Engine. I asume you have set up Google Cloud SDK in your local. (https://cloud.google.com/sdk/gcloud). Alternatively you can use Cloud Shell. $ gcloud auth list $ ...

I was working on a Spring boot application which I needed to deploy in Google Cloud Appengine, in the same time one of my colleague made a pull request for a similar code. Then I noticed that we two have used 2 different Maven plugins from Google appengine with same artifactId. they are: <plugin> <groupId> com.google.appengine</groupId> <artifactId> appengine-maven-plugin</artifactId> <version> 1.9.64</version> </plugin> and <plugin> <groupId> com.google.cloud.tools</groupId> <artifactId> appengine-maven-plugin</artifactId> <version> 1.3.2</version> </plugin> at the time of writing followings are the 2 articles I could find in Googledocs for 2 plugins  https://cloud.google.com/appengine/docs/standard/java/tools/maven  https://cloud.google.com/appengine/docs/standard/java/tools/using-maven  So as the name suggests they are "App Engine SDK-based" and "...

I had this note from long time in my Evernotes, I thought I should have post it here, so someone might find it useful. This is just Docker basics and commonly used commands that I've collected over time. Why Docker? Docker enables containerization - running applications in containers instead of virtual machines. Important notes: Containers are not VMs - they have different benefits Provides standardization across environments Enables continuous deployment from development to production Ensures consistency using the same container image throughout the deployment process Key Benefits: Self-contained environments Isolated from other applications Runs almost everywhere (especially in the Cloud) Small and lightweight Highly scalable Fast deployment Core Concepts Images An image is an executable package containing everything needed to run an application: ...

 Hi folks, Many days I was playing with Kong in Docker, quick scaffolding for anyone interest to play with it. This summarises my basic learnings. What is Kong? Kong is an API gateway. Some of the popular features deployed through Kong include authentication, security, traffic control, serverless, analytics & monitoring, request/response transformations and logging. A typical Kong setup is made of two main components: 1)Kong’s server, based on the widely adopted NGINX HTTP server 2)Kong’s datastore, Apache Cassandra and PostgreSQL can be used. Terminology: What are Kong plugins? Kong API gateway features are provided by plugins. Authentication, rate-limiting, transformation, logging etc, are all implemented independently as plugins. Plugins can be installed and configured via the Admin API running alongside Kong. What is a Kong Service? a Service is the name Kong uses to refer to the upstream APIs and microservices it manages. What is a Route? Routes specify...

This is well known thing if you are using Mockito to mock your services. But I wanted to note it here.  Imagine you have a method call inside method you are writing the unit test (or eg:-getPayment() ) that should not be called when your test is executed.  That may be the first reason why you mocked it in the first place.  In below code, I want to mock getPayment() method without executing it. option A:     Mockito.when(subject.getPayment()).thenReturn(paymentDetail); option B:     Mockito.doReturn(paymentDetail).when(subject).getPayment(); If you tested both, option A will actually call the getPayment()- method while the second will not. Both will cause doSomeStuff() to return the desired `paymentDetail` Object. Hope this helps someone new ith Mockito!