| |

Why I Like Spring

To start off, let’s agree that Spring is a lovely ecosystem, between the large community support, it’s incredibly popular & it’s just all round tried & tested. I could go on, one thing that’s made me fall in love with the Spring framework is the ease that’s included when scaling horizontally, and hell, here’s a link showing you just how easy it is.

What is horizontal scaling?

If you’re new to the world of technology you may or may not have heard of this term before, essentially, there are two main forms of scaling an application or system. This consists of horizontal & vertical, vertical scaling simply means where you add more power to an application and/or system. Horizontal scaling is essentially where you add more machines to the application, i.e. using a load balancer with several nodes. Now, depending on what layer(s) you have your load balancer(s) on can also contribute to more problems, however, in this brief article, I won’t discuss this too much.

So, what’s the problem?

Speaking of horizontal scalability while using Docker, Kubernetes & Azure, being able to externalise the HttpSession is near enough essential. In the scenario where a docker container dies, thanks to the use of a docker orchestration technology such as Kubernetes, it allows for another container to spin up, great. However, the issues arise when it comes to state; now, I think it’s reasonable to state that many web applications today are stateful to some degree or another. While everyone’s going wild saying how it’s all about going stateless, which isn’t by any means wrong, but in some scenarios, it’s just silly to make something(s) stateless. Maybe silly is the wrong word of choice, perhaps you could consider it an uphill battle with little to no noticeable benefit(s) or advantage(s).

Image result for kubernetes

Stateful & Stateless

Statelessness makes sense for web applications, after all the HTTP protocol is stateless by design, if you don’t want to take my word for it, then by all means refer to RFC 7230. However, sometimes from a business logic perspective, it makes no sense to make everything stateless, an example being whether a user is logged in or not. Rather than have a user log in on each request, just store it in some session-like object, querying the database would be incredibly inefficient for such a small feature. You could easily just store a Boolean in the session object, i.e. isUserLoggedIn, that’s about it, that’s all it would take, of course you’ll want to implement secure authentication & authorisation to ensure that all is well.

Another example of an application that should be stateful is a shopping cart, now where you keep that state specifically is up to you as an individual, group, company, etc. If you do like the idea of going stateless, you can easily keep that off the application server & away from the client & make use of some form of persistence technology, whether this is some form of NoSQL like Redis or a fully-fledged RDBMS. Traditionally using the RDBMS is a reliable approach, but depending on the ecosystem, it could require a lot of time-consuming DIY work. In other ecosystems, there are existing technologies and/or configurations to allow web applications to externalise stateful features. Looking at Java specifically, there are pre-existing solutions such as using Infinispan, however, such implementation could vary just depending on the application server that’s being used, it’s hardly a clean approach, at least in my opinion anyway. To further expand on why the RDBMS isn’t the best of ideas is that there will be performance issues.

Image result for redis

Another example of an application that should be stateful is a shopping cart, now where you keep that state specifically is up to you as an individual, group, company, etc. If you do like the idea of going stateless, you can easily keep that off the application server & away from the client & make use of some form of persistence technology, whether this is some form of NoSQL like Redis or a fully-fledged RDBMS. Traditionally using the RDBMS is a reliable approach, but depending on the ecosystem, it could require a lot of time-consuming DIY work. In other ecosystems, there are existing technologies and/or configurations to allow web applications to externalise stateful features. Looking at Java specifically, there are pre-existing solutions such as using Infinispan, however, such implementation could vary just depending on the application server that’s being used, it’s hardly a clean approach, at least in my opinion anyway. To further expand on why the RDBMS isn’t the best of ideas is that there will be performance issues.

Conclusion

With problems such as externalising the application state and/or session, with regards to the overall complexity, your mileage may vary, greatly. There’s a wide variety of variables that one needs to take into consideration, including the underlying architecture, i.e. if you’re using a single server, then this should be much easier than say a cluster or some architecture that uses some form of load balancer.  Therefore, I personally believe that Spring is a god send in such a scenario, using Spring Session, it’s compatible with all sorts of solutions, ranging from Redis to Hazelcast to some RDBMS.

There are many other reasons why one should enjoy working with Spring, not to mention how it has it’s own testing framework, which allows for a mixture of integration testing & unit testing, all in all Spring is quite a beautiful & complete framework.

Similar Posts

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments