DEV Community: Poovamraj T T

Make Spring Boot Lean And Mean - Throwing Away Hibernate and Java from Spring Boot

Poovamraj T T — Mon, 17 May 2021 19:38:53 +0000

Developing a backend application requires huge stability and data modeling is one of the pieces of software that is toughest to migrate hence choosing a reliable and stable technology is a necessity.

Spring Boot is one of the most reliable frameworks in the Java ecosystem. There are great efforts in developing leaner and better frameworks but Spring Boot seems to have great examples and solutions to many common problems faced in backend development. But it is hard to overlook the aged development methodology and impact on productivity.

I recently started writing an application and I have overhauled my Spring Boot boilerplate to ensure the latest development productivity improvements can be ensured where ever possible

Data Layer Improvements - Irritating parts of Hibernate

1) I realized OneToOne mapping can have multiple entities on the child table unless we mark it with unique=true. This is one such example where we have to understand the nook and cranny of Hibernate just to avoid severe issues.

2) Bidirectional mapping to join from child to parent

3) Writing complex queries are sometimes impossible due to the domain structure we design

4) Defining your SQL tables with Java POJOs might feel all good initially until the reality of complex DB migrations comes into the workflow.

Initially, to overcome writing the complex queries issues which were impossible with Hibernate, I started looking for replacements that were strongly typed. I stumbled upon jOOQ which I fell in love with instantly. But to be on the cautious side I integrated it and used it just for complex queries. After all, jOOQ itself mentions Hibernate is good for CREATE, UPDATE, and DELETE operations.

jOOQ has the coolest features that no other ORM I have seen has. It generates the Object representation of your Tables using a code-gen module.

This can be done by connecting it to a Database but I felt this was an unwanted dependency at build/dev time.

I overcame this by integrating Liquibase using which jOOQ can generate the Object representation. Initially, this felt like overkill but understanding the uses of DB Migration libraries like Flyway/Liquibase made me realize how important such a tool is for DB migration.

Now that I had my DB definitions in Liquibase and Object definitions generated by jOOQ it felt obsolete to use Hibernate which I was only using for CREATE, UPDATE, DELETE operations and it started to feel more and more obsolete.

Finally, I took the big leap of removing the spring-data-jpa dependency as a whole.

Improving Service Layer

Many shy away from Spring Boot because of it being a Java framework. After all, just after hearing the word Java, It is impossible for a developer to not be scared of some pattern like AbstractFactoryBuilderAdapter. But what we have to understand is that it is a JVM-based framework and languages like Scala and Kotlin integrate nicely with Spring Boot. Moving my application from Java to Kotlin felt like a breath of fresh air since I got all the following features along with it

1) Nullability checks
2) Type inference
3) Data classes
4) Concise code

The above efforts made my personal boilerplate feel very similar to Nodejs/Typescript/TypeORM combo that I use at my work.

Java/JVM is a great piece of software overlooked by many developers for shiny new frameworks. I have seen many startups and recently even a unicorn moving from languages like Go to Java due to many reasons. Some of the most complex features required for enterprise development are built into Java-based frameworks like Spring (For example - I was not able to find Access Control List feature in any other framework but in Spring)

I would like to hear your comments on this. You can follow me at Twitter - https://twitter.com/poovamraj

How to think in Next.js - Learn the Mental Model

Poovamraj T T — Sat, 08 May 2021 19:10:48 +0000

The most important thing when learning a new framework, especially ones which have a new way of doing things is to understand how to think (or design) solutions to a problem.

Next.js claims the major issue it fixes on top of React.js is "Pre Rendering"

What is Pre Rendering

Historically frameworks like JSP used to render the HTML content of the page on the server-side and send the rendered HTML page to the browser. This is in contrast to the approach used in modern frameworks like React.js where the web page first loads the JS and then it renders all the required HTML elements on the client (read it as the browser) side

The concept of Client-side rendering works well as it completely separates the backend and frontend. But there are certain issues that can arise from client-side rendering.

Search Engines tend to parse the HTML file and index it. This scraping process is not optimized for sites that do client-side rendering.
When you are rendering on the client end, whenever an API call is made, the request has to travel all the way from the client who can be in the US to the server which can reside in JAPAN. This can severely slow down the performance. Instead, if we are rendering on the server end, most of the data can be fetched easily as the rendering can happen at the same place as the server.

If you do not have the above 2 use-cases, you can simply use the traditional client-side rendering application. At least, that's what I am doing.

This concept is generally called Server-Side Rendering (SSR)

But Next.js tends to use the word "Pre Rendering". This is to distinguish the two major use cases the framework is used for

Static Rendering
Server-Side Rendering

Static Rendering

When the HTML code is generated as soon as we run the build, This is called static rendering.

Static rendering is useful for Homepages or Blogs where the content of the page doesn't change often (For example - each reload won't have different data like a stock market site).

We can write a "Page" by exporting a JSX component under the pages folder.

For example - writing a js file named 'hello.js' that exports a JSX component under the pages folder will give us a

localhost:3000/hello page

Creating a new folder will add it as a path.

For example - creating a folder named 'blog' under pages folder with a js file named hello that returns a JSX component provides us with

localhost:3000/blog/hello page

It is as simple as writing an HTML file under a webserver and accessing it using its path.

Next.js also provides a feature where the static pages can be rendered dynamically. Let me explain a use case

Let's say you write blogs that are maintained in a Database (actually they are usually maintained in a component called Headless CMS, but for simplicity, let's say a database)

If you want to fetch the content from that database instead of writing the content of the blog directly on the JS file. You can use the method getStaticProps

This will fetch us the content of the blog "WHILE BUILDING THE PROJECT" and pre-render the HTML pages for us

Server-Side Rendering
The HTML code is generated only when the request hits our server for Server-Side Rendering.

This is useful for use cases like Forum or Saas applications That has the potential to change for each request.

The pages (or routing) concept is similar to static rendering. Any js file returning a JSX component inside the pages folder is a separate page (or route)

Each time this route is called on the browser, the Next.js framework tends to render the page and provide a full HTML page as a response.

Any data that needs to be fetched from the backend for rendering this page can be returned using getServerSideProps.

For example - A table with all the stock prices can be rendered each time when a request is made. The required data to fill the stock price can be fetched inside getServerSideProps. Since the rendering can happen at the same location as the backend, the round trip time to make this request will be very very less.

Dynamic Routing
There can be a use case where all the routes will not be known to us. For example - In the previous blog example I mentioned where the content can be fetched from the DB, Imagine what will happen when a new blog is added to the DB.

We cannot be writing a new page each time a new blog is written right? (i.e) The routes that can be reached can change dynamically based on a different source of data rather than the JS files we created.

For this, we have the concept of Dynamic Rendering. Any file under the pages folder with the name wrapped with brackets like [].js can have a method called getStaticPaths which can be used to return all the possible paths. These paths can also be rendered for each request using an option called blocking which needs to be set in the return value.

Conclusion
Understanding the mental model of a framework easily helps us solve problems using that framework. While first learning React we all would have faced the issue of understanding the uses of a "state" and a "prop" while now it can be written without a second thought. In a similar way, to learn Next.js, the first thing to learn would be the uses of

getStaticProps
getServerSideProps
getStaticPaths

Next.js provides a lot more great features like <Link/> <Image/> <Head/>. But once the above differences and uses are understood, the rest should be a walk in the park!

I would love to discuss this topic and learn more if you have something to share!

You can find me on Twitter at - https://twitter.com/poovamraj