Skip to main content

A Java dev journey to full-stack: first chapter

The Motivation

I am an experienced Java developer and (surprise!) I like Java. I know it is not perfect but it works just fine for me (I enjoy type-safety and I do not consider verbosity a disadvantage, quite the opposite). I also know that some people dislike Java, which is also fine.

But recently I decided to step out of my confort zone as developer, my goal isn't to be one of the "cool kids" neither trying to monetize a new skill in the job market.
I have a quite practical motivation: I want to be able to build more (different) stuff.
That's exactly the same reason why I learnt Android development by myself a couple of years ago.

Web applications are ubiquitous, even more than native mobile apps, and thanks to cloud computing, one can easily and inexpensively release their idea/app to the World Wide Web.

I already did some Web development in the past, in the bad old days of JSP and JSF, but the process was slow and painful.

Nowadays the Web landscape has totally changed though, JavaScript is a mature language, it provides classes (well, not really, but bear with me) and a whole ecosystem which includes dependency injection, dependency resolution, a backend server (Node.js) and advanced IDEs.

The JavaScript Framework 

So the first step was to decide what to use for frontend development, among the numerous options, there are two main ones (by popularity): React or Angular.

After some research it seemed that Angular was more suitable for devs coming from the Java world, mainly because of two reasons:
- Typescript is more strongly typed than "naked" JavaScript, which makes it more similar to Java.
- Angular is a framework (not a library like React) which means that it provides more guidance (it's opinionated) and includes a comprehensive set of helper tools (e.g., a CLI).

So I chose Angular and VSCode as my Integrated Development Environment.

The Proof Of Concept

After having decided with what I'd code, one more important question remained open: what to code.
All I knew is that I wanted to make a modern (albeit simple) single page Web site. And by modern I essentially meant asynchronous live data loading onto the UI without user interaction (i.e., server data push, no need to click the "refresh" button).

But what would be the source of the data? That's when I decided to make things more interesting by throwing Android into the mix.

I decided the application would push location updates from my phone to the backend running on AWS and then to the Web browser.
All the data transfers would be in JSON format and secured by HTTPS (self-signed certificate).
And since I was already in 'adventurous mode', I decided to use Vert.x (a Java framework to build reactive applications) in the backend because it had been on my radar for a while already and it also provides good integration with JavaScript through its SockJS event bus bridge.

You can see how the web application works in the following video:

The Code

After several weeks of after-work coding and dealing with three different Git repositories, three different IDEs (AndroidStudio, Eclipse and VSCode) and two programming languages (Java and Typescript), I am ready to share the code with anyone who would care to have a look at it:


And the first version of the application is live at
Please note that you will get "your connection is not private" warning (or some other similar one depending on your browser of choice) when accessing it because of the self-signed certificate, but as long as you check that the SHA-256 fingerprint matches the following hexadecimal digits, you are safe:
DA C1 F8 06 D2 4E 17 C9 C4 F4 D7 47 40 AF CD F1
22 00 36 3E 97 CB 41 C2 63 DD 28 1F A0 51 12 29

Also, I do not think the backend will be able to handle much load since it runs on the smallest type of Amazon Lightsail instances (just 512 MB memory and one core processor) so if it is not able to keep up with the demand at least it would mean that this post has become somewhat popular :-)

I could write much more on related topics such as:
- how I combined Vert.x and Spring in the backend
- the Android service which fetches the location provided by the GPS
- client-side certificate
- the application configuration (loading, password encryption)
- RxJS
- the Vert.x event bus SockJS bridge
- the social implications of sharing my live location with potentially everybody (spoiler alert: I introduced a "masking" security mechanism in the Android code to keep the area where I live under the radar)

But I will leave that for future chapters of this journey since this learning exercise is far from over yet, stay tuned!


  1. I am attracted by the info which you have provided in the above post.frontend development agency It is genuinely good and beneficial info for us. Continue posting, Thank you.

  2. Amazingly helpful which you have shared here. I am impressed by the details and also it is a significant article for us. Continue imparting this sort of b2b travel platform development. Thank you.

  3. Thank you for sharing your journey, it is really inspiring. There are several tools and technologies full stack developers need to learn. Keep sharing your valuable knowledge and experience. Great blog. Full stack developer course in Chennai


Post a Comment

Popular posts from this blog

Kafka + WebSockets + Angular: event-driven microservices all the way to the frontend

In the the initial post of the  Event-driven microservices with Kafka series (see here  or  here ), I talked about the advantages of using event-driven communication and Kafka to implement stateful microservices instead of the standard stateless RESTful ones. I also presented the architecture and the source code of a related proof of concept application. In this post, I would like to show how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. Hence, in the first post of this series, we got rid of HTTP as the communication protocol among microservices in the backend, and now we are also replacing it (with WebSockets) as the communication protocol between the frontend and the backend. Ok, but why would you do that? Because it provides a better experience to the end user!. Using WebSockets you can build legit  real-time user interfaces, the updates are pushed immediately from the server to the client

Using Apache Kafka to implement event-driven microservices

When talking about microservices architecture, most people think of a network of stateless services which communicate through HTTP (one may call it RESTful or not, depending on how much of a nitpicker one is). But there is another way, which may be more suitable depending on the use case at hand. I am talking about event-driven microservices, where in addition to the classic request-response pattern, services publish messages which represent events (facts) and subscribe to topics (or queues depending on the terminology used) to receive events/messages. To fully understand and embrace this new software design paradigm is not straight-forward but it is totally worth it (at least looking into it). There are several interconnected concepts which need to be explored in order to discover the advantages of event-driven design and the evolutionary path which led to it, for example: Log (including log-structured storage engine and write-ahead log) Materialized View Event Sourcing C o

Kafka + Cadence + WebSockets + Angular: managing event-driven microservices state with Uber Cadence

In the the previous post of the Event-driven microservices with Kafka series (see here ), I showed how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. In that proof of concept application which processes money transfers, one Kafka topic is used to receive incoming transfer messages and a second topic is used to store the account balances state and broadcast changes (i.e., to push notifications from the backend to the frontend). The first topic (called " transfers ") and the second topic (called " account-balances ") are connected through Kafka Streams. Uber Cadence In this post we are bringing Uber Cadence  into the mix to manage the state of the application (i.e., to keep the balance of the accounts updated), thus, Cadence replaces Kafka Streams. Cadence is an orchestration/workflow engine which unlike most of the other workflow engines out there (e.g., Zeebe, Camunda and m